From 507155422bfa003fea3cbd53aeb6c9a8eb1ee2dc Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 08:43:13 +0000 Subject: [PATCH] port: the resolver starts late, and my 'duplicate tail' was a real stream My refusal to apply their weights found a defect in their decoder: resolve_movie_voice_region starts 238 packets (487424 B) inside ctx0 for ADV, and 8 of 10 three-chunk regions start mid-stream disc-wide. That re-reads one of my own measurements without touching it. I had the leading chunk as 'the TAIL of the kept stream' at r=0.998, lag flush against the end, and dropped it as a duplicate. If the streams are simultaneous and the region starts 238 packets into ctx0, the surviving fragment is ctx0's later 62%, which aligns flush against the end -- exactly what I measured. Same number, opposite meaning: a start-truncated simultaneous stream, not a duplicate. The port drops a real one. I suspected the instrument first, since they had just shown envelope correlation saturating at 0.86-0.95 across stream/channel pairs. Tested on the dialogue: r = 1.0000 at zero offset, -0.08..+0.08 elsewhere. It localises sharply; their saturation is concurrent streams at zero lag, a different regime. So the tool was sound and the error was entirely in the inference. Not fixed: including chunk 0 needs their corrected span (they say do not extend blind -- only ADV's clip is known) or an alignment decision I would be inventing, since the chunk is missing its head. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 55 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 788e5a3f..6587cd5d 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -127 sections. Search this before re-deriving anything. +128 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) @@ -138,6 +138,7 @@ dies, which is what this file is for. * [My rendered pulse, counted in their units — and #4 refutes the voice value without fixing it](#my-rendered-pulse-counted-in-their-units--and-4-refutes-the-voice-value-without-fixing-it) * [The voice export now carries every qualifying stream — and a unity sum was refused by our own check](#the-voice-export-now-carries-every-qualifying-stream--and-a-unity-sum-was-refused-by-our-own-check) * [Their stream assignment does not fit my region — weights NOT applied](#their-stream-assignment-does-not-fit-my-region--weights-not-applied) +* [The resolver starts late, and my "duplicate tail" was a real stream all along](#the-resolver-starts-late-and-my-duplicate-tail-was-a-real-stream-all-along) ## P0 — the exporter, 2026-08-28 @@ -7445,3 +7446,55 @@ of 0.9s reads as a strong finding and is the opposite. **Sample-level correlatio returns ≈ 0**, because the XMA decode's framing offset is unknown. I have used envelope correlation as my main audio instrument all fortnight; that it saturates where the content shares timing is a limit I did not know it had. + +## The resolver starts late, and my "duplicate tail" was a real stream all along + +My refusal to apply their weights found a defect in their decoder: +**`resolve_movie_voice_region` starts inside the first stream.** For `ADV`, ctx0 +declares 632 packets (1 294 336 B) and the resolver's leading chunk is 394 +(806 912 B) — **late by exactly 238 packets, 487 424 B**. A whole number of +packets, so an offset rather than corruption; extending by 238 makes +`to_xma_riffs` yield all three declared sizes. Disc-wide, 24/24 single-chunk +regions are fine and **8 of 10 three-chunk regions start mid-stream**. + +### 🔴 Which re-reads a measurement of mine, without touching the measurement + +This port measured the leading chunk as *"the TAIL of the kept stream"* — +envelope correlation r=0.998, lag flush against that stream's end — and dropped it +as an understood duplicate. + +**The correlation was right and the conclusion was wrong.** If the three streams +are simultaneous and the region starts 238 packets into ctx0, the surviving +fragment is ctx0's *later* 62 %, which aligns with the later part of the others — +**flush against the end**. That is precisely what I measured. Same number, and it +means the opposite of what I read into it: not a duplicate tail to discard, but a +start-truncated *simultaneous* stream. **The port has been dropping a real stream.** + +⚠️ I first suspected the instrument, because they had just shown envelope +correlation saturating at 0.86–0.95 across every stream/channel pair. Tested on +the actual dialogue: a 30 s window against other windows of the same take gives +**r = 1.0000** at zero offset and **−0.08 … +0.08** everywhere else. It localises +sharply. Their saturation is a different regime — *concurrent* streams sharing +timing at zero lag — and does not reach a lag search over one track. + +So the instrument was sound, its control was adequate, and the error was entirely +in the inference. That is a less comfortable finding than a broken tool: there was +nothing to fix, only something I concluded. + +### Not fixed here, deliberately + +The port still drops chunk 0. Including it correctly needs one of two things I do +not have: + +* **the corrected span** — theirs, and they explicitly say not to extend blind: + `ADV` is start − 238×2048, but for the other seven affected regions the exact + clip is **unknown**, their audit's figure being an upper bound (243 for `ADV` + where the truth is 238); +* **or an alignment decision** — chunk 0 is missing its *head*, so summing it from + sample 0 would be wrong by 84.5 s against 137.3 s. Aligning it flush to the end + is what the measurement implies, and implementing that on my own authority is + the invention the last twenty rounds have been about not making. + +✅ The assignment itself still stands — their ratio test was chosen to be immune to +the clipping — but ⚠️ chunk 0's absolute level was measured over 62 % of its +stream, so its 0.05 dB agreement is luckier than it reads.