From 40cf9b5025438f292da576ed33ff4d7d294ee53d Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 23:08:48 +0000 Subject: [PATCH] method: land the pacing re-correction itself The previous commit's message described this change but an exact-match miss meant only the ui-keyframe-time-unit.md half landed. This is the METHOD half: their argument was refuted by their own frame count (28 % and 47 % of frames presented), so my correction of a correct entry is withdrawn and the original reading stands. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/METHOD.md | 42 ++++++++++++++++++++++++++++++------------ 1 file changed, 30 insertions(+), 12 deletions(-) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 014ccb76..c753448b 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -2469,19 +2469,37 @@ elapsed clock time stays on schedule by doing less work: a uniformly starved clo presents fewer frames per real second and still finishes in exactly the media's duration. **The failure produces the appearance of success.** -🔴 **CORRECTED 2026-08-30, same day — I described their measurement as the -skippable kind and that was wrong.** They pointed out that the *overrun is itself -the evidence*: a player dropping frames to keep up finishes **early or on time**, -and theirs ran **146.6 s for 137.44 s of media**. Running long is inconsistent with -having skipped its way back onto schedule. So their `ADV` +6.7 % and `S00A` −0.5 % -belong to the time-to-consume class after all — the class endorsed below — and the -withdrawal applies only to the *audit* use, not to the load-starvation finding. +🔴 **CORRECTED TWICE, and the second correction restores the first reading.** +They argued the overrun was itself proof nothing was skipped — a player dropping +frames finishes early or on time, and theirs ran **146.6 s for 137.44 s of media**. +I accepted that and rewrote this entry. **Then they measured it**, counting the +frames the engine actually drew: -⚠️ One refinement they did not claim and I would not grant: running long proves the -player did not skip **enough to stay on schedule**, not that it skipped *nothing*. -Any dropping that did occur makes the true decode time longer still, so **+6.7 % is -a lower bound on the deficit**. That cuts in favour of their conclusion, not -against it. +| | engine frames | span | frames in media | presented | +|---|---|---|---|---| +| `S00A` 768×432 | 775 | 93.33 s | 2 813 | **28 %** | +| `ADV` 1280×720 | 1 941 | 140.77 s | 4 123 | **47 %** | + +**The player skips, heavily.** `S00A` held real time *because* it dropped three +frames in four — the mechanism the argument said was absent. So the reading above +was right, their argument was wrong, and **my correction of it was wrong**. + +⚠️ **I corrected a correct entry on an argument, having just written on this page +that a consumption counter is what makes an audit.** Their inference sounded right +and I did not ask what would measure it; the measurement was four lines. **An +argument from an absence — "no overrun would be visible if frames were dropped" — +is not evidence, and accepting one is the same error as making one.** + +📌 Their own limit, which they stated and I would not have caught: the probe counts +**presented** frames, not **decoded** ones. Theora is inter-frame predicted, so a +decoder must decode frames it never shows. This refutes *"presented every frame"* +and leaves *"decoded every frame"* unmeasured. `read_offset` is a consumption +counter precisely because it cannot have that gap. + +🔴 **And their figure is a spread, not a value**: three `ADV` runs gave **146.42, +146.60, 140.77 s** → **+2.4 %…+6.7 %, n=3, load-dependent**. It reached this corpus +twice as a flat "+6.7 %". The qualitative finding — heavy decode falls behind, +light does not — survives as a **lower bound measured under skipping**. ⚠️ My audio measurement survives that objection, and it is worth being precise about *why*, because the two look alike: `input_buffer_read_offset` is a