fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the menu's music is BGM_103 -- found by accident while chasing Q6,

Browse Source 
confirmed three ways

Chasing where the event code comes from, sub_821C5580 turned out to do
two things worth having.

For Q6 it arms the outer gate: li r11,3 ; stw r11,16(r28) is exactly the
value sub_821C7850 tests before dispatching, which answers the "what does
this+16 == 3 gate on" question I left open last iteration. It then passes
r5 = [r27+4], an event read out of a structure, so the vocabulary is
still not enumerable. Of the four callers of sub_821C7850, three pass
constants -- 0, 0 and 5 -- and this one does not.

The accident is a few instructions earlier: li r5, 1103 into a sound-play
call. 1103 is a BGM cue id, BGM_103. That closes a residual I had written
off as undecodable: which bank the menu plays. The cue table genuinely
cannot say, since its BGM entries are numeric -- but the code can, and it
checks out three independent ways. The census says BGM_103.slb is two
waves of 3876864 and 3930112 bytes; the XMA probe at the main menu saw
two stereo streams of 3876864 and 3930112 bytes. Byte for byte on both.

That also corrects me. bgm-two-stems.md said those observed sizes matched
no bank's declared waves and inferred the decoder gets a window rather
than a whole wave. Wrong on both counts -- I had checked only the BGM_0xx
rows of the census because that was the block on screen. METHOD gets it:
check a measurement against the whole reference set, not the part you
happened to be reading.
This commit is contained in:
Sylpheed RE agent
2026-08-28 20:10:41 +00:00
parent a98e96b0f0
commit 86e52b01d0
6 changed files with 97 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -129,8 +129,25 @@ bank's two waves are simultaneous, not sequential.** Concatenating them is wrong
now measured as well as inferred.
🟡 It still does **not** separate the two readings — surround-rear pair versus a
second intensity layer — because both predict simultaneity. And the two byte
sizes do not match any bank's declared wave sizes in
[`../data/bgm-wave-census.txt`](../data/bgm-wave-census.txt), so *which* bank the
menu plays is still not established; the game hands the decoder a window, not the
whole declared wave.
second intensity layer — because both predict simultaneity.
## ✅ The menu's music is `BGM_103` — three independent routes agree
An earlier version of this section said the two observed byte sizes "do not match
any bank's declared wave sizes". **That was wrong** — I had checked only the
`BGM_0xx` rows. They match `BGM_103` exactly, and the code names it:
| route | evidence |
|---|---|
| **static, code** | `GamePart_Title`'s phase handler `sub_821C5580` does `li r5, 1103` into a sound call (`sub_8217ACF8`, with `r4 = 4`) — **cue 1103 = `BGM_103`** |
| **static, disc** | [`../data/bgm-wave-census.txt`](../data/bgm-wave-census.txt): `BGM_103.slb` = two waves of **3 876 864** and **3 930 112** bytes, 87.75 s each |
| **runtime** | the XMA probe at the **main menu** saw two stereo 48 kHz streams decoding simultaneously, of **3 876 864** and **3 930 112** bytes |
Byte-for-byte on both waves. So:
* **which bank the menu plays is decoded** — `BGM_103`, from the executable, since
the cue *table*'s BGM entries are numeric and name no screen;
* and the two-stems-play-together finding is now confirmed **on a named bank**,
with the runtime stream sizes equal to the bank's declared wave sizes — so the
game hands the decoder the whole wave, not a window, which is the opposite of
what the earlier note guessed.