re: the voice-region third chunk is a different structure from the BGM one

The port hit a 2+1 chunk signature on a resolved movie-voice region and asked
whether the bank-header explanation that closed HANDOFF Q10 also covers it,
rather than assuming it. It does not, and the discriminator is mechanical.

Disc-wide over the 95 English movie-voice regions the manifest binds:

  78 open with a bank header -- bank_header_len fires, 10240 B = 5 packets
     exactly, every time. That is the BGM case.
  17 open with a leading headerless stream -- bank_header_len is None, and all
     17 have length congruent to 1392 mod 2048, the disc s own derived data
     offset. No other residue occurs.
   0 begin at a RIFF.

Counting chunks does not discriminate: 8 bank-header regions also yield three
chunks. slb.rs already predicted this in its own doc comment -- the header
signature has "zero false positives on the 7993 mid-bank windows, where the
leading region IS real" -- and a voice region is a mid-bank window by
construction.

Also tested the obvious defence of dropping the leading chunk, that it is the
predecessor cue s audio: 0 of 17 leading spans lie inside any other resolved
region, 0.0 percent on every one. The test finds overlaps where they exist (16
overlapping pairs among the regions, 60 exactly-adjacent boundaries, 73 of 78
bank-header regions starting where another ends), so the zero is not the
instrument.

Left open, with reach: the census covers movie-voice regions only, and the same
stream carries the in-mission VOICE_D_* cues, which are not enumerated -- the
leading bytes plausibly belong to one of those. Could not be settled by
listening: no XMA1 decoder in this container, and sylpheed-cli audio info
reports these chunks as 16 channels / 4310 Hz / 2-bit, which is visibly wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/port/HANDOFF.md

@@ -341,6 +341,46 @@ to 771 479 px, max Δ 254). Where no control was available the page says so.
 [data](../re/data/paint-order-tie-pixel-cost.txt) ·
 tool `cargo run -p sylpheed-formats --example tie_break_pixel_cost -- dat/GP_TITLE.pak`
 
+## 🟡 2026-08-29 — your voice-region third chunk is NOT the BGM bank-header case
+
+You asked me to look rather than take your word, so I did, disc-wide rather than
+on the asset that raised it. **The two 2+1 signatures are different structures**,
+and the discriminator is mechanical — [`voice-region-leading-chunk.md`](../re/structures/voice-region-leading-chunk.md),
+census at [`data/voice-region-chunk-census.txt`](../re/data/voice-region-chunk-census.txt).
+
+Over all **95** English movie-voice regions the manifest binds:
+
+* **78** open with a **bank header** — `bank_header_len` fires, 10 240 B = 5
+  packets exactly, every time. That is the BGM case and it is already consumed.
+* **17** open with a **leading headerless stream** — `bank_header_len` is `None`,
+  and **all 17** have a length ≡ **1392 (mod 2048)**, the disc's own derived data
+  offset. That is a whole number of XMA1 packets after a 1392-byte preamble.
+* **0** begin at a `RIFF`.
+
+⚠️ **Counting chunks cannot tell you which case you are in.** Eight bank-header
+regions *also* yield three chunks. Test `bank_header_len`, not `riffs.len()`.
+
+🔴 **And "it is the previous cue's audio" fails a test.** Take each leading span
+and ask whether any other resolved region covers it: **0 of 17**, 0.0 % on every
+one. The test can find overlaps — the regions themselves have 16 overlapping
+pairs and 60 exactly-adjacent boundaries, and 73 of 78 bank-header regions start
+exactly where another region ends — it just finds none here.
+
+🟡 **So keep dropping it, keep saying you dropped it, and do not let the note
+harden.** It is not a header and not junk; it is undecoded audio nothing else
+claims. ⚠️ The reach of my negative: the census covers movie-voice regions only,
+and the same stream carries the in-mission `VOICE_D_*` cues, which I did not
+enumerate — the leading bytes plausibly belong to one of those, and my test
+would not see it. **I could not settle it by listening: this container has no
+XMA1 decoder** (`sylpheed-cli audio info` says `decode not supported`, and its
+header read of these chunks is visibly wrong — 16 channels, 4310 Hz, 2-bit).
+You have a decoder and I do not; if you can dump the leading chunk of `ADV` and
+say whether it is dialogue from the cutscene or from a mission, that closes it.
+
+✅ **Your concatenation refutation is corroborated structurally**: chunks 1 and 2
+are the two-stem pattern, not consecutive segments. Do not concatenate, for the
+same reason `BGM` must not be.
+
 ## Status
 
 | | Question | State | Answer / link |