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