Sylpheed/docs/re/structures/voice-region-starts-late.md

🔴 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):

-   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:

✅ The real population (2026-08-30, corrected)

The number this page first published — "8 of 10 three-chunk regions start mid-stream" — was not a count. The audit that produced it was cut short, the committed table ends mid-list with no summary line, and I read a partial file as a complete one. The port agent's count of 25 was right.

Redone as a census that prints its population, coverage and skips together (../data/voice-region-chunk-census.txt):

POPULATION: 104 movies in the manifest
COVERAGE:   95 resolved and read, 9 unresolved, 0 unreadable  (104 accounted for)
  1 chunk(s):  70 region(s)
  3 chunk(s):  25 region(s)

Cross-referenced against the fix's own sweep, which also ran to completion (78 unchanged + 17 fixed + 9 skipped = 104):

regions the fix changed	17
of those, three-chunk	17 — all of them
of those, one-chunk	0
three-chunk regions not affected	8 — S02A S05A S07B S11A S12A S12B S13B S15B

✅ So "the defect is specific to the multichannel regions" survives, and now has complete populations on both sides: every affected region has three chunks, and not one of the 70 single-chunk regions was touched. ⚠️ But it is not true that every three-chunk region was affected — 8 of the 25 were already starting at a boundary, which is what the 1.5 MB cap predicts, since a region only trips the filter if its span exceeds it.

📌 The original "8 of 10" was wrong in its denominator and coincidentally shares a digit with the 8 that are unaffected. Recorded because a number that survives into a later document by resembling the right answer is the worst kind.

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 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.

✅ WHY — and it is fixed (2026-08-30, later)

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.

.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.

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.