# `.slb` leading-stream data offset — 1392 was never a constant

**✅ Settled 2026-08-26, verified by decoding.** A bank's leading headerless
packet stream does not start at a fixed offset. It starts at
**`first_riff % 2048`**. `HEADERLESS_DATA_OFFSET = 1392` is the value that
offset happens to take in `<lang>\etc\`, and assuming it everywhere starts the
decode mid-packet and throws away almost all of the audio.

## The rule

XMA1 packets are 2048 bytes and the leading stream is a whole number of them
ending at the first `RIFF`. So its start is forced:

    start = first_riff % 2048

Disc-wide that lands on exactly **four** values — 1392, 1468, 1600, 1728 — all
of the form `1392 + 4k`. Across the 3 965 Japanese and 3 393 English banks with
a non-empty leading region, no other value occurs:

| | 1392 | 1468 | 1600 | 1728 |
|---|---|---|---|---|
| `eng\etc`, `eng\Movie`, `eng\Briefing` | 1 520 | — | — | — |
| `eng\Voice` | 8 | 1 873 | — | — |
| `jpn\etc` | — | 1 402 | 303 | — |
| `jpn\Briefing` | — | 71 | — | — |
| `jpn\Movie` | — | — | 61 | — |
| `jpn\Voice` | — | — | 2 033 | 95 |

It varies by **language and subdirectory**, which is why a constant derived
from `eng\etc\` looked right for years' worth of the banks anyone had reason to
open.

## Verified by decoding, not by arithmetic

The alignment argument alone proves nothing — any offset can be made to "align"
by definition. The test is whether more audio comes out. Decoded through
FFmpeg's `xma1` at mono/48 kHz, on a random sample of **140** banks that have a
non-empty leading region:

| outcome | banks |
|---|---|
| more audio at `ri % 2048` | **85** |
| byte-identical | 54 |
| less audio | **1** |

Median gain among the improved: **70×**. The 54 identical ones are the control —
they are the `eng\etc`-style banks where `ri % 2048` *is* 1392, so the rule
must and does reproduce the old behaviour exactly. Individual cases:

    eng\Voice\VOICE_TCAF_592.slb    1 506 ->  97 152 bytes   (65x)
    jpn\Voice\VOICE_TCAF_592.slb    2 910 -> 127 178 bytes   (44x)
    eng\etc\VOICE_D_452.slb        30 154 ->  30 154 bytes   (unchanged, control)

## The one counterexample

`eng\Voice\VOICE_TCAF_608.slb` decodes 2 840 bytes at 1392 and 896 at 1468.

It is worth being precise about what that is and is not. It is **not** a bank
where the old constant works and the derived offset fails: its leading region is
38 988 bytes, and *both* offsets yield well under a tenth of a second, i.e. both
fail. 1392 merely produces marginally more garbage. Whatever is wrong with this
bank is a separate defect and is **not settled** here.

## ❌ This withdraws my own claim from earlier the same day

[`sound-pak-contents.md`](sound-pak-contents.md) reported that the leading
region rule holds for "0 of 5 100 Japanese banks" and filed a backlog item
saying the Japanese banks were a different, undecoded layout. **That was wrong.**
The Japanese banks are the same format; only the offset differs. The measurement
behind it was correct — zero of them satisfy `(riff − 1392) % 2048 == 0` — but
the conclusion drawn from it was not, and the reason is instructive: I treated
`HEADERLESS_DATA_OFFSET` as a property of the format when it was a property of
the sample the format was derived from.

The same error was hiding a defect in the **English** set too: 1 873 `eng\Voice`
banks sit at 1468 and were being decoded mid-packet just as badly.

## What this does not settle

* **Why the offset takes those four values**, and what the bytes before it are.
  There is no length field in the first 64 bytes — banks open on high-entropy
  data — so the offset is derived, not read.
* **`eng\Voice\VOICE_TCAF_608.slb`**, above.
* **The 799 jpn / 696 eng banks with no `RIFF` at all** are untouched by this;
  they go down the headerless path and were not re-examined.
* Nothing here was run **in the game** — this is a decoder-side result measured
  with FFmpeg as the oracle.