-
Notifications
You must be signed in to change notification settings - Fork 18
Home
Damien Zammit edited this page Jan 13, 2019
·
2 revisions
With exception to the header of the PT session file, it seems that everything consists of blocks. Blocks have a very clear structure:
struct block_t {
uint8_t blockMarker; // 0x5a
uint16_t blockType; // many options, they might have to do with a certain data structure inside the data block, but I haven't found very strict 'rules' yet.
uint32_t dataSize;
uint8_t[dataSize] data
}
I have a strong suspicion that the data inside a block always starts with a content type, determined by a uint16. As far as I can remember, every block has had one so far. It is possible that this depends on the blockType. The data part can contain more blocks, which each again follow the block_t structure. I found that content block types can occur in multiple block types, and also that content blocks can occur on different nesting levels.
#!/usr/bin/env node
const filename = process.argv[2];
const fs = require('fs');
const path = require('path');
/** @type {Buffer} */
const file = fs.readFileSync(filename);
// gets buffer
// check header
console.log('bitcode', file.toString('ascii',1,17));
if (file[0] !== 0x03 || file.toString('ascii',1,17) !== "0010111100101011") {
console.log("Not a protools file");
return
}
const isBigEndian = !!file[17]; // 0 if LE, 1 if BE
// 18 and 19 are some bytes of which is unclear what they mean
// then at 20 we get the first 5a, we split everything up in blocks from there
const blocks = [];
let i = 20;
let done = false;
do {
if (file[i] !== 0x5a) {
console.log('weird, an unfinished block, breaking at ', i);
break;
}
let blocktype = isBigEndian? file.readUInt16BE(i+1): file.readUInt16LE(i+1);
let blocksize = isBigEndian? file.readUInt32BE(i+3): file.readUInt32LE(i+3);
let blocktypeString = isBigEndian?
file.readUInt8(i+4).toString(16) + file.readUInt8(i+3).toString(16):
file.readUInt8(i + 3).toString(16) + file.readUInt8(i + 4).toString(16);
let blockcontenttype1 = isBigEndian? file.readUInt16BE(i+7): file.readUInt16LE(i+7);
let blockcontenttypeString = isBigEndian?
file.readUInt8(i + 8).toString(16) + file.readUInt8(i + 7).toString(16) :
file.readUInt8(i + 7).toString(16) + file.readUInt8(i + 8).toString(16);
let blockcontenttype1marker = isBigEndian? file.readUInt8(i+9): file.readUInt8(i+9);
let blockcontenttype2 = isBigEndian? file.readUInt16BE(i+10): file.readUInt16LE(i+10);
console.log(`block found at ${i}, blocktype ${blocktype}, size ${blocksize}, blockcontenttype1 ${blockcontenttype1}, typemarker1 ${blockcontenttype1marker}, contenttype2 ${blockcontenttype2}`);
let totalblocksize = 1 + 2 + 4 + blocksize;
blocks.push({
loc: i,
blocktype,
blocktypeString,
blocksize,
totalblocksize,
blockcontenttype: blockcontenttype1,
blockcontenttypeString,
blockdata: file.slice(i, i+totalblocksize)
});
i += totalblocksize || 1; // one for marker, two for type, 4 for block size int
} while (i < file.length)
blocks.forEach(b => {
const fp = path.join("blocks", b.blocktype.toString(16), b.blockcontenttypeString);
try {
fs.mkdirSync(fp, { recursive: true })
}
catch (e) {
if (e.code !== "EEXISTS") throw e;
}
const fn = path.join(fp, filename + "_" + b.loc);
fs.writeFileSync(fn, b.blockdata);
});
console.log("number of blocks", blocks.length);
/*
block type 3 seems to always be followed by a 16 bit int, 8 bit int and a 32 bit int
in 7.3
block type 5, content type 0x2810 LE, always followed by 0x0310 in both BE and LE
then a 32 bit int with the session rate
*/
/*
Content types: (hexadecimals in LE notation, as it easier to locate in a hex viewer)
0x30 00 => product info, including version
0x04 10 => audio file list, always block type 2
0x1a 27 => only occurs in 12, contains "Markers"
0x28 10 => session sample rate
0x67 20 => session info, path of session
0x19 25 =>
0x11 25 => Snaps block
0x56 20
*/
/*
block type 2, content type 0x04 10: Audio file list
uint32 num sound files
then contains a block of type 1, content type 0x3a10
uint32 num1
uint8 some byte
uint32 num2
uint32 numchars (always 11, because audio files)
char[11] => Audio Files
uint32 => empty, unclear
-> the following is repeated for every audio file
uint8 => 0x02, seems to be indicator that something will be following
uint32 => empty, unclear
uint32 => length of the string to follow
uint32 => number that reads WAVE in BE, EVAW in LE
->
uint8 => 0x00 seems to be indicator that this was the last file
uint32 => 0xFF FF FF FF, seems to be indicator for end of list
uint32 => length of string to follow
char[] => root drive name
5 x uint8 => unclear what this is for
uint32 => number, unclear
uint32 => length of string to follow
char[]
5 x uint8 => unclear what this is for
uint32 => number, unclear, is value of previous directory + 1
uint32 => length of string to follow
char[]
5 x uint8 => unclear what this is for
uint32 => number, unclear, is value of previous directory + 1
uint32 => length of string to follow
char[]
after last path uint32 empty, perhaps to indicate that the end of the path has been reached
Next block
0x5a, block type 0x18 00 in 7.3, 0x0700 in v8
content type 0x0310 Meta data of audio files
uint32 // looks like a counter, data for file 1
uint8 0x5a => content block:
block type 0x0200
uint32 block size
content type 0x01 10
uint32 sample rate of file ?
uint8 very often 0x01
uint8 very often 0x10, in pt8 0x18
uint64 file length
*/
/*
sample offset...
block content type 0x0b10 LE
uint32 possible number of blocks to follow
nested block
uint8 0x5a
uint16 0x0600 => block type (7.1 has 5)
uint32 block size
uint16 content type 0x0810
nested block
uint8 0x5a
uint16 block type 0x0c00
uint32 block size
uint16 content type 0x0710
uint32 string length
char[] name
uint16 empty?
uint16 number, sometimes 0x1000 sometimes 0x2000, is uint16 as compared to BE
uint8 seems to be always zero
uint16 length
*/
/*
Regions per track
block type 0x02 00
content type 0x5210
uint32 string length
char[]
uint32 regions per track
block 0x5a
block type 1
content type 0x5010
nested block 0x5a
block type 7
content type 0x4f10
uint16 number
uint32 tr.reg.index
*/