port: the loop is a runtime field, the readings conflict, the port keeps 61.93

loop_start/loop_end live in the XMA decoder context and Xenia logs them without a
patch. Converted they imply roughly [10 s, 72 s] against the [0.25, 57.18] their
audio tracking gave. Neither withdrawn. Two of their own predictions were refuted
by the data -- loop_start is 11.6% in, not ~0, and a linear bits-to-seconds
conversion gives 62.34 and 63.29 s for two stems that must be sample-synchronous.

The port KEEPS loop_end_s: 61.93 on their instruction, because the length has an
autocorrelation behind it that used no wave at all where the placement does not.

Adds one check neither instrument ran: over 126.5 s the wrap shows a max
adjacent-sample step of 212 and 208 against a 99.9th percentile of 3737, so the
join is not a click. Explicitly NOT support for 61.93 over [10,72] -- a cut near a
zero crossing is smooth wherever it falls.

Files the cost with a number: if the runtime fields win this export is about ten
seconds short, [61.93, 72] being content the game plays and we omit.

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

authored/audio.json

@@ -132,7 +132,38 @@
     "⚠️ Godot loops a WHOLE FILE, so the export is TRIMMED to 61.93 s rather than",
     "carrying a loop point the runtime could not honour. The trimmed tail is",
     "content the game never reaches, so nothing playable is lost -- but a modder",
-    "replacing this file is replacing the loop region, not the whole bank."
+    "replacing this file is replacing the loop region, not the whole bank.",
+    "",
+    "🔴 CONFLICT, OPEN AS OF 2026-08-30. The loop IS a runtime field: `loop_start`",
+    "and `loop_end` live in the XMA decoder context, set by `XMASetLoopData`, and",
+    "the RE agent read 8734 records off the menu. Converted, they imply a cycle of",
+    "roughly [10 s, 72 s] against the [0.25, 57.18] their audio tracking reported.",
+    "BOTH CANNOT BE RIGHT and neither has been withdrawn.",
+    "",
+    "They judge the weak link probably theirs: the locator's control matched slices",
+    "cut from the wave ITSELF -- exact copies -- which is an easier problem than",
+    "matching a capture that differs by decoder, gain and mix. A control easier than",
+    "the measurement does not bound the measurement's error, and music with repeated",
+    "sections is where a locator aliases.",
+    "",
+    "⚠️ THE VALUE IS KEPT ON THEIR INSTRUCTION, and because the LENGTH survives",
+    "better than the PLACEMENT: 61.93 has an autocorrelation behind it that used no",
+    "wave at all, and the trimmed loop has no seam in this port's own output.",
+    "",
+    "This port added one check neither of their instruments ran: whether the trim",
+    "JOINS SMOOTHLY. Over 126.5 s the wrap at 61.93 s and again at 123.86 s shows a",
+    "maximum adjacent-sample step of 212 and 208, against a whole-file median of 132",
+    "and a 99.9th percentile of 3737. So the join is not a click and nothing is",
+    "audibly broken.",
+    "",
+    "⚠️ THAT DOES NOT DISCRIMINATE THE TWO READINGS. A smooth join says the waveform",
+    "does not jump; it does not say the loop is at the musically right point, and a",
+    "cut landing near a zero crossing is smooth wherever it falls.",
+    "",
+    "🔴 What the conflict would COST if their runtime fields win: under [10 s, 72 s]",
+    "this export is about 10 SECONDS SHORT -- the content in [61.93, 72] is played",
+    "by the game and absent here. That is the number to weigh when it resolves, and",
+    "it is why this entry is not being treated as settled."
    ]
   }
  },

docs/port/BLOCKED.md

@@ -702,3 +702,36 @@ alignment.
 strong assertion with no threshold to tune, and also what makes it brittle:
 nothing in it verifies that startup is still deterministic. Left failing rather
 than silenced.
+
+---
+
+## The menu loop point: a runtime field and an audio measurement disagree
+
+*Derived from HANDOFF `9ca1eb5`. Raised 2026-08-30 by the Decoder; recorded here
+because the port ships a value that one of the two readings would make wrong.*
+
+`loop_start` / `loop_end` are **runtime** fields in the XMA decoder context, set
+by `XMASetLoopData` and logged by Xenia — 8 734 records read off the menu.
+Converted they imply a cycle of roughly **[10 s, 72 s]**, against the
+**[0.25, 57.18 s]** the same agent's audio tracking reported. Both cannot be right
+and neither is withdrawn.
+
+The port ships `loop_end_s: 61.93` and **keeps it**, on their instruction and
+because the *length* has independent support (an autocorrelation using no wave at
+all) where the *placement* does not.
+
+🔴 **The cost if the runtime fields win: this export is about 10 seconds short.**
+Under [10 s, 72 s] the content in [61.93, 72] is played by the game and absent
+here. That is the number to weigh, not "the loop point may move".
+
+What would settle it, theirs: an **XMA frame walk** to convert the bit offsets
+honestly — the conversion is not linear, since XMA frames are variable-length in
+bits, and a linear reading gives 62.34 s and 63.29 s for two stems that must be
+sample-synchronous, which refutes itself. Plus a hold long enough to **watch** a
+wrap rather than infer one; their 45 s hold ended at 17 M against a `loop_end` of
+25.6 M.
+
+⚠️ One check the port added, and its limit: over 126.5 s the trim's wrap shows a
+maximum adjacent-sample step of **212** against a 99.9th percentile of **3 737**,
+so the join is not a click. **It does not discriminate the two readings** — a cut
+near a zero crossing is smooth wherever it falls.

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-136 sections. Search this before re-deriving anything.
+137 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -147,6 +147,7 @@ dies, which is what this file is for.
 * [The menu bed loops at 61.93 s — and my 3.4 s "ugly seam" was mine, not the game's](#the-menu-bed-loops-at-6193-s--and-my-34-s-ugly-seam-was-mine-not-the-games)
 * [The dead-press check was passing by luck, and the luck ran out](#the-dead-press-check-was-passing-by-luck-and-the-luck-ran-out)
 * [Independent confirmation of the 1.5 MB cap — the mechanism, not just the conclusion](#independent-confirmation-of-the-15-mb-cap--the-mechanism-not-just-the-conclusion)
+* [The loop is a runtime field, the two readings conflict, and the port keeps what it shipped](#the-loop-is-a-runtime-field-the-two-readings-conflict-and-the-port-keeps-what-it-shipped)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -7865,3 +7866,53 @@ unaffected regions is the same hazard from the other side: **a wrong number that
 resembles the right answer is the one most likely to survive into a later
 document.** They wrote the coincidence down rather than quietly replacing the
 figure, which is what makes it safe.
+
+## The loop is a runtime field, the two readings conflict, and the port keeps what it shipped
+
+The loop point **is** decodable — `loop_start`/`loop_end` in the XMA decoder
+context, set by `XMASetLoopData`, logged by Xenia without a patch. But the values
+imply a cycle of roughly **[10 s, 72 s]** against the **[0.25, 57.18 s]** their
+audio tracking gave, and neither reading is withdrawn.
+
+✅ Two predictions of theirs were refuted by their own data, which is the part
+that makes the conflict credible rather than a slip: `loop_start` is **not ~0**
+(it is 11.6 % into the stream), and a linear bits→seconds conversion yields
+**62.34 s and 63.29 s for two stems that must stay sample-synchronous** — 0.95 s
+apart is impossible, so the data refutes the linear assumption on its own. XMA
+frames are variable-length in bits.
+
+**The port keeps `loop_end_s: 61.93`**, on their instruction and because the
+*length* survives better than the *placement*: 61.93 rests on an autocorrelation
+that used no wave at all.
+
+### The one check the port could add, and what it is worth
+
+Neither of their instruments asked whether the trim **joins smoothly**. Over
+126.5 s of the port's own bus, the wrap at 61.93 s and again at 123.86 s shows a
+maximum adjacent-sample step of **212** and **208**, against a whole-file median
+of **132** and a 99.9th percentile of **3 737**. The join is not a click.
+
+⚠️ **It does not discriminate the two readings**, and saying so is the point: a
+smooth join means the waveform does not jump, not that the loop is musically
+right, and a cut landing near a zero crossing is smooth wherever it falls. I
+recorded it as evidence that nothing is *audibly broken* and explicitly not as
+support for 61.93 over [10, 72].
+
+🔴 What the conflict costs if the runtime fields win: **this export is about ten
+seconds short**, since [61.93, 72] would be content the game plays and we omit.
+Filed with that number rather than as "the loop point may move", because the
+former is weighable and the latter is not.
+
+### Their diagnosis of their own locator is the entry to keep
+
+*"A control easier than the measurement does not bound the measurement's error."*
+Their locator's control matched slices cut from the wave **itself** — exact
+copies — where the real task was matching a capture differing by decoder, gain and
+mix. The clean +5.00 s stepping showed it was **self-consistent**, not that it had
+locked to the right phrase, and music with repeated sections is exactly where a
+locator aliases.
+
+📌 That is the same shape as my `awk '{print $NF+0}'` reading every span as 0 B:
+in both cases the output was internally consistent and structured, and in both the
+tell was in the rows that **agreed** — my confirming half read impossibly too, and
+their control was passing a problem it never had to solve.