e7bea389c7
located, and two of them reproduce Continuing Q8 rather than opening anything new. The gap that mattered was the confirm cue: a menu needs a sound on A, and I had only cursor and cancel. The fix was where I was counting from. The first run started counting streams at the main menu, so the confirm cue had already fired during boot and showed up as "played before any input". Counting from the TITLE instead attributes it cleanly: the A that advances title -> main menu fires the 12288-byte wave at 0x5d6c0, together with the two stereo BGM stems, which is the menu's music starting. So move (0x1ec0, 0.533 s), confirm (0x5d6c0, 1.016 s) and back (0x0ec0, 0.344 s) are all located and decodable. Move and back came back with IDENTICAL head bytes and sizes on a second independent boot, so the dedup-keyed method is stable and those two are now n=2 rather than n=1. Two honest limits recorded rather than smoothed over. The A press both confirms and opens a screen, so its wave could be the cue the vocabulary calls DECIDE or the one it calls SUB_WIN_OPN -- the port gets the sound the game plays, not a name. And left/right fired no new stream, which excludes a DISTINCT invalid cue but cannot exclude them quietly replaying one of the three already heard, because the probe dedups on head bytes.
40 lines
2.2 KiB
Plaintext
40 lines
2.2 KiB
Plaintext
SE cue waves located inside Static.slb by playing them.
|
|
|
|
Method: run Canary with --xma_param_probe=true, drive the main menu, and read the
|
|
per-stream XMA-PARAM lines. Each line carries the stream's first 32 bytes; those
|
|
bytes are then searched for in Static.slb's 8 353 472 readable bytes.
|
|
|
|
event packets bytes channels/rate offset in Static.slb
|
|
------------------------- ------- ------ -------------- --------------------
|
|
d-pad move (cursor) 4 8192 mono 48000 Hz 0x1ec0
|
|
B / back (cancel) 2 4096 mono 48000 Hz 0x0ec0
|
|
A / confirm (title->menu) 6 12288 mono 48000 Hz 0x5d6c0
|
|
|
|
Each head matched at exactly ONE offset. The first two are contiguous:
|
|
0x0ec0 + 4096 = 0x1ec0.
|
|
|
|
Simultaneously at the main menu, two STEREO 48 kHz streams were decoding:
|
|
1893 packets / 3 876 864 B and 1919 packets / 3 930 112 B. See
|
|
structures/bgm-two-stems.md -- this is the runtime observation that the two
|
|
stems of a music bank play at the same time.
|
|
|
|
DECODED 2026-08-28 with tools/re-capture/slb_extract_wave.py + ffmpeg's xma1:
|
|
|
|
event offset packets decoded rms peak envelope shape
|
|
---------------- -------- ------- --------- ----- ----- ------------------------
|
|
d-pad move 0x1ec0 4 0.533 s 2085 29813 sharp attack, monotonic decay
|
|
B / back 0x0ec0 2 0.344 s 2985 16973 attack, peak in frame 2
|
|
(pre-input cue) 0x5d6c0 6 1.016 s 4327 32767 peaks in frame 3, long decay
|
|
|
|
CONTROL: the same synthesized RIFF wrapper applied to BGM_001.slb's first wave
|
|
(offset 14336, stereo) decodes to 173.808875 s -- identical to the duration
|
|
obtained from that bank's own on-disc RIFF header. The wrapper is correct.
|
|
|
|
SECOND RUN 2026-08-28 -- independent boot, same probe:
|
|
* d-pad move and B reproduced with IDENTICAL head bytes and sizes (2 of 2 runs).
|
|
* The 12288-byte wave fires on the A that advances title -> main menu, together
|
|
with the two stereo BGM stems (the menu's music starting). Counting from the
|
|
title rather than the menu is what attributed it.
|
|
* Left and Right fired NO new stream -- no distinct invalid cue. (Dedup caveat:
|
|
a press replaying an already-heard wave would also log nothing.)
|