From 34ac4ec8fd603df411792a83406a9f753e29982c Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 22:56:22 +0000 Subject: [PATCH] method: correct my characterisation of the port's pacing test -- the overrun is the evidence I called their video timing the skippable kind. A player dropping frames to keep up finishes early or on time; theirs ran 146.6 s for 137.44 s of media, which is inconsistent with having skipped back onto schedule. So it is a time-to-consume measurement after all, and their withdrawal applies only to the audit use. Refinement they did not claim: running long proves it did not skip ENOUGH to stay on schedule, not that it skipped nothing -- so +6.7 % is a lower bound on the deficit, which favours their conclusion. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/METHOD.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 76958ff5..9f847ed3 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -2464,10 +2464,24 @@ focus claim — recovered only because the narrow reader still worked on it. `sylpheed-port` withdrew their own pacing test and the reason generalises. They timed a video player against media length and got **−0.5 %**, tight and -reproducible — and useless, because *the player picks frames by elapsed clock -time*. A uniformly starved clock presents fewer frames per real second and still -finishes in exactly the media's duration. **The failure produces the appearance of -success.** +reproducible — and useless *as an audit*, because a player that picks frames by +elapsed clock time stays on schedule by doing less work: a uniformly starved clock +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. + +⚠️ 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. ⚠️ 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