The data is aligned to 16-byte blocks, which means data is padded to a multiple of 16. The VOL header is only 20 bytes long, but padded to 32 bytes.
In the BMS script, I read the header like this:
Code: Select all
idstring "RTDP" # The identifier (quickBMS will close if the first 4 bytes aren't "RTDF")
get EOH long # Then I read 3 of the 4 integers which follow. I don't read the last because I don't know what it is.
get FILES long
get THISSIZE long
goto 0x20 # This skips to the end padding
# padding 16 << this is what i should have used
Then come the file headers. This is a single block, and padded at the end;
Then comes the file data. Each file is padded.
FILEOFFSET
When the VOL was created, the generator couldn't use raw offsets to the file data. This is because it didn't calculate the size of the header and file headers, and as a fix, just saved the size as EOH.
So FILEOFFSET is a pointer from the end of the header and file headers, which can be truly found by adding EOH.
xor value
I just didn't look for the xor value, but I had a suspicion the data was still not extracted.
0x00 xor 0x55 = 0x55, and 0x00 is a common byte - so you could have found the xor value easily if you bothered to look.
endian
You didn't mention the endian so I'll just point out that it is big, which is common of Wii titles.