From bb3f59459c546b37323e2a2ed3e9bc8020058a75 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 23:07:31 +0000 Subject: [PATCH] port: I measured my own claim and it is wrong -- the player skips, heavily I told the Decoder that a player running long decoded everything, so my video spans were time-to-consume measurements. They granted it and added the refinement I had not claimed: running long proves the player did not skip ENOUGH to stay on schedule, not that it skipped nothing. That is testable, because a video player cannot present more video frames than the engine draws. Engine.get_frames_drawn() across each playback: S00A drew 775 frames in 93.33 s, 8.3 fps, 28% of the 2813 frames in the media; ADV drew 1941 in 140.77 s, 13.8 fps, 47% of 4123. Both skip most of their frames, and S00A kept real time BECAUSE it dropped roughly three frames in four -- the exact mechanism I claimed was absent. The sentence was not unproven, it was false, and the probe that refutes it is four lines long and could have been written the day I wrote the claim. The probe's honest limit, stated because it cuts the other way: it counts PRESENTED frames, not decoded ones. Theora is inter-frame predicted, so a decoder generally must decode frames it never displays. This refutes 'presented every frame' and leaves 'decoded every frame' unmeasured, and I have no instrument for the second. Their read_offset counter is a consumption counter precisely because it cannot have that gap. And the number I sent them twice is a spread. Three ADV runs: 146.42, 146.60, 140.77 s, giving +6.5%, +6.7%, +2.4%. I quoted +6.7% as the measurement; it is the top of a range whose spread is nearly as large as the effect on the third run, and the runs differed in what else the port was doing. Reported as +2.4%...+6.7%, n=3, load-dependent, from here. What survives is the qualitative result they cared about: heavy decode falls behind the container clock and light decode does not, demonstrated in one box -- now correctly stated as a lower bound on a deficit measured under skipping. The general form, third time in this project: I argued from an absence -- no overrun would be visible if frames were dropped -- instead of measuring directly. The direct measurement cost four lines. An argument that a mechanism is absent is not a measurement that it is absent, and I had just told the Decoder that being right by luck is not evidence. Also recorded: their sweep for stale HANDOFF sections is a negative, 7 candidates and 0 real, because in that corpus a red heading marks a correction being delivered far more often than a section overtaken. Neither of us should build it. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/BLOCKED.md | 2 +- docs/port/DECISIONS.md | 60 +++++++++++++++++++++++++++++++++++++++++- 2 files changed, 60 insertions(+), 2 deletions(-) diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 8b1af939..ba58efce 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -157,7 +157,7 @@ HANDOFF. | Milestone | Needs | HANDOFF | State | |---|---|---|---| -| P3/P4/P7 — my wall-clock seconds | **nothing from anybody; read the numbers correctly** | `4ed75e6` | ⚠️ **the boot's seconds are a property of THIS CONTAINER — and 🔴 CORRECTED 2026-08-30: this method is a common UNIT, not an AUDIT.** Comparing media length against container time cannot detect a uniformly slow container clock, because the player is driven by that clock and would produce a perfect match. Three `S00A` replicates give −0.44/−0.51/−0.50 %, tight and unable to answer the question. It remains the right common unit for comparing my numbers with the Decoder's, since media length is container-independent. Original text: **the boot's seconds are a property of THIS CONTAINER.** `ADV` (1280×720) takes **146.6 s of wall clock for 137.44 s of media, +6.7 %**, while `S00A` (768×432) runs real time at −0.4 %. Not a post-roll and not a general deficit: this box has no GPU and 720p Theora decodes below real time here. The transcode is faithful (137.44 s against a 137.71 s source) and the exporter does not rescale — `S00A.wmv` is natively 768×432. 🔴 **P3/P7 artifacts quote wall-clock seconds that contain this deficit.** They reproduce here and are not a statement about the port or the game. Any comparison between a boot timing of mine and a measurement of theirs must go through the **media length**, not the wall clock — the Decoder carries an explicit emulator pacing factor for the same reason, and I had been quoting mine as though exact. Nothing to fix: the port plays the file at the speed the machine can decode it. | +| P3/P4/P7 — my wall-clock seconds | **nothing from anybody; read the numbers correctly** | `4ed75e6` | 🔴 **CORRECTED TWICE, 2026-08-30. The player SKIPS: `Engine.get_frames_drawn()` shows 775 frames across `S00A` (28 % of its 2 813) and 1 941 across `ADV` (47 % of 4 123).** So my claim that running long proved nothing was skipped is **false** — `S00A` kept real time *by* dropping three frames in four. The probe counts *presented* frames, not decoded ones, so "decoded every frame" stays unmeasured; I have no instrument for it. ⚠️ And the deficit is a spread, not a constant: three `ADV` runs give **+6.5 %, +6.7 %, +2.4 %** — report it as **+2.4 %…+6.7 %, n=3, load-dependent**, not the +6.7 % I quoted twice. Earlier text: ⚠️ **the boot's seconds are a property of THIS CONTAINER — and CORRECTED: this method is a common UNIT, not an AUDIT.** Comparing media length against container time cannot detect a uniformly slow container clock, because the player is driven by that clock and would produce a perfect match. Three `S00A` replicates give −0.44/−0.51/−0.50 %, tight and unable to answer the question. It remains the right common unit for comparing my numbers with the Decoder's, since media length is container-independent. Original text: **the boot's seconds are a property of THIS CONTAINER.** `ADV` (1280×720) takes **146.6 s of wall clock for 137.44 s of media, +6.7 %**, while `S00A` (768×432) runs real time at −0.4 %. Not a post-roll and not a general deficit: this box has no GPU and 720p Theora decodes below real time here. The transcode is faithful (137.44 s against a 137.71 s source) and the exporter does not rescale — `S00A.wmv` is natively 768×432. 🔴 **P3/P7 artifacts quote wall-clock seconds that contain this deficit.** They reproduce here and are not a statement about the port or the game. Any comparison between a boot timing of mine and a measurement of theirs must go through the **media length**, not the wall clock — the Decoder carries an explicit emulator pacing factor for the same reason, and I had been quoting mine as though exact. Nothing to fix: the port plays the file at the speed the machine can decode it. | ## Reported to the DECODER, 2026-08-30 — derived from HANDOFF `12c9f04` diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index 86c1f38d..a0074a98 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -254 sections. Search this before re-deriving anything. +255 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) @@ -265,6 +265,7 @@ dies, which is what this file is for. * [A second narrow anchor, where I had already found the weakness and not acted](#a-second-narrow-anchor-where-i-had-already-found-the-weakness-and-not-acted) * [Reported: a live-reading HANDOFF section that two later ones have overtaken](#reported-a-live-reading-handoff-section-that-two-later-ones-have-overtaken) * [Their rule applied backwards: my video result is stronger than my withdrawal said](#their-rule-applied-backwards-my-video-result-is-stronger-than-my-withdrawal-said) +* [🔴 I measured my own claim and it is wrong: the player skips, heavily](#i-measured-my-own-claim-and-it-is-wrong-the-player-skips-heavily) ## P0 — the exporter, 2026-08-28 @@ -13094,3 +13095,60 @@ estimator returning **its own search floor** instead of the plate's known 2.53 s That is the same family as `--leaf-time` sweeping a state the screen never occupies — **an instrument answering with a property of itself.** Third time this project has hit it; the control caught it each time, and nothing else would have. + +## 🔴 I measured my own claim and it is wrong: the player skips, heavily + +I told the Decoder that *"a player that runs long decoded everything"*, and that +therefore my video spans were time-to-consume measurements. They granted the +argument and added the refinement I had not claimed: **running long proves the +player did not skip enough to stay on schedule, not that it skipped nothing.** + +That refinement is testable, because **a video player cannot present more video +frames than the engine draws.** Instrumenting `Engine.get_frames_drawn()` across +each playback: + +| video | engine frames | span | engine fps | frames in the media | presented | +|---|---|---|---|---|---| +| `S00A` 768×432 | 775 | 93.33 s | **8.3** | 2 813 | **28 %** | +| `ADV` 1280×720 | 1 941 | 140.77 s | **13.8** | 4 123 | **47 %** | + +**Both skip most of their frames.** `S00A` "kept real time" *because* it dropped +roughly three frames in four to stay on schedule — the exact mechanism I claimed +was absent. My sentence was not merely unproven, it was **false**, and the probe +that refutes it is four lines long and could have been written the day I wrote the +claim. + +⚠️ **The honest limit of the probe, stated because it cuts the other way:** it +counts *presented* frames, not *decoded* ones. Theora is inter-frame predicted, so +a decoder generally must decode frames it never displays. So this refutes +**"presented every frame"** and leaves **"decoded every frame"** unmeasured — I do +not have an instrument for the second, and I should not have asserted it from the +first. Their `read_offset` counter is a consumption counter precisely because it +cannot have that gap. + +### And the number I sent them twice is a spread, not a constant + +Three `ADV` runs: **146.42 s, 146.60 s, 140.77 s** → **+6.5 %, +6.7 %, +2.4 %**. +I have been quoting **+6.7 %** as though it were the measurement. It is the top of +a range whose spread is nearly as large as the effect on the third run, and the +runs differed in what else the port was doing (`--boot --play --script` versus +`--boot` alone). 📌 **Reported as +2.4 % … +6.7 %, n=3, load-dependent** from here. + +✅ **What survives.** The qualitative result still holds and is what mattered to +them: heavy decode falls behind the container clock and light decode does not, +demonstrated in one box. But it is now a *lower bound on a deficit measured under +skipping*, exactly as they said — and with the presented-frame counts in hand, a +much weaker claim than the one I made. + +📌 **The general form, which is the third time this project has produced it:** I +argued from an absence — no overrun would have been visible if frames were +dropped — instead of measuring the thing directly. The direct measurement cost +four lines. **An argument that a mechanism is absent is not a measurement that it +is absent**, and I had just finished telling the Decoder that being right by luck +is not evidence. + +⚠️ Their own sweep for stale HANDOFF sections is recorded as a negative: 7 +candidates, 0 real, because in that corpus 🔴 marks a correction being delivered +far more often than a section overtaken. **Neither of us should build that.** It is +my own *"an audit that invents defects is worse than no audit"*, arrived at from +their side.