PPM metadata and provenance

The metadata block starts at absolute offset 0x10 and is 0x90 bytes long. It is separate from the 16-byte file header and the 0x600-byte thumbnail. The block records edit ancestry as root, parent and current author fields; a spin-off can therefore preserve its origin while changing its current author. [1][2]

Field map

Relative offset	Field	Interpretation
0x00	16-bit lock	Normally zero for unlocked and one for locked
0x02	16-bit frame index	Frame chosen for the thumbnail
0x04 / 0x1A / 0x30	Three UTF-16LE names	Root, parent and current author, each 11 code units
0x46 / 0x4E / 0x7A	Three eight-byte IDs	Parent, current and root FSIDs
0x56 / 0x68 / 0x82	Filename records	Parent, current and root fragment
0x8A	32-bit timestamp	Seconds since 2000-01-01

The offsets above are relative to the metadata block, not to file start. Names are null-padded; a reader should stop at the first null code unit within the fixed field. Format IDs from the stored byte order, then reverse for their usual hexadecimal display. [2]

Validation and display

Check the thumbnail frame index against the actual frame count. Display the three author roles explicitly; choosing only “creator” can erase the distinction between an original and a spin-off. Treat lock state and author labels as file claims, not an authentication result. The original SD path also performs a filename-related comparison during acceptance. [1][2]

How the original serialiser writes metadata

The studied original code sometimes copies alternate metadata or suppresses regeneration in checkpoint modes. It does not always freshly synthesise all 0x90 bytes from a single structure. A byte-for-byte reproduction needs to account for the operation mode and existing state, not only the published field table. [1]

Filename records in metadata

The parent and current filename fields are each 18 bytes long: a three-byte prefix from the last six MAC hex digits, a thirteen-character middle part and a 16-bit edit counter. The root's eight-byte fragment contains the three-byte prefix and five more bytes from the middle part. Read these as binary records rather than null-terminated printable filenames. The documented layout ends with two padding bytes at metadata-relative offset 0x8E. [3]

To display an FSID, reverse the eight stored ID bytes and format them as sixteen upper-case hex digits. The timestamp counts seconds since 2000-01-01 00:00:00. Offsets in the metadata table are relative to that block: metadata offset 0x46 is absolute file offset 0x56. [3]

Filename fragments are not all stored the same way

The parent and current filename records each consist of three prefix bytes, thirteen literal filename characters and a 16-bit edit counter. The wiki’s worked filename is F78DA8_14768882B56B8_030: F78DA8 prints the three prefix bytes, 14768882B56B8 is the thirteen-character component, and counter 30 is displayed as 030. The separators are part of the printed form, not extra bytes inside each eighteen-byte record. [4]

The eight-byte root fragment is shorter: it keeps the three-byte prefix plus five bytes representing the first ten hexadecimal characters of the middle component. It cannot preserve all thirteen characters or an edit counter. Do not treat its final five bytes as another thirteen-character text field. See identity and filename handling for the separate filesystem-name rules. [4]

Metadata-relative 0x8E is a two-byte padding field documented as zero. Author names use fixed eleven-code-unit UTF-16LE fields, with null padding; thumbnail-frame indexing begins at zero. These are the field sizes once the format-version check has determined that metadata is present. [4]

A filename example with all three byte records

DSiBrew supplies bytes for the filesystem name G35B20_0909841CDBEB1_002. The two complete filename records retain the middle component as thirteen text bytes, while the short root fragment packs its first ten hexadecimal characters into five bytes. The author and ancestry labels below follow the root/parent/current field map above; the older article uses less precise labels for some author and filename positions. [5] [2]

Absolute offset	Record	Bytes in the supplied example
0x0066	Parent filename; edit counter 0	D3 5B 20 30 39 30 39 38 34 31 43 44 42 45 42 31 00 00
0x0078	Current filename; edit counter 2	D3 5B 20 30 39 30 39 38 34 31 43 44 42 45 42 31 02 00
0x0092	Short root filename fragment	D3 5B 20 09 09 84 1C DB

• The first three bytes are the binary prefix D3 5B 20.
• In either complete record, bytes 30 39 30 39 38 34 31 43 44 42 45 42 31 spell 0909841CDBEB1. The following little-endian counter is 00 00 for the parent record and 02 00 for the current record.
• The root fragment instead retains 09 09 84 1C DB, representing 0909841CDB. It omits the final three middle characters EB1 and both counter bytes.

The printable name begins with G, whereas the first prefix byte begins with hexadecimal nibble D. That is consistent with Studio's filesystem check character: applying the separately documented check-character arithmetic to metadata-form D35B20_0909841CDBEB1_002 yields accumulator 52, base-36 index 16 and character G. The three prefix bytes should therefore be kept as stored, even though the printed name begins with a different character. See identity and filename handling. [5] [6]

The historical article tentatively associates the prefix with an FSID suffix and the middle component with a date or random value. The later filename reference instead identifies the prefix with the console's current Wi-Fi MAC suffix, which can diverge from a retained FSID after a Wi-Fi-card change. An FSID-suffix match is therefore not a reliable identity check. These observations also do not establish how the complete middle component is generated. [5] [6]