Sylpheed/docs/re/menu-audio-cues.md

Menu audio — the event vocabulary is on the disc; the binding is not

Status: ✅ CONFIRMED and decoded for the cue vocabulary and the bank that holds it. 🟡 the cue↔event binding is a name match, not a measurement. ❔ two negatives with their reach: no cue names a screen's music, and the audio for an individual SE cue cannot yet be extracted.

Answers most of MISSION Q8.

✅ The UI cue vocabulary — decoded

dat/tables.pak's sound table has a SOUNDS record of 5 798 cues. 322 are SE_* and the low block is the user-interface vocabulary, named by the game's authors after the events, not after the sounds:

id	cue	id	cue
1	SE_UI_START	9	SE_UI_SUB_WIN_CLS
2	SE_UI_CURSOR	10	SE_UI_ALART_WIN
3	SE_UI_DECIDE	11	SE_UI_PAUSE
4	SE_UI_CANSEL (sic)	12	SE_UI_SPLASH_IN
5	SE_UI_IMPOSI	13	SE_UI_SPLASH_OUT
6	SE_UI_WAIT	14	SE_UI_LOAD_CMP
7	SE_UI_NEXT	17/18	SE_UI_WEAPON_PLAN / _CREATE
8	SE_UI_SUB_WIN_OPN	81–83	SE_UI_MISSION_START / _UPDATE / _END

Full 322-cue list in data/se-ui-cues.txt. The remaining blocks are gameplay: SE_HUD_* (21–83), SE_BR_* briefing (50–72), SE_SW_* / SE_MW_* weapons, SE_DS_* engine, SE_EXP_* explosions, SE_SHIELD_*.

✅ They all live in one bank — decoded

The sound table's BANK_SE record is a single field: Static.slb. And the disc-wide check agrees — 0 of the 322 SE_* cues has an entry in FILES, the 5 135-path list where every voice, briefing and BGM bank is named. SE is the one family that is not one-cue-one-file.

SETTINGS names the XACT project too: PATH = game:\dat\sound.pak+, PARAM = Pj_Silph.xgs.

🟡 The binding: a name match, and I am calling it that

MISSION asks which cue fires on move / confirm / back / error. Read off the names:

event	cue
cursor moves	SE_UI_CURSOR (2)
Ⓐ confirm	SE_UI_DECIDE (3)
Ⓑ back	SE_UI_CANSEL (4)
invalid / error	SE_UI_IMPOSI (5)
submenu opens / closes	SE_UI_SUB_WIN_OPN / _CLS (8/9)
the splash	SE_UI_SPLASH_IN / _OUT (12/13)

Nobody has watched the game emit cue 2 on a d-pad press. This is inference from identifiers, and it belongs in the same box as Q4's GamePart ids — with one honest difference worth stating: these are the authors' own event names, chosen to describe when the sound plays, not asset labels I am interpreting. It is a strong name match. It is still a name match, and the port is authoring it.

Measuring it needs the guest's cue-play call observed with its argument — the same instrumentation Q4's residual wants, and not something this container can do today (it runs --mute=true against an SDL dummy device, so there is no audio path to watch either).

✅ Which BGM per screen — the TABLE cannot say, but the CODE can

All 32 BGM cues are named BGM_001…BGM_109, and nothing in SOUNDS, FILES or the bank headers names a screen. That negative stands for the tables.

It does not stand for the executable. GamePart_Title's phase handler sub_821C5580 contains li r5, 1103 feeding a sound call — cue 1103 = BGM_103 — and BGM_103.slb's two declared waves (3 876 864 / 3 930 112 bytes) are byte-for-byte the two streams the XMA probe saw decoding at the main menu. Three routes, one answer; see structures/bgm-two-stems.md.

So the per-screen BGM binding is recoverable per screen, from the code that plays it — not from any table.

❔ And a new negative: an individual SE's audio is not extractable yet

🔴 SUPERSEDED by this page's own later section — read that instead. The heading's claim is false: the waves were located in Static.slb by playing them and reading the offsets out of the running game — move 0x1ec0, confirm 0x5d6c0, back 0x0ec0 — and this page states it further down: "both waves are located in Static.slb. The port can have the audio."

What survives below is the reason the file resists static scanning, which is still correct and still worth reading: Static.slb carries no RIFF/seek/ WAVE delimiters at all, so a wave in it is defined only by (offset, packet count) and those come from the oracle, not from the bytes. The negative was about the method, and it was written as though it were about the audio.

Kept rather than deleted: it is the evidence for why the extraction route had to be dynamic. ⚠️ It was also still being quoted by INDEX.md days later (audit).

Static.slb is 8 353 472 readable bytes (declared 8 970 240 — exactly the 616 768 over-declaration the corpus already records), and it contains 0 RIFF, 0 seek, 0 WAVE — scanned over the whole buffer, so this is not an offset problem. Every other bank on the disc is delimited by seek magic at data_at + declared_size (7 620/7 620 in slb-data-offset.md); Static.slb is outside that population. So the route that extracts every voice line and every BGM does not give you SE_UI_CURSOR's audio: the cue is named, the bank is named, and the wave inside the bank is not locatable by any boundary marker.

The named next step is Pj_Silph.xgs — the XACT project file SETTINGS points at, which in XACT is exactly where cue→wave-index lives. It is in sound.pak: name_hash("Pj_Silph.xgs") resolves to TOC index 9454. ⚠️ Its entry is 533 bytes at a 2048-aligned offset and carries no XGSF magic — and its region has phase 1728, so those 533 bytes are very likely the previous bank's tail rather than its own (the leading-region effect, [slb-data-offset.md] (structures/slb-data-offset.md)). Locating its real bytes is the first job, not parsing XACT.

For the port

• the cue names and ids are disc facts — use them as the event vocabulary;
• which event fires which cue is authored from the table above;
• which BGM plays on which screen is authored — nothing on the disc says;
• and the UI sound effects cannot be exported yet. That is a gap in the assets, not in the naming.

❔ Pj_Silph.xgs is a dead end — retracting the lead, with the reach

The section above named Pj_Silph.xgs as "the named next step", on the reasoning that in XACT the cue→wave index lives in the project file. That route is dead.

check	result
the entry's own bytes	533 bytes, high entropy, no XGSF magic
±8 KB around the entry in the flat concatenation	no XGSF, SDBK, WBND, RIFF or seek
all of sound.pak — 1.08 GB across .p00–.p04	0 × XGSF, 0 × SDBK, 0 × WBND
the executable	0 occurrences of XGSF/XACT; no string matching xact, .xgs, wavebank or soundbank

Control, run first: the same magic scan over BGM_001.slb's neighbourhood finds RIFF exactly where the bank structure says it should be. The scan works; the magic genuinely is not there.

So the .xgs / .slb names are inherited from the authoring tool, not from the shipped format — nothing on this disc is a parseable XACT container. There is no XACT project file to read, and writing an XACT parser would have been wasted work.

Where that leaves the SE audio: undecodable, with reach

Locating an individual SE cue's wave inside Static.slb is not possible from anything found on the disc. Looked in:

• Static.slb itself — 8 353 472 readable bytes, 0 RIFF / 0 seek / 0 WAVE, where every one of the other 7 620 banks is delimited by seek magic at data_at + declared_size (structures/slb-data-offset.md);
• the XACT project file — absent, as above;
• the sound table's five records — SOUNDS gives cue→id, FILES gives bank paths, BANK_SE gives the one bank name, SETTINGS gives a path and the (absent) project file, STAGES is empty. No record carries an offset.

What does corroborate the binding: Static.slb is 8 353 472 bytes, and at the bitrates the disc uses elsewhere (25 697–31 000 B/s) that is 269–325 seconds of audio — 0.84 to 1.01 s per cue over 322 cues. Exactly the shape of a bank of short UI/HUD/weapon effects, which is what BANK_SE says it is. The bank is the right bank; only the index into it is missing.

If it is ever picked up, the route is the running game, not the disc: watch the guest hand a wave offset/length to the decoder when a cue fires. That is the same instrumentation the cue↔event binding needs, and the same one this container cannot run.

✅ Retracting "cannot be extracted" — the waves are locatable, by playing them

The section above concluded that an individual SE cue's audio "cannot be extracted". That was too strong, and the tool to do it was already in this build. Canary here carries a cvar xma_param_probe, added for exactly this purpose — its 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".

Run with --xma_param_probe=true, drive the menu, and each newly-decoded stream prints one line with its packet count, channel count, sample rate and first 32 bytes. Searching those bytes in Static.slb finds the wave.

event	packets	bytes	format	offset in Static.slb
d-pad move (cursor)	4	8 192	mono 48 kHz	0x1ec0
Ⓑ back (cancel)	2	4 096	mono 48 kHz	0x0ec0
Ⓐ confirm (title → main menu)	6	12 288	mono 48 kHz	0x5d6c0

Each head matched at exactly one offset. Reference data in data/se-cue-runtime-offsets.txt.

Structurally this also cracks the bank's layout. The first two are contiguous — 0x0ec0 + 4096 = 0x1ec0 — so Static.slb is a packed run of XMA waves, each a whole number of 2 048-byte packets, with no delimiter between them. That is why the seek-magic scan found nothing: there is nothing to find. A wave is defined only by (offset, packet count), and those live in the game's own tables, not in the bank.

⚠️ The order is not cue-id order. Ⓑ's wave precedes the cursor's in the file, while the name match puts SE_UI_CURSOR at id 2 and SE_UI_CANSEL at 4. So the index cannot be derived by counting; it has to be observed per cue.

What is now measured, and what is still a name match

• ✅ measured — a d-pad move and a Ⓑ press each play a specific, different wave, and both waves are located in Static.slb. The port can have the audio.
• 🟡 still a name match — that the cursor's wave is the cue called SE_UI_CURSOR. The event→wave binding is measured; the event→name binding is still read off the authors' identifiers.
• ✅ decoded to PCM — see below. The cues play.

✅ The waves decode — artifact, not assertion

tools/re-capture/slb_extract_wave.py wraps a (bank, offset, packet count, channels, rate) slice in a synthesized XMA1 RIFF for ffmpeg's xma1 decoder:

slb_extract_wave.py Static.slb 0x1ec0 4      # -> Static_0x1ec0.riff -> 0.533 s

event	offset	packets	decodes to	RMS	peak	envelope
d-pad move	0x1ec0	4	0.533 s	2 085	29 813	sharp attack, monotonic decay
Ⓑ back	0x0ec0	2	0.344 s	2 985	16 973	attack, peak in frame 2
Ⓐ confirm	0x5d6c0	6	1.016 s	4 327	32 767	peaks in frame 3, long decay

All three are mono 48 kHz, audible from sample 0, and have the percussive attack-and-decay shape of UI blips — not silence, not noise.

Control, run first: the same synthesized wrapper applied to BGM_001.slb's first wave decodes to 173.808875 s — identical to the duration obtained from that bank's own on-disc RIFF header in structures/bgm-two-stems.md. The wrapper is not approximately right; it reproduces a known-good decode exactly.

The bitrates are consistent too: 8 192 B / 0.533 s ≈ 15.4 kB/s, 4 096 / 0.344 ≈ 11.9 kB/s, 12 288 / 1.016 ≈ 12.1 kB/s — mono at roughly half the stereo BGM rate.

🟡 The decoded audio is deliberately not committed. Three commands regenerate it from the disc, and the corpus keeps measurements and tooling rather than extracted game audio. The offsets, packet counts and this tool are the deliverable.

The three cues the milestone needs are bound — 2026-08-28, second run

A second, independent boot repeated the probe and pinned the one that was still unattributed.

event	wave	packets / bytes	runs agreeing
d-pad move	Static.slb+0x1ec0	4 / 8 192	2 of 2 — identical head bytes
Ⓑ back	Static.slb+0x0ec0	2 / 4 096	2 of 2 — identical head bytes
Ⓐ confirm	Static.slb+0x5d6c0	6 / 12 288	newly bound this run

The 0x5d6c0 wave was previously logged as "played before any input", because the first run only started counting at the main menu. Counting from the title instead shows it appears exactly on the Ⓐ that advances title → main menu, along with the two stereo BGM stems (the menu's music starting).

So move / confirm / back — everything the five-screen milestone needs — are located and decodable.

🟡 What that Ⓐ measurement does not separate. The same press both confirms and opens a screen, so this wave could be the cue the vocabulary calls SE_UI_DECIDE or the one it calls SE_UI_SUB_WIN_OPN. The port needs a sound on confirm and this is the one the game plays there; which name it carries is not established.

❔ ⬅ and ➡ play nothing distinct

menu-navigation-semantics.md measured that left/right do not move the cursor. They also fire no new XMA stream — so there is no distinct "invalid" cue on the main menu, and SE_UI_IMPOSI was not observed. The port should leave left/right silent.

⚠️ Reach of that negative: the probe dedups on head bytes, so a press that replayed an already-heard wave would log nothing. At that point in the run the cursor, confirm and BGM waves had all been heard. So this excludes a distinct invalid cue; it cannot exclude left/right quietly replaying one of those three.