re: the UI sound effects ARE extractable -- retracting "cannot be

extracted", and the tool was in the build all along

Two iterations ago I closed Q8 by declaring the SE audio undecodable:
Static.slb has no wave boundaries, there is no XACT container anywhere,
and I said the index "exists only at runtime" as though that put it out
of reach. The disc half of that stands. The conclusion did not.

This build of Canary carries a cvar called xma_param_probe, added by this
project, whose own comment says it logs each XMA stream's parameters and
head bytes so raw sound.pak entries can be matched to real decode params.
It has been sitting in the startup CONFIG DUMP of every log I have read
this session.

Run with it, driving the main menu: a d-pad move spawns a new mono 48 kHz
stream of 4 packets / 8192 bytes, and B spawns a different one of 2
packets / 4096 bytes. Searching their logged head bytes in Static.slb
finds each at exactly one offset -- 0x1ec0 and 0x0ec0 -- and the two are
contiguous, 0x0ec0 + 4096 = 0x1ec0. So the bank is a packed run of whole
2048-byte packets with no delimiters, which is precisely why the seek
scan found nothing: there is nothing to find. A wave is (offset, packet
count) and nothing else.

That splits Q8's binding cleanly. Event -> WAVE is now measured: the port
can have the audio. Event -> cue NAME is still a name match on the
authors' identifiers, and the page says so.

The same run settled something for Q10 too. Sitting on the main menu, TWO
stereo 48 kHz streams were decoding simultaneously. bgm-two-stems.md said
that observation was what it needed and that this container could not
make it; it can, and a music bank's two waves are now measured as
simultaneous rather than only inferred.

METHOD gets the general lesson, because it cost two iterations: check
what instrumentation the local build already has before declaring a
question blocked on tooling.

docs/re/structures/bgm-two-stems.md

@@ -113,3 +113,24 @@ transcribing one.
   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**.
+
+## ✅ Confirmed at runtime — two stereo streams decode at once
+
+The page above said the "played together" reading needed "a runtime observation
+of whether the game submits both waves to the mixer at once", and that this
+container could not do it. It can: `--xma_param_probe=true` logs every XMA stream
+the decoder is handed.
+
+Sitting on the **main menu**, two stereo 48 kHz streams were decoding
+simultaneously — **1 893 packets / 3 876 864 B** and **1 919 packets /
+3 930 112 B**. Two stereo streams alive at the same moment on a screen with one
+piece of music playing is the direct observation this page was missing: **a music
+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.