re: resolve_movie_voice_region starts INSIDE the first stream, 8 of 10 multichannel regions

Found because the port refused to apply my stream assignment and did the
arithmetic instead: the running decoder's three ADV contexts sum to 3 584 000 B
against a resolved region of 3 114 352 -- 15 % too small to hold them. Two spans,
one wrong, and it was the disc side.

The gap is 238 packets exactly (487 424 B), which is what a start offset looks
like; ctx0 declares 632 packets and the resolver's leading chunk has 394.

Verified against the decoder's own byte_sizes, which cannot be fitted to: at
-238 packets to_xma_riffs yields [1294336, 1118208, 1171456], all three exactly.
It is a real boundary and not the end of a sweep -- at -300 the previous asset's
chunks appear while the three ADV sizes stay stable.

Disc-wide: 24 of 24 single-chunk regions start at a boundary; 8 of 10 three-chunk
regions start mid-stream. The defect is specific to the multichannel case.

The audit's per-movie number is an UPPER BOUND, not the clip -- its stopping rule
is the chunk count changing, and to_xma_riffs absorbs a few packets of the
previous asset first (243 reported for ADV against a true 238). Only ADV has
external ground truth.

Consequence: in those 8 movies the leading chunk is a truncated first stream, not
a spurious artefact, and anything measured on it was measured on a fragment --
including this corpus's own chunk-0 level, though the assignment survives because
its ratio test was chosen to be immune to the clipping.

The resolver is NOT patched. Why the predecessor cue's trailer lands 238 packets
into the next asset is unanswered, and a fix guessed from one movie would be
worse than a documented defect.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 08:41:22 +00:00
parent 8c71520ab8
commit 3e8235ddbd
6 changed files with 321 additions and 0 deletions

View File

@@ -149,6 +149,14 @@ FL/FR residual's **+0.918**, chunk 2 **+0.962** against BL/BR's **+0.929**.
| ctx1 · 1 118 208 | **FC** (LFE silent) |
| ctx2 · 1 171 456 | **BL, BR** |
🔴 **And the identifier this is indexed by does not resolve against the disc.** The
port refused to apply this assignment because the three contexts sum to 3 584 000 B
against a resolved region of 3 114 352. It was right to: the **region start is
wrong**, by 238 packets for `ADV` and on 8 of 10 multichannel regions disc-wide —
[`voice-region-starts-late.md`](voice-region-starts-late.md). The assignment above
still stands (the ratio test was chosen to be immune to the clipping), but chunk 0's
absolute level was measured over 62 % of its stream.
⚠️ **Reach.** Levels, not waveforms — this is an argument from three numbers
agreeing to 0.5 dB and a 1:1 structural match, not from a matched waveform. One
movie, one boot. And chunk 0 is a clipped tail, which is why the ratio test is

View File

@@ -0,0 +1,87 @@
# 🔴 `resolve_movie_voice_region` starts **inside** the first stream — 8 of 10 multichannel regions
**Classification: decoded**, against the running decoder as ground truth for one
movie and a structural check disc-wide. Found because the port agent refused to
apply a result of mine and did the arithmetic instead.
## How it surfaced
I sent the port a stream→channel assignment indexed by `byte_size`. It did not
apply it, and said why:
| | bytes |
|---|---|
| the running decoder's three `ADV` contexts | **3 584 000** |
| the resolved `ADV` voice region | **3 114 352** |
| | **15 % too small to hold them** |
Two spans, one of which was not what the other thought it was. The disc side is
this crate's, and it is the one that was wrong.
## The gap is a whole number of packets
| | |
|---|---|
| `ctx0` declares | **632** packets = 1 294 336 B |
| the resolver's leading chunk has | **394** packets = 806 912 B |
| difference | **238 packets = 487 424 B** |
A whole number of packets is what a **start offset** looks like. Corruption does not
land on 2048-byte multiples.
## Verified against the decoder, which cannot be fitted to
Stepping the region start backwards and re-running `to_xma_riffs`
([`../data/voice-region-start-clip.txt`](../data/voice-region-start-clip.txt)):
```
- 0 packets: [806912, 1118208, 1171456]
- 237 packets: [1292288, 1118208, 1171456]
- 238 packets: [1294336, 1118208, 1171456] <== the decoder's own three sizes
- 239 packets: [1296384, 1118208, 1171456]
- 300 packets: [57344, 45056, 1294336, 1118208, 1171456]
```
**238 is a real boundary, not the end of a sweep.** At 300 the *previous*
asset's chunks appear (57 344, 45 056) while the three `ADV` sizes stay exactly
stable. The stream begins there and something else ends just before it.
## Disc-wide
[`../data/voice-region-start-audit.txt`](../data/voice-region-start-audit.txt):
| region | starts at a boundary | **starts mid-stream** |
|---|---|---|
| 1 chunk | **24 / 24** | 0 |
| 3 chunks | 2 | **8 / 10** |
**The defect is specific to the three-stream (multichannel) regions.** Every
single-stream region is fine.
⚠️ **The audit's per-movie packet number is an UPPER BOUND, not the clip.** Its
stopping rule is "step back until the chunk *count* changes", and `to_xma_riffs`
absorbs a few packets of the previous asset into the first chunk before that
happens — it reports **243** for `ADV` where the decoder-verified answer is **238**.
Only `ADV` has external ground truth, so only `ADV`'s clip is exact.
## What this means for anyone consuming a voice region
🔴 **In those 8 movies the leading chunk is a truncated first stream, not a spurious
artefact.** Any consumer that drops it as "the leading chunk that matches nothing"
is discarding most of a real stream — and any measurement made *on* it (levels,
correlations against the other chunks) was made on a fragment.
⚠️ **This includes measurements in this corpus.** My own
[`intro-audio-decomposed.md`](intro-audio-decomposed.md) assignment used `ADV`'s
clipped chunk 0; the quantitative argument there survives because it quotes a
**ratio** test explicitly chosen to be immune to the clipping, but the absolute
level for chunk 0 was measured over 62 % of the stream.
## ⚠️ What is NOT fixed here
**The resolver is unchanged.** This page establishes that its start is wrong for
these regions and by how much for one of them; it does not derive the correct rule.
`voice_region_chunks.rs`'s own note says the region *"starts at the PREDECESSOR
cue's trailer"* — so the question is why that trailer lands 238 packets into the
next asset, and that is not answered. Recorded rather than patched, because a fix
guessed from one movie would be worse than a documented defect.