Avid does not publish this format. Everything on these pages is from ptformat, the open-source reader that Ardour uses, which covers Pro Tools 5 to 12.
The plain header
The first 20 bytes, offsets 0x00 to 0x13, are not obfuscated.
| Offset | Size | Meaning |
|---|---|---|
0x00 | 1 | 0x03 in the files ptformat recognises by this byte |
0x01 | 16 | In other files, the ASCII text 0010111100101011 |
0x11 | 1 | Byte order of the file: zero is little-endian, non-zero big-endian |
0x12 | 1 | The XOR type: 0x01 or 0x05 |
0x13 | 1 | The XOR value that the key is derived from |
ptformat accepts a file when byte 0 is 0x03 or the bit string is at offset 1,
and rejects files under 20 bytes.
The XOR scheme
Every byte from offset 20 on is XORed with a value from a 256-byte table. The type byte chooses how the table is built and how a byte picks its entry.
| Type | Pro Tools | Delta from the value | Table index for file offset i |
|---|---|---|---|
0x01 | 5 to 9 | the d for which (d × 53) & 0xFF = value | i & 0xFF |
0x05 | 10 to 12 | minus the d for which (d × 11) & 0xFF = value | (i >> 12) & 0xFF |
The search for d runs from 0 to 255 and takes the first match. The table is then:
key[n] = (n × delta) & 0xFF for n from 0 to 255
out[i] = in[i] XOR key[index(i)] for every i from 20 onwardsType 0x05 changes key entry only every 4 KiB, because its index uses the
offset’s higher bits. Any other type byte is not supported.
A worked example
In a type 0x01 file with value 0x35, d is 1 because
53 × 1 = 0x35. The key is then key[n] = n. The byte at file offset
0x14 is XORed with 0x14, and the byte at offset 0x0100
with 0x00.
In a type 0x05 file with value 0x0B, d is 1 and
the delta is −1, so key[n] = (−n) & 0xFF. Every byte from offset
0x1000 to 0x1FFF uses key[1], which is
0xFF.
Not confirmed
- Sessions saved by versions after Pro Tools 12; ptformat stops at 12.
- The meaning of the other header bytes.