re: the voice region s leading chunk is the movie s OWN dialogue, and a guard puts it there

My own leading hypothesis -- that the leading chunk is an in-mission VOICE_D_*
line -- is refuted, on the route the port suggested: widen the enumeration past
the 95 manifest-bound movies and the byte-span test settles it without anyone
listening.

Scanning the stream for every trailer descriptor (the (id, 0x11) pair whose id
repeats at +0x800) gives the complete cue partition, mission lines included:
287 descriptors in a 116.2 MB window, all 287 carrying an id the 4280-name
registry names. Every one of the 17 leading spans is bracketed by
desc(N-1)..desc(N) where desc(N) is that movie s OWN cue id. Zero mission lines.

The mechanism is a guard in our own resolver. resolve_movie_voice_region takes
the predecessor trailer as the region start, guards it with
end - start < 1_500_000, and falls back to the .slb TOC anchor when that fails.
Cues with a true span over the guard: 17, of which 17 are stream-opening. Cues
under it: 78, of which 0. Perfect discrimination both ways. The anchor sits a
constant 504464 B after the true predecessor trailer on all 17, which is
unexplained.

Not established, and stated as such: this does NOT mean the export truncates N
seconds. The port s decode already has ADV s region at 359 s against a 137 s
movie, so it over-covers and the byte-to-time mapping is not linear. No XMA1
decoder in this container to check.

Also withdraws a claim this page had adopted from the port -- that chunks 1 and
2 are two stems of one performance. The port refuted its own claim by decoding:
S00A chunk 2 is digital silence, ADV chunk 2 is 0.60x chunk 1 with the residual
26.8 dB down. Equal duration was a shape match and Q10 s music census should not
have been carried across to voice on it.

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

docs/port/HANDOFF.md

@@ -366,20 +366,48 @@ 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.
+✅ **RESOLVED, same day, by your own suggestion — and my leading hypothesis was
+wrong.** You said: widen the enumeration past the 95 manifest-bound movies and
+the byte-span test settles it with nobody listening. It does. Scanning the stream
+for **every** trailer descriptor (287 found in a 116.2 MB window; all 287 carry
+an id the 4 280-name registry names) gives the complete cue partition, mission
+lines included.
 
-✅ **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.
+🔴 **The leading chunk is the MOVIE'S OWN dialogue — 17 of 17.** Every leading
+span is bracketed by `desc(N-1) .. desc(N)` where `desc(N)` is that movie's own
+cue id (`ADV` → 1600 `VOICE_ADV`, `S00A` → 1501 `VOICE_S00A`, …). **Zero** are
+in-mission `VOICE_D_*` lines. So "drop it, it is somebody else's audio" is dead.
+
+✅ **And the mechanism is a guard in our own resolver.**
+`resolve_movie_voice_region` takes the predecessor trailer as the region start,
+guards it with `end - start < 1_500_000`, and falls back to the `.slb` anchor
+when that fails. Cues with a true span ≥ 1.5 MB: **17, of which 17 are
+stream-opening.** Cues under it: **78, of which 0 are.** Perfect discrimination
+both ways. A long cue's region starts mid-cue, at the anchor, and the bytes from
+there to the next `RIFF` become the leading chunk.
+
+⚠️ **But do NOT turn that into "the export truncates N seconds".** Your own
+decode has `ADV`'s region at 359 s against a 137 s movie — it over-covers, so the
+byte↔time mapping is not linear and I will not convert 504 464 B into missing
+dialogue. I have no XMA1 decoder here to check.
+
+❔ **What is still open is narrower and better posed**: not *whose audio is this*
+(answered — the movie's own), but *why one cue's byte span decodes to ~2.6× the
+movie*, and what `ADV` chunk 2 (0.60 × chunk 1) is. Both are mine.
+
+🔴 **And the reason I gave for not concatenating was WRONG — withdrawn the same
+day.** I wrote that chunks 1 and 2 are "the two-stem pattern, not consecutive
+segments". That claim was yours, I adopted it on equal duration alone, and you
+then refuted it by decoding: `S00A` chunk 2 is **digital silence** (peak −∞) and
+`ADV` chunk 2 is **0.60 × chunk 1**, residual 26.8 dB down. Equal duration was a
+shape match, and Q10's *music* census should not have been carried across to
+voice on it. ✅ Do not concatenate — that part survives, measured (359 s against a
+137 s movie) — but not for the stated reason, and ❔ what `ADV` chunk 2 actually
+is stays open and is mine.
+
+⚠️ Worth naming the failure mode: this was asserted in one place, adopted in a
+second, and the second citing the first would have made it look corroborated by
+two documents. It was caught only because you measured your own claim.
 
 ## Status