File Example: http://www.mediafire.com/download/kwa62rbz48826oo/CA022000.bin
"File Count is at Offset" (which is how many files are presented, and can be counted from looking at header) I get 0x0C at size 4 (Most cases it's 4, if it's bigger, the size of file is likely to be really huge?) with byte order Big Endian (EX: Sequence of 10203040... Big Endian = 10203040 [normal]... Little Endian = 40302010 [backwards]... not sure if this is the right way to look at it)
For individual "File Length is at Offset", I put 0x2C at size 4 and byte order Big Endian. I don't understand the calculation space just underneath byte order option.
For individual file name location/offset, I checked that "File Name is included in the VFS" since names/directories are given in this container I'm wanting to extract. "File Name is Included in the Individual File Record at Offset" I set it to 0x34. I'm not sure if this section is the "directory/name listing starts here" flag.
File Record I'm uncertain what I'm supposed to be looking for. I keep thinking 0x08 is where offset begins and has record size of 0x130... but I'm certain it's wrong.
Individual File Name Size I'm not certain about this, but I guess since directory listing starts from 0x24 ~ 0x137... I'd assume the value is 0x104.
Would love more help on this, since I can't seem to dig around for self-input on what am I supposed to be looking for, along with the calculation portion for Individual File Offset.
Help would be appreciated!
0x0C - File Count, 32-bit big endian (green box)
0x20 - File Records begin, size 0x114 each. You can use the difference between the start of the file names for each record to determine this value.
Within each record,
0x08 - file length, 32-bit big endian (red box)
0x10 - file offset, 32-bit big endian (pink box)
0x14 - 0x100 byte file name (light blue box).VGMToolbox will stop parsing the file names at a null byte (0x00).
Highlighted Hex View
Calculation Portion
Regarding the calculation portion, some VFSs store offsets as values different than the absolute offset. The value may be relative to the end of the header or some older VFSs divide the absolute offset by 0x800 (possible remnant of CD related blocks?).
So for example, if the offset in a file record is relative to the end of the header, you might put "$V + 0x291C" in the calculation box. For the second example above you could use "$V * 0x800."
The calculation box simply replaces $V with the value found in the file and then runs it through a javascript Math function to perform the calculation.
edited 1:45 AM EDT September 18, 2015
On a side note, it looks that finding a consistent calculation rate for .pos files (for .XMA) doesn't seem to work out, and I believe that the calculation for it hasn't been found yet.
In case of error (particularly this set), I noticed when applying to some .bin files it didn't work correctly and causes VGMToolbox to hang, but that was because the .bin files near the end actually didn't contain a VFS, which instead contained .WMV data.