PlayStation Development Network

Hello!
I'm reversing some of Einhander's files format for translation purposes and one of sound formats looks almost identical to VAB. According to "File Format 47.pdf", it has exactly the same structure, except VAG offset table does not take 512 bytes, but visually looks like almost 0x15F0 bytes and all samples begin from this offset (0x2010). I also have problems with major tools to even extract samples properly from this VAB (even VAB Tool).
Last pair in offset table is sector offset and size word16 of another sample, which is not included in standard vab file, but just attached in the end.
So I was thinking if it's possible that this VAB file is just from another library version (Einhander was compiled with PSYQ 3.7)
Is anyone familiar with such kind of VAB file structure?

Try using bin2seq.

Thank you, Squaresoft74!
That sort of helped: at least bin2seq has properly calculated VB start at 0x2000 and so first 6 VAGs were extracted properly.
That's also interesting why there is more than 0x1000 bytes between VH end and VB start in .VAB file, as File Format 47 does not mention this.
But what is more important, there is also 7th sample, which is attached in the end of VB and reference to this can be found in this empty space after VH. bin2seq also did not recognize it. In the game 7th sample just plays in the same time as 1st sample.
I attach VAB file just in case.

Here's your Vab file splitted to .vh/.vb, VabTool will now properly load them.
Taking a wild guess, i assume data (mostly 0x00) between the VH and VB ones in your raw VAB file are just some filler (with some pointers for the file system used by the game) so the files are stored in 0x800 multiple chunks.

Thank you very much! For me it was important to know that it's not some kind of standard scheme. I should debug a little deeper in Einhander code to check how this pseudo vab file is used.

Hello again, just to close the topic, this file was really another archive.
It has first 0x2000 bytes as VAB header in it's usual format + dummy bytes to the end of 0x2000 block. Last two word16 of block are size in sectors of VAB body and size in bytes of the last sector.
So executable code just copies VAB header to RAM, and then copies to SPU all sectors after 0x2000 until last specified sector is encountered. Then it just copies appointed number of bytes of last sector to SPU, so now SPU memory has all VAGs. And code then parses VAB header, which is left in RAM for different play sound tasks.

Nice, good luck with your reversing/translation project.