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.