port: external ground truth for all 25 three-chunk regions -- none truncated
The Decoder has no external check on the regions beyond ADV. One reference owes nothing to their crate: each movie's own duration from its WMV. A start-truncated stream must decode shorter than its movie -- ADV's was 38% short before the fix. Dumped every region and decoded every chunk: 25 three-chunk regions, 75 chunks, 0 more than 5% short, largest deviation 1.78%. No region is still truncated, and the reference is genuinely external. Flags a population discrepancy: their page says 8 of 10 three-chunk regions start mid-stream; I find 25 three-chunk regions on this disc. Reported, not resolved. My first run reported '0 of 13' and there were 25 -- cargo run inside a while read loop consumes stdin, so every second movie was eaten and the covered set was positions 1,3,5,7... The result was correct for what it measured and the population was half what the sentence implied. That is the truncated-log trap arriving in my own shell loop; I caught it only by comparing against a count from one command earlier. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
@@ -9,7 +9,7 @@ dies, which is what this file is for.
|
||||
|
||||
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
|
||||
|
||||
132 sections. Search this before re-deriving anything.
|
||||
133 sections. Search this before re-deriving anything.
|
||||
|
||||
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
|
||||
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
|
||||
@@ -143,6 +143,7 @@ dies, which is what this file is for.
|
||||
* [The voice export is complete — new pin, and the cause was a "within one bank" cap](#the-voice-export-is-complete--new-pin-and-the-cause-was-a-within-one-bank-cap)
|
||||
* [The positional weights are applied — keyed by byte size, so the key is a check](#the-positional-weights-are-applied--keyed-by-byte-size-so-the-key-is-a-check)
|
||||
* [🔴 Unexplained: `verify-menu-audio`'s dead-press check has started failing](#unexplained-verify-menu-audios-dead-press-check-has-started-failing)
|
||||
* [External ground truth for every three-chunk region — the movies' own durations](#external-ground-truth-for-every-three-chunk-region--the-movies-own-durations)
|
||||
|
||||
<!-- /INDEX -->
|
||||
## P0 — the exporter, 2026-08-28
|
||||
@@ -7656,3 +7657,50 @@ control, would not have this failure mode.
|
||||
Filed rather than patched: silencing it would remove the only check that a dead
|
||||
press stays silent, and I would rather have a failing check than a passing one
|
||||
whose premise I have stopped believing.
|
||||
|
||||
## External ground truth for every three-chunk region — the movies' own durations
|
||||
|
||||
They have no external check on the 15 regions beyond `ADV`, and no route to one
|
||||
that does not go through the port or the emulator. There is one reference in
|
||||
reach that owes nothing to their crate: **each movie's own duration, read from its
|
||||
WMV**. A start-truncated stream must decode *shorter than its movie* — `ADV`'s was
|
||||
84.55 s against 137.71, a 38 % deficit.
|
||||
|
||||
Dumping every region with their `adv_voice_dump` and decoding each chunk:
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| three-chunk regions found | **25** |
|
||||
| chunks decoded | **75** |
|
||||
| chunks more than 5 % short of their movie | **0** |
|
||||
| largest deviation of any chunk | **1.78 %** |
|
||||
|
||||
✅ **No region is still truncated.** The reference is external — the durations come
|
||||
from `/disc/dat/movie/*.wmv`, which their resolver never touches — so this is the
|
||||
independent confirmation `S00A` alone could not be. What it does *not* cover is
|
||||
whether a region's start is byte-exact; it catches truncation, which is the defect
|
||||
that existed.
|
||||
|
||||
🟡 **A population discrepancy worth their attention.** Their page says *"8 of 10
|
||||
three-chunk regions start mid-stream"*. I find **25** three-chunk regions on this
|
||||
disc, not 10. Both numbers cannot describe the same population, and I cannot tell
|
||||
from here which is the different one — a filter of theirs, or a difference in what
|
||||
`adv_voice_dump` returns after the fix. Reported, not resolved.
|
||||
|
||||
### 🔴 My first run silently covered half of them and said it was clean
|
||||
|
||||
It reported *"0 of 13 three-chunk regions have a short chunk"*. There were 25.
|
||||
`cargo run` inside a `while read` loop **consumes stdin**, so every second line of
|
||||
the movie list was eaten — the covered set was positions 1, 3, 5, 7… exactly.
|
||||
|
||||
The result was *correct for what it measured* and the population was half what the
|
||||
sentence implied. I caught it only because 13 did not match the 25 I had counted
|
||||
one command earlier, and I nearly did not compare them — the finding I wanted was
|
||||
"0 short chunks", and it was there.
|
||||
|
||||
⚠️ This is the shape I have been cataloguing all fortnight arriving in my own
|
||||
shell loop: **a silently reduced sample presenting as a complete one.** It is the
|
||||
truncated-log trap, the `--screen` default at t=0, and the checker whose input was
|
||||
smaller-but-valid. Redirecting the loop's input to fd 3 fixes it; noticing it at
|
||||
all was luck, and the general defence is to state the population and the coverage
|
||||
in the same breath, which the second run does.
|
||||
|
||||
Reference in New Issue
Block a user