VAB sound bank Confirmed

At a glance

Magic

VABp at the bank's own offset 0 - usually not the PROT entry's offset 0 (see the wrapper figure)

Where on disc

424 banks across 219 PROT.DAT entries. The vab_01 cluster (extraction 1072..1194) holds one bank per entry; 0891_level_up is the single multi-bank archive (206 banks); most music banks ride inside scene streaming containers

Stride

32-byte header, 16-byte program slots, 32-byte tones, 8-byte-unit sample sizes

Parser

crates/vab (header + extractor + SPU-ADPCM decoder); playback side engine-audio::VabBank

Confidence

Confirmed - standard Sony layout; the Legaia-specific rules are pinned by the bank-open and program-change routines (how we know) and disc-wide corpus tests

Used by

Audio stack, Media player, Asset viewer

What trips up a stock VAB reader

The format itself is documented in the PsyQ SDK, so this page covers only the parts that are Legaia-specific - the things that make a generic VAB extractor return nonsense on this disc.

• The bank is wrapped and split. The dominant carrier is the scene streaming shape, and the bank is two chunks of it: the header tables are chunk 0's payload and the sample bodies are a later chunk's, so a chunk header sits inside the bank. crates/vab::parse_header(buf, offset) takes a starting offset for the first part; vag_body_origin finds the second.
• Don't trust the filename. Extraction labels carry the +2 CDNAME numbering shift; a block name is a hint. Trust the VABp magic and the loader constant.
• Program numbers are not tone-page indices. Tone pages are packed by used program, so a program finds its page by rank. This is the single most consequential fact on this page.
• The VAG size table is 1-indexed. Slot 0 is a spacer, 0 in every retail bank; it is not a pitch or sample-rate field.
• Sample rate lives in center. A 22.05 kHz body is authored with its center key an octave high. A port that also scales by 22050/44100 plays everything an octave low.

Layout

A bank is a fixed 32-byte header, a 128-slot program table, a packed run of 16-tone pages, a 256-entry sample-size table, and then the sample bodies.

Bank header (32 bytes)

ps is the number of used programs (and so of tone pages), ts the total tone count, vs the number of sample bodies.

Whole bank

Each ProgAtr slot carries a tones byte, volume, pan and reserved words retail reuses at open time. The pages are packed, one per used program, in slot order. Sizes are in 8-byte units with [0] a spacer. The header part is 0x20 + 0x800 + 0x200·ps + 0x200 bytes; the bodies follow in a different chunk, so on disc a 4-byte chunk header sits between the size table and the first sample block.

Finding the sample bodies

The body chunk carries no magic. It is identified by length: chunk 0's payload is exactly the header part, and header_part_len + body_len == fsize. Its type byte is 0x01 in almost every bank and 0x03 in ten.

• A reader that walks straight on from the size table lands on the body chunk's header, four bytes early. The SPU-ADPCM grid shows it: a block's high nibble is a filter index and only 0..=4 is legal, and the grid four bytes on is 100% legal where the naive origin scores about chance.
• Six entries (0886, 1058, 1059, 1063, 1064, 1065) put the SEQ chunk before the body chunk, so the naive origin is thousands of bytes off and no small alignment probe recovers it. Anything that indexes a body out of a stream entry has to walk the chunks.

In the port, crates/vab has three entry points and picking the wrong one is a silent defect: parse for a bank at a known offset (its body spans are the chunk-header address), parse_in_stream for a bank inside a DATA_FIELD stream (spans already resolved), and vag_body_origin_at for the body chunk alone, walking forward from the end of the header part.

The one multi-bank archive

PROT extraction 0891 holds 206 banks - one per monster sound-effect set - in a single 5.7 MB entry that the game never loads whole. Its first sector is the index:

Each word is a bank's first sector relative to the entry; the extra final word is the archive's own sector count.

Bank i runs from start_sector[i] to start_sector[i+1], so the table is bounded by its successor exactly the way a PROT TOC entry is. Each bank is a two-chunk stream in the shape above, a zero terminator, then sector padding the builder left its previous buffer contents in.

The reader is FUN_8003E104: it bounds the bank index against the count word, subtracts the two sector bounds and shifts both left by 11. Its callers pass monster_id - 1. The index is resident at 0x801C8980 because the boot image (PROT 0895) copies 0x400 bytes of the entry's first sector there at start-up.

Program slots vs packed tone pages

A SEQ ProgramChange (or an SFX descriptor) names a program number, which indexes the 128-slot ProgAtr table directly. The tone pages that follow are packed: one 16-tone page per program whose tones byte is non-zero, ps pages in total, in slot order. A program finds its page by its rank among the used slots, not by its own number.

• Retail builds the rank map once, at bank open: the open routine writes the running used-program count into each slot's +8 reserved word, and the program-change handler reads it back as the page index (how we know).
• The open also stashes each VAG's SPU address >> 3 into the +0xC / +0xE reserved slots.
• 66 of the 218 wrapped banks - 43 of the 77 music_01 banks - use sparse program sets, so indexing pages by the raw program number mis-tones or silently drops most of their instruments.
• In the port, engine-audio::VabBank::upload expands pages into slot space.

Tone attributes: which fields retail uses

Each 32-byte tone (VagAtr) carries the standard Sony fields. A disc-wide census of every tone fixes which of them the retail data populates:

center / shift carry the sample rate

center is the key at which the tone plays at unity - SPU pitch 0x1000, 44.1 kHz - and shift raises it by shift/128 of a semitone. The header has no per-sample rate, so a 22.05 kHz body is authored with center twelve semitones above the key it should sound at. Full key-on law: audio § key-on pitch law. crates/vab's WAV writer hard-codes 22050 for standalone extraction, a separate question from playback.

The VAG size table is 1-indexed

The trailing table is 256 × u16; vag_table[1..=vs] hold each sample's size in 8-byte units, so vag_table[0] is a leading spacer. It is 0 in all 424 retail banks, and no pitch offset is derived from it - VabReport::vag_table_spacer surfaces the raw byte only.

How we know

Full spec with every field: docs/formats/vab.md. For bulk extraction of every bank to per-program WAVs, see the vab CLI in extraction tooling.

See also