Sylpheed/docs/re/bgm-102-decoded-during-boot.md

✅ The two unexplained XMA streams are BGM_102.slb — and the corpus's BGM_103 sizes survive a check

Classification: decoded for the identification (the bank, plus a disc-wide search); measured for the fact that it was decoded during a boot.

Closes the ❔ left by the take-2 audio capture, where audio-capture-channel-map-trap.md recorded that --xma_param_probe logged five distinct streams on one boot when only ADV's three were accounted for.

The identification

The probe gives a byte_size and nothing else, so the disc was asked which cue owns a stream that long. Both unexplained sizes are whole packet counts — 1 150 976 = 562 packets, 1 269 760 = 620 — and --example find_stream_by_size searched every inter-descriptor span of the continuous voice stream and every sound.pak entry large enough:

hits in the movie-voice stream	0
hits in sound.pak	one entry carrying both: hash 9799c546

One entry holding both sizes is the two-stem shape, not a coincidence of two separate matches. The hash recovers by candidate enumeration (--example name_from_hash) to BGM_102.slb.

BGM_102.slb  2 445 760 B on disc, header 10 240 -> 2 streams
   stream 0: 1 150 976 B (562 packets)  declared 30 703 B/s  => 37.487 s
   stream 1: 1 269 760 B (620 packets)  declared 33 872 B/s  => 37.487 s

✅ So the boot's five streams were ADV's three voice streams plus one music bank's two stems, and nothing is unaccounted for.

🟡 What it does NOT establish: which screen it belongs to

The capture window ran from process launch to t = 253 s, and its screen log reads movie/attract throughout, with the title arriving at t = 262 s — after the recording ended. So BGM_102 was decoded somewhere inside a launch-to-just-before-title window.

⚠️ That is not enough to call it the attract music. The probe fires on first decode and its log lines carry a thread id, not a timestamp, so nothing here says when in those 253 s it started — and a title BGM being decoded moments before the title appears is exactly as consistent. The numbering makes that a live hypothesis rather than a remote one: the corpus already has the main menu on cue 1103 → BGM_103, so 1102 sitting one below it is at least suggestive of the title.

The experiment that would settle it is cheap and is not done: put a wall-clock timestamp on the probe line (or bound the run so it stops before the title) and compare against the screen log the capture already produces.

🟢 Refutation attempt — HANDOFF's BGM_103 wave sizes. It SURVIVED.

HANDOFF asserts the menu's music is BGM_103 partly on "BGM_103.slb's two declared waves (3 876 864 / 3 930 112 B)". Read off the disc:

BGM_103.slb  7 841 292 B, header 10 240 -> 2 streams
   stream 0: 3 876 864 B  declared 44 181 B/s  => 87.750 s
   stream 1: 3 930 112 B  declared 44 788 B/s  => 87.749 s

Exact, both. The claim stands unchanged.

✅ And a third route to "two stems of identical duration"

bgm-two-stems established equal duration by decoding. The XMA1 PsuedoBytesPerSec fix (voice-region-leading-chunk.md) gives the same answer from the header alone, on three banks:

bank	stem 0	stem 1
BGM_102	37.487 s	37.487 s
BGM_103	87.750 s	87.749 s
BGM_001	173.821 s	173.821 s

⚠️ And the one apparent disagreement resolves in the corpus's favour. BGM_001 reads 173.821 s here, against the 167.663 s the port measured by decoding. The gap is 6.158 s — and HANDOFF already records that BGM_001 "fades out at 167.663 s and is followed by 6.15 s of silence". The declared duration covers the encoded stream including its trailing silence; the decoded figure is where the audio stops. The two are consistent, and neither is wrong.

That is a genuine cross-check of the declared-rate method against an independent decode, and it is the second one (the first was ADV, agreeing to 0.02 %).