# WHERE the menu loop starts -- measured, no bits-to-seconds conversion.
#
# 2026-08-30. tools/re-capture/menu_loop_firstpass.py. The fix over the
# previous run was scheduling, not analysis: tail the log from BEFORE the
# music starts, so the first pass is sampled at the same cadence as every
# later cycle. Offsets below loop_start are played exactly ONCE.
#
# Backlog compression, previous run vs this one:
#   before: 616 samples at t=0.002 spanning offsets 32..2,559,033
#   now:    125 samples at t=26.479 spanning offsets 32..515,239
#
# WRAPS: t = 96.46, 158.33, 220.21   gaps 61.87, 61.87   (both contexts, same
# instant, as they must be to stay sample-synchronous)
#
# TWO DERIVATIONS, both contexts:
#   (a) time from offset 32 to read_offset crossing loop_start,
#       with the unsampled head corrected at the LOCAL measured rate
#       (387,823 / 377,440 bits/s over 748 timestamped samples):
#         8.11 s sampled + 1.33 s head  =  9.44 s
#   (b) first pass (offset 32 -> loop_end) minus the cycle:
#         70.0 + 1.33 - 61.87            =  9.44 s
#
#   ctx0 -> 9.44 s     ctx1 -> 9.44 s     agreeing to the digit
#
# => LOOP REGION [9.44 s, 71.31 s] of an 87.744 s wave; cycle 61.87 s.
#    The first 9.44 s is an intro played ONCE; the last 16.4 s -- the
#    fade-out bgm-two-stems.md documents -- is NEVER played.
#
# The decoder reads ahead of playback, but both endpoints are read_offset
# events, so the lead cancels in the difference.