Closes the open question at the bottom of slb-data-offset.md. X = (cumulative start of the .pNN segment holding the wave) mod 2048 The XMA packet grid is 2048-aligned inside each individual segment file, but the .pak TOC addresses entries in the flat concatenation at offsets that are themselves multiples of 2048. The segment files are not multiples of 2048 long, so each join shifts the grid by size % 2048 — and the four disc-wide values are exactly the running sums: 1392 = |p00| % 2048; 1468 = +76; 1600 = +132; 1728 = +128 Exact for 7620/7620 banks with a RIFF and 1163/1163 RIFF-less ones via their seek chunk, 0 mismatches. Supersedes both heuristics (the 99.62 % packet scan and the 99.97 % seek-residue rule) and dissolves the 28 ties. The refutation test — an entry straddling a segment join must show two phases in one file — passes on all 3 straddlers. The leading bytes are the previous bank's audio, not a header: byte diversity per offset is indistinguishable from a known packet (101.06 vs 101.90, no fixed field anywhere), the seek packet counts chain exactly across consecutive entries, and the inter-entry bytes no TOC entry claims are 1903/1928 non-zero. Also recorded: the real bank header layout (id, block size 0x800, header size in blocks, XMAWAVEFORMAT), and the loader search — a null result. None of the four values exists as an immediate, a table or a float anywhere in default.xex, which is what a pack-time artifact predicts. Sound subsystem addresses mapped for the next pass. Withdraws the 🟡 "most banks declare more data than they store" finding: declared data sizes are exact (260/260), the bytes are just outside the TOC window. Also withdraws my own "the header is unique, so nothing is shared" inference — the windows tile, they do not overlap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE