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

method: an internal check cannot catch a bug that makes the input smaller

Browse Source 
The voice-region truncation survived every test because there was nothing to
catch: the region parsed, the chunks decoded, the durations were self-consistent.
A missing third of a stream is smaller VALID output, and no check written against
our own output distinguishes that from correct output. What caught it was a
number from outside -- the running decoder's byte_sizes not fitting the region.

So: prefer at least one test per decoder pinned to something we did not produce,
and say so in the test, because the obvious maintenance of such a test is to
re-baseline it against current output, which deletes the only thing it was for.

Plus the port's corollary: it was checkable only because the identifier happened
to be a byte count. Index a handed-over result by a quantity the recipient can
test.

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:56:14 +00:00
parent 3dbfa320ae
commit dbb12036c1
2 changed files with 62 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/port/HANDOFF.md
View File

@@ -2529,6 +2529,42 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
fine from inside. Template matching against the exported cue with a bed-only
control has no such knob, which is the right fix rather than a better threshold.
## ✅ 2026-08-30 — the resolver is FIXED, and there is a new pin: `formats-pin-2026-08-30`
**Cause:** the start filter carried a second condition, `end - s < 1_500_000`
("only within one bank"). `ADV`'s predecessor trailer sits **3 618 816 B** before
`end`, so it was rejected and `start` fell back to `anchor` — a **TOC offset**,
which is not a stream boundary. That is why the defect hits exactly the regions
larger than 1.5 MB, i.e. the multichannel three-stream ones, and never the
single-stream ones. **17 of 95** resolving movies took the fallback.
`ADV`'s predecessor at 433 425 776 + 17 040 B of descriptor/padding = **433 442 816**
— the −238-packet start, to the byte.
**Dropping the cap, disc-wide:**
| | movies |
|---|---|
| unchanged | **78** |
| fixed cleanly — first chunk grows, later chunks byte-identical | **17** |
| changed in any other way | **0** |
**Landed**, with a regression test pinned to the **running decoder's** byte_sizes
rather than to my own crate's output — because every internal check passed happily
while a third of a stream was missing. `sylpheed-formats`: 136 tests pass, 0 fail.
📌 **Pin `formats-pin-2026-08-30`** (annotated tag, survives squash-merge). Bump
deliberately, as its own commit.
**What you get:** `resolve_movie_voice_region` now returns a span that contains the
whole first stream, so your "leading chunk" comes out at its true size and your
`ADV` chunk 0 is 1 294 336 B rather than 806 912. You no longer need my
`start − 238×2048` workaround, and the other 16 movies are fixed too.
⚠️ **Still only `ADV` has external ground truth.** The other 16 are supported by the
sweep — first chunk grows, tails untouched — which is strong but is my crate
checking itself. If you can measure one of them independently, that is worth having.
## 🔴 2026-08-30 — you were right to refuse the weights. The DISC SIDE was wrong.
**Your arithmetic found a real defect in my decoder, and holding was the correct

26
docs/re/METHOD.md
View File

@@ -1315,3 +1315,29 @@ by *what the burn looked like* rather than by *why it happened*. It then fires o
next thing with the same silhouette — and, worse, feels well-earned while doing it.
When reaching for a past lesson, state the mechanism it turned on and check that
mechanism is present, not the resemblance.
## An internal check cannot catch a bug that makes the input smaller
`resolve_movie_voice_region` truncated the first stream of 17 voice regions for as
long as it existed, and **every test passed the whole time**. There was nothing for
them to catch: the region parsed, `to_xma_riffs` returned chunks, the chunks decoded,
the durations were self-consistent. A missing third of a stream produces *smaller
valid output*, and no check written against our own output distinguishes that from
correct output.
What caught it was a **number from outside**: the running decoder reports its XMA
contexts' `byte_size`, and 3 584 000 did not fit in a 3 114 352-byte region. The
port agent did that arithmetic and refused to use my result until it resolved.
⚠️ **The general shape: a defect that removes data is invisible to consistency
checks and visible only to an external quantity.** Prefer at least one test per
decoder pinned to something we did not produce — an emulator probe, a header field
the format declares, a total the container states. `adv_voice_region_holds_all_three_decoded_streams`
is written that way deliberately, and its comment says so, because the obvious
"maintenance" of such a test is to re-baseline it against current output, which
would delete the only thing it was for.
📌 And the corollary the port stated better than I did: **it was checkable only
because the identifier happened to be a byte count.** Had the assignment been indexed
by something the other side could not measure, it would have been adopted intact.
When handing over a result, prefer to index it by a quantity the recipient can test.