fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: land the loop-point correction where the claim actually lives

Browse Source 
The port found its exporter still shipping 'no loop-point field has been
identified anywhere' in the field manifest.json concatenates, days after the
correction existed in other fields. Auditing this corpus the same way found the
same failure here: the refuted sentence was still standing untouched in
bgm-two-stems.md -- where anyone looking up BGM behaviour arrives -- and in
HANDOFF.md, the one page the port is told to read. My correction had gone into a
NEW page only.

Both fixed in place, each naming the refutation rather than quietly deleting the
old claim, and each carrying the measured window [9.44, 71.31] s at 61.87 s.

METHOD entry: writing a correction down is not landing it. Grep the corpus for
the CLAIM, not for the file you were working in. Plus the port's trap in doing
that audit -- a replacement that quotes the refuted sentence in order to name it
will match a substring search from inside the paragraph saying it is false.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 10:20:04 +00:00
parent 712cac8984
commit 1d770b65eb
4 changed files with 135 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs/re/structures/bgm-two-stems.md
View File

@@ -117,11 +117,22 @@ transcribing one.
* a music bank is **two waves that play together**, not one track and not a
sequence — do not concatenate;
* both are full length; align them at sample 0;
* **the track is not a seamless loop.** `BGM_001` fades out and is followed by
**6.15 s of silence** (last sound 167.663 s of 173.809 s; the final second
before silence is at RMS 168 against 4 788 at the head). Looping the wave as
stored gives a fade-out and six seconds of nothing every cycle. No loop-point
field has been identified in the XMA header, so a menu loop is **authored**.
* **the track is not a seamless loop *as stored*.** `BGM_001` fades out and is
followed by **6.15 s of silence** (last sound 167.663 s of 173.809 s; the final
second before silence is at RMS 168 against 4 788 at the head). Looping the wave
end-to-end gives a fade-out and six seconds of nothing every cycle.
🔴 **But "no loop-point field has been identified … so a menu loop is
authored" is REFUTED (2026-08-30), and this bullet said it for days after.**
There is no loop point in the **file header**; there is one in the **XMA decoder
context**, written at runtime via `XMASetLoopData`, and Xenia already logs it.
For `BGM_103` it is **`[9.44 s, 71.31 s]`, cycling every 61.87 s** — measured by
watching three wraps, so the game never reaches the fade at all. That is *why*
the stored tail looks unusable: it is never played.
[`menu-bgm-loop-fields-conflict.md`](menu-bgm-loop-fields-conflict.md)
⚠️ Reach: measured on `BGM_103` only. Whether every bank carries loop bounds is
untested — but "the format has nowhere to put one" is dead.
## ✅ Confirmed at runtime — two stereo streams decode at once