# The XMA context's loop fields for the menu bed, read from the running game.
#
# 2026-08-30. run-canary --gpu=null --xma_param_probe=true --log_mask=13
# --log_level=3 (log_mask DISABLES categories: 13 = Kernel+Cpu+Gpu off, APU ON,
# and XELOGAPU is debug level, hence level 3). No Canary patch was needed --
# UpdateLoopStatus already logs these.
#
# Menu reached by the log oracle in 26.8 s; 45 s hold; 8 734 'Looped Data'
# lines, ALL of them after BGM_103's contexts appear. The movie's three ADV
# streams produce NONE, i.e. loop_count = 0 on them.
#
# ctx -> wave, from the probe's own byte_size:
#   ctx0  packets=1893  byte_size=3876864   (wave 0)
#   ctx1  packets=1919  byte_size=3930112   (wave 1)
#
# LOOP FIELDS (bit offsets; loop_count 255 = infinite):
#   ctx0  loop_start =  3 605 682   loop_end = 25 640 423   len = 22 034 741
#   ctx1  loop_start =  3 539 158   loop_end = 26 216 351   len = 22 677 193
#
# READ-OFFSET TRAJECTORY over the 45 s hold:
#   ctx0  min 32  max 16 944 845     ctx1  min 32  max 17 165 054
#   20.0 % of samples are BELOW loop_start in both.
#   Neither reaches loop_end, so NO WRAP was observed in this run.
#
# => playback starts at offset 32 (the first packet header) and runs forward;
#    loop_start is where it returns AFTER loop_end. The first pass is longer
#    than the cycles that follow.
#
# 🔴 A LINEAR bits->seconds conversion is INVALID. Applied to each stem with
# its own byte_size it gives:
#   ctx0  62.34 s     ctx1  63.29 s
# Two stems that play sample-synchronously cannot have loop durations 0.95 s
# apart, so the linearity assumption is refuted by the data itself. XMA frames
# are variable-length in bits.
#
# 🔴 AND IT CONFLICTS with the audio measurement. loop_start at 3.6 M of
# 31.0 M bits is 11.6 % in; linearly that is ~10 s, so the cycle would be
# roughly [10 s, 72 s] of the wave. The audio wave-offset tracking
# (menu-bgm-loop-measured.txt) put the observed offsets at 0.25 .. 57.18 s.
# Both cannot be right. Unresolved.