From dd7edd5e38d9131a38f10e65d38e6bbfb380e829 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sun, 30 Aug 2026 16:35:09 +0000 Subject: [PATCH] re: withdraw "the sweep rate matches the disc" -- two errors that cancelled sylpheed-port corrected the disc figure I compared against: the leaf's final segment HOLDS, so a cycle length is not a motion duration. Verified from the disc rather than accepted -- pteff03 moves over t=0..540 of a 600-unit cycle (4.000 px/unit, not 3.600) and pteff03a over 0..630 of 720 (4.063, not 3.556). Checking that sent me back to my own measurement, which was worse. "6-7 px/frame" came from eyeballing deltas between consecutive APPEARANCES in a capture that skips frames, so a delta of 7 often spans two frames. A least-squares fit of x against frame over all 132/112 points gives +4.287 and -4.348 px/frame, with rms residuals of 3.6 and 3.3 px. So the confirmation I reported was a prediction 20 % too low meeting a measurement 50 % too high. Neither number was right and the agreement was an artefact of both being wrong -- which is the most dangerous form of agreement in this corpus, because nothing about it looked suspicious. The corrected numbers say something larger than the claim they replace. Measured against declared: 4.287/4.000 = 1.072 units per frame, and 4.348/4.063 = 1.070. Two independent strips with different cycle lengths and different declared rates agree to three significant figures. Q1 establishes 2 units per RENDERED frame for top-level elements. So either a nested leaf record advances at about half the top-level rate, or Q1's factor does not apply to nested records. Measured, not explained, and flagged as deserving its own iteration because Q1 is load-bearing. One untested candidate recorded: 1 unit per 1/30 s of game time against the ~28.5 fps this corpus measures for the idle title gives 1.053, close to 1.07. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- .../examples/ptloop_leaf_extent.rs | 14 +++++++ docs/re/data/title-sweep-drawn-at-rest.txt | 39 +++++++++++++++++++ 2 files changed, 53 insertions(+) diff --git a/crates/sylpheed-formats/examples/ptloop_leaf_extent.rs b/crates/sylpheed-formats/examples/ptloop_leaf_extent.rs index 3c6c0b5f..6ac4ca4b 100644 --- a/crates/sylpheed-formats/examples/ptloop_leaf_extent.rs +++ b/crates/sylpheed-formats/examples/ptloop_leaf_extent.rs @@ -39,11 +39,25 @@ fn main() { if !sys.contains(&k.scale_y) { sys.push(k.scale_y) } } } + // A CYCLE LENGTH IS NOT A MOTION DURATION. Find the last t at + // which x still changes: sylpheed-port reports the final segment + // HOLDS, which would make px/unit larger than cycle-based maths. + let mut last_move = 0u32; + let mut prev = None; + for t in 0..=span { + if let Some(k) = le.pose_at(t) { + if prev.map_or(false, |p| p != k.x) { last_move = t } + prev = Some(k.x); + } + } let w = (le.pivot_x * 2) as i64; println!(" leaf {:<12} pivot {}x{} quad w={w} x track {lo} .. {hi} \ (centre {} .. {}) scale_x {:?} scale_y {:?}", le.name, le.pivot_x, le.pivot_y, lo + le.pivot_x as i64, hi + le.pivot_x as i64, sxs, sys); + println!(" motion ends at t={last_move} of a {span}-unit cycle -> {:.3} px/unit over the MOVING span (vs {:.3} over the cycle)", + (hi - lo) as f64 / last_move.max(1) as f64, + (hi - lo) as f64 / span as f64); } } } diff --git a/docs/re/data/title-sweep-drawn-at-rest.txt b/docs/re/data/title-sweep-drawn-at-rest.txt index 8a510592..a27cee86 100644 --- a/docs/re/data/title-sweep-drawn-at-rest.txt +++ b/docs/re/data/title-sweep-drawn-at-rest.txt @@ -31,3 +31,42 @@ # 🔴 SO MY OWN HYPOTHESIS IS REFUTED by the oracle, and sylpheed-port's reading of # their `title` curve -- that the sweep is PRESENT in a title capture -- is # confirmed. + +################################################################################ +# 🔴 BOTH HALVES OF THE "RATE MATCHES THE DISC" LINE ABOVE ARE WITHDRAWN. +# +# The PREDICTION was wrong. sylpheed-port pointed out that the final segment +# HOLDS, so a cycle length is not a motion duration. Verified from the disc: +# pteff03 motion ends t=540 of a 600-unit cycle -> 4.000 px/unit (not 3.600) +# pteff03a motion ends t=630 of a 720-unit cycle -> 4.063 px/unit (not 3.556) +# +# The MEASUREMENT was also wrong, and that error is mine alone. "6-7 px/frame" +# came from eyeballing deltas between consecutive APPEARANCES, but the capture +# skips frames -- so a delta of 7 often spans two frames, not one. A least-squares +# fit of x against frame over the whole capture gives: +# strip A +4.287 px/frame (132 pts, frames 1..149, rms resid 3.59 px) +# strip B -4.348 px/frame (112 pts, frames 1..149, rms resid 3.33 px) +# +# ⚠️ So the confirmation was two errors that happened to overlap: a prediction +# 20 % too low meeting a measurement 50 % too high. Neither number was right and +# the agreement was an artefact of both being wrong. +# +# 📌 WHAT THE CORRECTED NUMBERS SAY -- and it is a bigger claim than the one +# withdrawn: +# +# strip A / pteff03 measured 4.287 px/frame / declared 4.000 px/unit +# strip B / pteff03a measured 4.348 px/frame / declared 4.063 px/unit +# -> 1.072 and 1.070 units/frame +# +# Two independent strips, different cycle lengths and different declared rates, +# agree on 1.07 units per submitted frame to three significant figures. Q1 +# establishes 2 units per rendered frame for TOP-LEVEL elements +# (ui-keyframe-time-unit.md). 🟡 So either a NESTED leaf record advances at about +# HALF the top-level rate, or Q1's factor does not apply to nested records. This +# is measured, not explained, and Q1 is load-bearing enough that it deserves its +# own iteration rather than a note here. +# +# 🟡 One candidate worth recording: if the leaf advances 1 unit per 1/30 s of game +# time while VdSwap frames arrive at the ~28.1-28.5 fps this corpus measures for +# the idle title, the ratio is 30/28.5 = 1.053 -- close to the observed 1.07. +# Untested.