# ✅ 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`](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`](structures/bgm-two-stems.md) established equal duration by
decoding. The XMA1 `PsuedoBytesPerSec` fix
([`voice-region-leading-chunk.md`](structures/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 |

🔴 **An explanation I gave here was wrong and is withdrawn (2026-08-29).** It
said `BGM_001`'s declared **173.821 s** disagreed with a decoded **167.663 s**,
and that "declared covers the encoded stream including its trailing silence; the
decoded figure is where the audio stops". **There is no disagreement to explain.**
A full decode of `BGM_001` yields **173.809 s of PCM** — the 167.663 s is where
the music *fades out*, measured from the audio, and the stream continues silent
to its declared end **inside** that decode. Declared and decoded agree.

✅ **The declared-rate method is now cross-checked on three banks against
independent decodes**, and it is better than the first version of this page
claimed:

| bank | declared | decoded | agreement |
|---|---|---|---|
| `BGM_103` | 87.750 / 87.749 s | **87.744 s** | 5–6 ms |
| `BGM_102` | 37.487 s | **37.482 s** | 5 ms |
| `BGM_001` | 173.821 s | **173.809 s** | 12 ms |

⚠️ The conclusion that survives unchanged is the useful one: **trust it for
lengths, not for musical boundaries.** A bank's declared length includes whatever
silence the encode carries, so it is not a loop point — that has to be measured
from the audio, and for `BGM_001` that is 167.663 s, 6.1 s before the stream
ends.