Settles the conflict by timing the loop instead of converting it. A tailing probe
stamps read_offset with the wall clock as each log line arrives, so the period
needs no bits-to-time step -- the step already shown to be invalid.
Three wraps, each exactly loop_end -> loop_start, and BOTH CONTEXTS WRAP AT THE
SAME INSTANT all three times. That is the property two stems of one performance
must have and the one the linear conversion could not deliver (62.34 vs 63.29 s
would drift a second per cycle).
Cycle 61.56 and 62.06 s, mean 61.81, against the audio autocorrelation's 61.93 --
0.2 % apart from instruments sharing nothing.
Linearity refuted a second time and internally: the fitted rate over 10..60 s is
341 394 bits/s while the cycle covers 22 034 741 bits in 61.81 s = 356 491
bits/s, 4.4 % apart inside one stream.
My own audio locator's PLACEMENT is refuted. loop_start at 3.6 M bits is 11.6 %
of the stream by any reading, ~10.1 s at the cycle's own mean rate, against the
0.25 s that page reported -- for the reason already suspected, that its control
matched slices cut from the wave itself and never tested the aliasing the real
problem has. The length was right and the span was wrong.
Still not measured: loop_start in seconds. Offsets below it play exactly once and
this trace stamped that whole stretch at t=0.002, swallowing the log backlog in
one read, because it started after the music. The fix is to start the trace
before tapping into the menu -- one line, not done.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
