re: the loop IS a runtime XMA field -- and reading it contradicts my audio measurement

No Canary patch was needed: UpdateLoopStatus already logs loop_start/loop_end,
they just need the Apu category (--log_mask=13 --log_level=3).

Decoded, from the menu, 8734 records all after BGM_103's contexts appear:
  ctx0 (wave 3876864)  loop_start 3605682  loop_end 25640423  loop_count 255
  ctx1 (wave 3930112)  loop_start 3539158  loop_end 26216351  loop_count 255
The movie's three ADV streams log NO loop records -- they do not loop.

Semantics visible in the trajectory: read_offset runs from 32 upward and 20 % of
samples sit below loop_start, so the stream plays from the beginning and
loop_start is where it returns AFTER loop_end. No wrap was observed -- the 45 s
hold ended with read_offset at 17 M against a loop_end of 25.6 M.

Two registered predictions REFUTED. loop_start is not ~0 but 11.6 % in. And a
linear bits-to-seconds conversion is invalid: it gives 62.34 s and 63.29 s for
two stems that must play sample-synchronously, which is impossible, so the data
refutes the assumption on its own.

That leaves a conflict I am not resolving: the field implies a cycle of roughly
[10 s, 72 s]; my audio tracking reported offsets 0.25..57.18 s. Recorded as
contested, with the likely weak link named as mine -- that locator's control used
slices cut from the wave itself, exact copies, which is an easier problem than
matching a real capture, and a control easier than the measurement does not bound
its error.

The port is told to change nothing: its trimmed 61.93 s loop is verified in its
own output, and the length survives better than the placement.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/data/menu-bgm-xma-loop-fields.txt

@@ -0,0 +1,40 @@
+# 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.