fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: count the voice-region population properly -- 25 three-chunk, and 17 of them were broken

Browse Source 
Pays the debt from the truncated audit. The census prints population, coverage
and skips in the same output, and ends with an explicit END line, so a cut-short
run cannot be read as a complete one.

  POPULATION 104 movies; COVERAGE 95 resolved, 9 unresolved, 0 unreadable
  70 one-chunk regions, 25 three-chunk regions

The port's 25 was right; my '8 of 10' was not a count.

Cross-referenced against the fix's own sweep, which also ran to completion
(78 + 17 + 9 = 104): all 17 changed regions are three-chunk, none is one-chunk,
and 8 three-chunk regions were never affected -- which the 1.5 MB cap predicts,
since a region only trips the filter if its span exceeds it.

So 'the defect is specific to the multichannel regions' survives with complete
populations on both sides, while 'all three-chunk regions were broken' does not.
The original 8-of-10 was wrong in its denominator and coincidentally shares a
digit with the 8 that are unaffected, which is the kind of resemblance that
carries a dead number into a later document.

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 09:46:08 +00:00
parent 11dee240bd
commit 4c7898ef4a
4 changed files with 100 additions and 129 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
docs/re/structures/voice-region-starts-late.md
View File

@@ -50,36 +50,43 @@ stable. The stream begins there and something else ends just before it.
[`../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 real population (2026-08-30, corrected)
🔴 **THIS POPULATION IS WRONG — the audit run was cut short and I read a partial
file as a complete one.** The port agent counts **25** three-chunk regions where
this table says 10, and it is right to say both numbers cannot describe the same
set. The committed
[`../data/voice-region-start-audit.txt`](../data/voice-region-start-audit.txt) ends
mid-list at `S11A` with **no summary line** — the program never printed its totals,
which is exactly the tell I should have checked and did not.
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.
**So "8 of 10" is a ratio over an unknown fraction of the population.** What is
*not* affected: the mechanism, the `ADV` clip verified against the decoder, and the
fix's own sweep, which ran to completion and printed its totals (78 / 17 / 0 / 9).
⚠️ But the sentence "the defect is specific to the multichannel regions" rested on
this table and is now **unsupported** — it may still be true; it is not shown here.
Redone as a census that prints its population, coverage and skips together
([`../data/voice-region-chunk-census.txt`](../data/voice-region-chunk-census.txt)):
📌 This is the same trap the port hit in a `while read` loop the same day (`cargo
run` eating stdin, halving the sample silently) and the one this corpus keeps
paying for: **a silently reduced sample presenting as a complete one.** The defence
that would have caught both is stating population and coverage in the same
sentence, and refusing to read a table whose summary line is missing.
```
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)
```
⚠️ **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.
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