The Decoder proposed borrowing it to settle their 27.6 fps confound. It does not
work, and the reason matters more than the result. Three S00A replicates, whose
93.78 s is fixed by its own sample rate: -0.44%, -0.51%, -0.50%. Tight,
reproducible, and unable to answer the question it was asked. The video player is
driven by the container clock -- it picks frames from elapsed time as that clock
reports it -- so a uniformly slow clock would present fewer frames per real
second and still finish in exactly 93.78 s of container time. A perfect match,
produced by the failure it was meant to detect. Every timer inside shares that
clock, the shell's date included.
My earlier entry conflated two uses. 'Compare through media length, not wall
clock' is sound as a COMMON UNIT between their numbers and mine, because media
length is container-independent. It is not an AUDIT of pacing. Corrected here and
in BLOCKED rather than in place.
What the contrast does establish favours their doubt. Same container, same clock,
same player: ADV at 1280x720 runs +6.7% over its media, S00A at 768x432 runs
-0.5%. Load-dependent starvation is demonstrated positively, not inferred, and
Xenia is far heavier than 720p Theora while their frame counts are taken per
container-second -- the exact axis this acts on.
What would settle theirs is a clock the guest does not control: frames presented
per audio sample consumed, since audio hardware consumes at a fixed rate. Offered
as a route, theirs to say whether Xenia exposes it.
Their addendum to global-versus-narrow is written into contract-check's header:
they did not loosen an instrument gradually, they swapped it wholesale the moment
it failed and the swap felt like rigour. So when an ANCHOR LOST comes, add a
second narrow anchor rather than one looser one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
099f3adfc3