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/port/HANDOFF.md

@@ -2529,6 +2529,39 @@ whatever it returns — the same reason a truncated log and a t=0 render both lo
 fine from inside. Template matching against the exported cue with a bed-only
 control has no such knob, which is the right fix rather than a better threshold.
 
+## 🟡 2026-08-30 (later) — the loop IS a runtime field. **Change nothing yet.**
+
+`loop_start` / `loop_end` live in the **XMA decoder context**, set by
+`XMASetLoopData`, and Xenia already logs them — no patch needed. Read from the menu:
+
+| ctx | wave | loop_start | loop_end | loop_count |
+|---|---|---|---|---|
+| 0 | 3 876 864 B | 3 605 682 | 25 640 423 | 255 |
+| 1 | 3 930 112 B | 3 539 158 | 26 216 351 | 255 |
+
+✅ Also decoded: the stream plays from offset **32**, and `loop_start` is where it
+returns *after* `loop_end` — so the first pass is longer than later cycles. And the
+movie's three `ADV` streams log **no** loop records at all: they do not loop.
+
+🔴 **But two of my predictions are refuted and there is a conflict I cannot
+resolve**, so **do not re-author `loop_end_s` from this**:
+
+* `loop_start` is **not ~0** — it is 11.6 % into the stream.
+* A linear bits→seconds conversion gives **62.34 s** and **63.29 s** for two stems
+  that must stay sample-synchronous. 0.95 s apart is impossible, so the conversion
+  is invalid — XMA frames are variable-length in bits.
+* That implies a cycle of roughly **[10 s, 72 s]**, against the **0.25 … 57.18 s**
+  my audio tracking reported. Both cannot be right.
+
+⚠️ **The weak link is probably my own earlier control**: it located slices *cut from
+the wave itself* — exact copies, an easier problem than matching your capture. A
+control easier than the measurement does not bound its error.
+
+**The 61.93 s length survives better than the placement** — it has an
+autocorrelation behind it that used no wave at all, and your trimmed loop has no
+seam in your own output. Keep what you shipped.
+[`menu-bgm-loop-fields-conflict.md`](../re/structures/menu-bgm-loop-fields-conflict.md)
+
 ## ✅ 2026-08-30 — the menu BGM loops at **61.93 s**, and there is **no seam**
 
 **Measured, 240 s parked on the menu.** Your authored loop is wrong in both