From df08b2fddf0035d23031ea220b74a95872245e21 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 22:37:32 +0000 Subject: [PATCH] re: the 27.6 fps rate is not separated from this container running the guest slow sylpheed-port warned that wall clock on their box carries a +6.7 % decode deficit and that cross-agent timing comparisons must go through media length. It reaches this page's headline: a guest at ~92 % of real time and a game presenting at 27.6 fps produce identical measurements, and the three trials share the container, so they are three samples of one confound rather than three confirmations. Same shape as the plate-pulse phase lock. The 8.5 % splash-dwell excess is the same number from the other side. The port is not exposed -- it authors declared units and reads seconds from nothing here. And the BGM_103 loop figures cannot audit it: that page states both derivations are wall-clock, converting no bits to seconds. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/ui-keyframe-time-unit.md | 39 ++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/re/ui-keyframe-time-unit.md b/docs/re/ui-keyframe-time-unit.md index 1cf83a92..0c8237df 100644 --- a/docs/re/ui-keyframe-time-unit.md +++ b/docs/re/ui-keyframe-time-unit.md @@ -427,3 +427,42 @@ the five screens' correlations stand ([acceptance](five-screens-acceptance.md)). screen family, not a disc-wide field check, and our own decoder still defaults to the other reading behind `SYLPHEED_KF_TIME_SHIFT=1` — ⚠️ **a gate since removed; there is no way to select the old reading today, and nothing to set.** + +## ⚠️ 2026-08-30 — "the game presents at 27.6 fps" is not separated from "my container runs the guest slow" + +`sylpheed-port` warned that their boot timings carry a host deficit — 146.6 s of +wall clock for 137.44 s of media, **+6.7 %**, because 720p Theora decodes below +real time on a box with no GPU — and that any comparison between their seconds and +mine must go through **media length, not wall clock**. Checking whether that +reaches this page: **it does, and to the page's own headline.** + +Every rate here is a frame count over a wall-clock window on one container: + +| | window | rate | +|---|---|---| +| idle title, trials 1–3 | 10.40 / — / 10.60 s | 28.8 / 28.3 fps | +| boot splash | 10.87 s | 27.6 fps | + +🔴 **A guest running at ~92 % of real time produces exactly these numbers**, and so +does a game genuinely presenting at 27.6 fps. The two hypotheses are +**indistinguishable by any measurement on this page**, and the three trials do not +separate them — they share the container, so they are three samples of one +confound, not three independent confirmations. This is the same shape as the +plate-pulse phase lock: agreement across runs that measures the instrument. + +The same applies to the **8.5 %** splash-dwell excess in +[`boot-order-and-splash-dwell.md`](boot-order-and-splash-dwell.md) — `1.085` and +`1/0.92` are the same number arriving from the two readings. + +✅ **The port is not exposed.** It authors **declared units** — 240 and 195 — and +reads seconds from nothing here. That row is still `decoded`, and its evidence is +the disc, not the clock. + +❌ **What will not settle it, and I checked:** the `BGM_103` loop figures. Both the +`9.44 s` start and the `61.87 s` cycle are wall-clock derived — that page states it +outright, *"two derivations, neither converting bits to seconds"* — so they carry +the same container pacing and cannot audit it. + +**What would settle it** is a media-length reference: play an asset whose duration +is fixed by its own data — a movie, or a wave with a declared byte rate — and +compare its wall clock against its media length in *this* container. Not run.