They challenged the dwell agreement: declared spans 240 u and 195 u at 60 u/s give
4.000 and 3.250 s against six cold boots whose ratios all exceed 1, mean 1.085,
implying 54-56 units/s. And that 240 units at 60 should give 4.000 where I report
4.28.
The port does not play 240 units. Their 240 is the visible span, the logo
element's 15->255. The port plays the whole group from t=0, and my export gives
the full spans as 255 and 210 units -- 4.250 and 3.500 s. My 4.28 and 3.58 are
those plus transition overhead.
Recomputed against what the port plays, the ratios become 1.011, 1.083, 1.028,
1.002, 1.001, 0.962 -- mean 1.0145 with one of six below unity, against their mean
1.085 with none below. The systematic largely dissolves.
Their practical consequence does not follow either: the gap is 0.174 s, not 0.42,
and on developer_logos the port runs 0.041 s LONGER than the oracle mean, the
opposite sign.
Fourth instance of the same family after pivot-as-extent, centre-track-as-bbox and
cycle-length-as-motion-duration: a visible span read as a played span -- and the
first where the misread number was mine to supply and I had never stated which
span the port plays.
What survives: publisher still runs long in two of three boots against the full
group. Much weaker than 8.5%, thin at three boots, and no support for changing
keyframe_units_per_second.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
ad72a2e2bb