formats: drop the 1.5 MB cap that truncated 17 voice regions' first stream

The cause, and the fix, with a disc-wide check.

resolve_movie_voice_region picks start = the predecessor cue's trailer, then
filtered it with 'end - s < 1_500_000' -- 'only within one bank'. ADV's
predecessor sits 3 618 816 B before end, so the filter rejected it and start fell
back to anchor, which is a TOC offset and not a stream boundary. That explains
the shape of the defect exactly: it strikes regions larger than 1.5 MB, which is
why the three-stream multichannel regions are hit and single-stream ones never
are. 17 of 95 resolving movies took the fallback.

ADV's predecessor trailer at 433 425 776 plus 17 040 B of descriptor and padding
is 433 442 816 -- the -238-packet start measured against the decoder, to the byte.

Dropping the cap: unchanged 78, fixed cleanly 17, changed in any other way ZERO.
In all 17 the only difference is a larger first chunk with every later chunk
byte-identical, which is what a corrected start looks like and what pulling in a
neighbouring asset does not.

Regression test pinned to the RUNNING DECODER's byte_sizes rather than to this
crate's own output. That is the point of it: every internal check passed happily
while a third of a stream was missing, so only an external number could have
caught this class of bug.

sylpheed-formats: 136 tests pass, 0 fail (the one still running at commit time is
an unrelated long mesh test).

Exact clips for the other 16 are not independently verified -- the sweep is
strong but ADV is the only one with a decoder measurement behind it.

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:55:47 +00:00
parent fb6095ae3a
commit 3dbfa320ae
8 changed files with 351 additions and 10 deletions

View File

@@ -0,0 +1,36 @@
ADV today [806912, 1118208, 1171456]
prop [1294336, 1118208, 1171456] first chunk GREW, tail identical
S00A today [1323008, 1263616, 98304]
prop [1810432, 1263616, 98304] first chunk GREW, tail identical
S01A today [1153024, 1390592, 1552384]
prop [1640448, 1390592, 1552384] first chunk GREW, tail identical
S02B today [430080, 505856, 866304]
prop [919552, 505856, 866304] first chunk GREW, tail identical
S02C today [1867776, 1349632, 2390016]
prop [2353152, 1349632, 2390016] first chunk GREW, tail identical
S03A today [251904, 540672, 739328]
prop [741376, 540672, 739328] first chunk GREW, tail identical
S04B today [555008, 870400, 991232]
prop [1044480, 870400, 991232] first chunk GREW, tail identical
S06A today [350208, 294912, 860160]
prop [839680, 294912, 860160] first chunk GREW, tail identical
S06B today [606208, 874496, 1449984]
prop [1093632, 874496, 1449984] first chunk GREW, tail identical
S07A today [503808, 473088, 1040384]
prop [993280, 473088, 1040384] first chunk GREW, tail identical
S09B today [176128, 571392, 843776]
prop [665600, 571392, 843776] first chunk GREW, tail identical
S11C today [741376, 1075200, 1107968]
prop [1228800, 1075200, 1107968] first chunk GREW, tail identical
S12C today [1843200, 1273856, 2502656]
prop [2328576, 1273856, 2502656] first chunk GREW, tail identical
S13A today [401408, 585728, 962560]
prop [890880, 585728, 962560] first chunk GREW, tail identical
S14A today [1816576, 1634304, 2541568]
prop [2301952, 1634304, 2541568] first chunk GREW, tail identical
S15A today [253952, 618496, 1122304]
prop [743424, 618496, 1122304] first chunk GREW, tail identical
S15C today [929792, 1101824, 1384448]
prop [1417216, 1101824, 1384448] first chunk GREW, tail identical
unchanged 78 fixed-cleanly 17 would-break 0 skipped 9

View File

@@ -45,3 +45,31 @@ decoder wants [1294336, 1118208, 1171456] = 3584000 B payload
# will happily absorb a few packets of the PREVIOUS asset into the first chunk
# before that happens -- for ADV it reports 243 where the decoder-verified
# answer is 238. Only ADV has external ground truth.
# ---------------------------------------------------------------------------
# WHY (examples/voice_region_start_why.rs), and the FIX (cap_sweep)
#
# The resolver picks start = the predecessor cue's trailer, then filters it with
# .filter(|&s| s < end && end - s < 1_500_000)
# "only within one bank (~1.5 MB), else this is the first cue in its block and
# the audio starts at the anchor itself".
#
# ADV's predecessor sits 3 618 816 B before `end`. The filter REJECTS it, and the
# start falls back to `anchor` -- a TOC offset, not a stream boundary:
#
# movie id anchor pred(before) span chosen
# ADV 1600 433930240 433425776 3618816 anchor <- REJECTED
#
# predecessor 433425776 + 17 040 B of descriptor/padding = 433442816,
# which is exactly the -238 packet start measured against the decoder.
#
# 17 of 95 resolving movies hit this. Reading from the predecessor instead:
#
# anchor (today) start 433930240 -> [806912, 1118208, 1171456]
# predecessor (proposed) start 433425776 -> [1294336, 1118208, 1171456] MATCHES
#
# DISC-WIDE CONSEQUENCE of dropping the cap (voice-region-cap-sweep.txt):
# unchanged 78 fixed-cleanly 17 would-break 0 skipped 9
# In all 17 the first chunk GROWS and every later chunk is byte-identical --
# which is what a corrected start looks like, and what pulling in a neighbouring
# asset does not.

View File

@@ -77,11 +77,54 @@ 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
## ✅ WHY — and it is fixed (2026-08-30, later)
**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.
The predecessor trailer does **not** land 238 packets into the next asset. It is
never consulted: a second condition on the start filter threw it away.
```rust
.filter(|&s| s < end && end - s < 1_500_000) // "only within one bank"
```
`ADV`'s predecessor sits **3 618 816 B** before `end`, so the filter rejects it and
`start` falls back to `anchor` — **a TOC offset, which is not a stream boundary at
all**. That is the whole mechanism, and it explains the shape of the defect
exactly: it strikes regions *larger than 1.5 MB*, which is why the multichannel
three-stream regions are hit and the single-stream ones never are.
| | |
|---|---|
| `ADV` predecessor trailer | 433 425 776 |
| + descriptor and padding | 17 040 B |
| = stream start | **433 442 816** — the 238-packet start, to the byte |
**17 of the 95 resolving movies** took the fallback.
### ✅ The fix, and its disc-wide check
Dropping the cap (keeping `s < end`):
```
anchor (today) start 433930240 -> [806912, 1118208, 1171456]
predecessor (proposed) start 433425776 -> [1294336, 1118208, 1171456] MATCHES
```
| | movies |
|---|---|
| unchanged | **78** |
| fixed cleanly — first chunk grows, every later chunk byte-identical | **17** |
| **changed in any other way** | **0** |
Zero. In all 17 the *only* difference is a larger first chunk, which is what a
corrected start looks like and what pulling in a neighbouring asset does not.
[`../data/voice-region-cap-sweep.txt`](../data/voice-region-cap-sweep.txt).
**Landed** in `media.rs`, with a regression test pinned to the **running decoder's**
byte_sizes rather than to this crate's own output —
`adv_voice_region_holds_all_three_decoded_streams`. That distinction is the point:
every internal check passed happily while a third of a stream was missing, so only
an external number could have caught it.
⚠️ **Exact clips for the other 16 are still not independently verified.** The sweep
shows their first chunk grows and their tails are untouched, which is strong; but
`ADV` is the only one with a decoder measurement behind it.