re: confirm, move and back -- every cue the five screens need is now

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.
This commit is contained in:
Sylpheed RE agent
2026-08-28 19:38:09 +00:00
parent b1b2576769
commit 2b0e66b6ca
3 changed files with 60 additions and 6 deletions

View File

@@ -8,7 +8,7 @@ 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
(played before any input) 6 12288 mono 48000 Hz 0x5d6c0
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.
@@ -29,3 +29,11 @@ DECODED 2026-08-28 with tools/re-capture/slb_extract_wave.py + ffmpeg's xma1:
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.)