07f0231ff8
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
37 lines
2.1 KiB
Plaintext
37 lines
2.1 KiB
Plaintext
# The menu loop WATCHED, not converted: three wraps, timed by wall clock.
|
|
#
|
|
# 2026-08-30. tools/re-capture/xma_readoff_trace.py tails the Apu debug log
|
|
# and stamps each 'Looped Data' read_offset with the wall clock as it arrives.
|
|
# That gives the loop period in seconds with NO bits-to-time conversion --
|
|
# which is the step menu-bgm-loop-fields-conflict.md showed to be invalid.
|
|
#
|
|
# WRAPS (each ctx from its own loop_end to its own loop_start):
|
|
# t= 65.07 ctx1 26,216,351 -> 3,542,945 ctx0 25,640,423 -> 3,610,911
|
|
# t=126.63 ctx1 26,216,351 -> 3,542,945 ctx0 25,640,423 -> 3,610,911
|
|
# t=188.69 ctx1 26,216,351 -> 3,542,945 ctx0 25,640,423 -> 3,610,911
|
|
#
|
|
# BOTH CONTEXTS WRAP AT THE SAME INSTANT, three times. They stay
|
|
# sample-synchronous, which is what two stems of one performance must do and
|
|
# what the linear conversion's 62.34-vs-63.29 s could not deliver.
|
|
#
|
|
# CYCLE: 126.63-65.07 = 61.56 s ; 188.69-126.63 = 62.06 s ; mean 61.81 s.
|
|
# The audio measurement (menu-bgm-loop-measured.txt) gave 61.93 s from an
|
|
# autocorrelation that used no wave at all. 0.2 % apart, different instruments.
|
|
#
|
|
# 🔴 LINEARITY REFUTED AGAIN, internally: the fitted rate over the clean
|
|
# stretch 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 within one stream, so bit offsets
|
|
# cannot be converted to seconds by any single rate.
|
|
#
|
|
# 🟡 loop_start's POSITION IN THE WAVE IS NOT DETERMINED BY THIS RUN.
|
|
# Offsets below loop_start (32 .. 3,605,682) are played exactly ONCE, before
|
|
# the first wrap, and this trace stamped that whole stretch at t=0.002 --
|
|
# 616 samples spanning offsets 32..2,559,033 in one batch, because the trace
|
|
# started after the music did and read the log's backlog in one gulp.
|
|
# A linear back-extrapolation suggests ~9-13 s, but linearity is exactly what
|
|
# is refuted above, so that is an indication and not a measurement.
|
|
#
|
|
# WHAT IS SETTLED: the loop region begins WELL INTO the wave, not at ~0.25 s.
|
|
# 3.6 M bits is 11.6 % of the stream by any reading; at the cycle's own mean
|
|
# rate it is 10.1 s. The audio locator's placement is refuted.
|