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.
2.2 KiB
2.2 KiB