# 🟡 The menu BGM loop point — not captured, and why the obvious rig cannot take it

**Classification: not an answer.** Recorded per *"do not improvise around a
blocker"*: this says what was tried, what it cost, and the route that is left.

## The question

`BGM_103` is the menu track: two waves of **87.750 s** that play *together*
([`bgm-two-stems.md`](bgm-two-stems.md)). That page establishes the track **is not
a seamless loop** — `BGM_001` fades out with 6.15 s of silence after it — and that
**no loop-point field has been found in the XMA header**, so a menu loop is
currently **authored**. The port measures its bed restarting at 87.8 s with a
**3.4 s near-silent seam**.

What is missing is what the *game* does at that seam. Sitting on the menu for two
loop periods and recording would answer it.

## 🔴 The rig that seemed obvious does not work

Audio needs the ALSA `file` tee; detecting the title needs **video**, so
`--gpu=null` is unavailable. That combination was measured, twice:

| | |
|---|---|
| guest speed | **~0.20× real time** (76.5 s of audio in 378 s of wall clock) |
| title reached | **no** — not in 300 s, even after tapping Ⓐ to skip the movie |
| ALSA state at the end | `avail_update returned error: -32 (Broken pipe)`, then `ALSA underrun detected, recovering...` |

⚠️ **The emulator was not crashing** — memory was fine (rss 701 MB, 9.5 GB free) and
the `Killed` line in the log is this harness's own cleanup after the probe timed
out. The failure is simply that **rendering plus a PulseAudio-paced ALSA tee plus an
x11grab sampler is too slow to reach the menu**, and the tee's slave breaks under it.

## ✅ Refuted along the way — "`--gpu=null` runs here die at ~70 s"

[`CONTAINER-NOTES.md:98`](../agents/CONTAINER-NOTES.md) says `--gpu=null` runs
*"die at ~70 s with `PM4_DRAW_INDX: Failed in backend`"*. **That is not true of this
container now.** The intro-audio capture
([`intro-audio-output-census.md`](intro-audio-output-census.md)) ran `--gpu=null`
for **148.02 s** and ended because its probe's timer expired, with the emulator
still alive and the whole `ADV` movie decoded. More than twice the quoted lifetime,
so the claim does not hold as written; whatever produced it was either fixed or was
never general.

That matters because `--gpu=null` is the only configuration that gives a clean
capture (0.31 % silence, ~0.96× real time), and this note had been the reason not to
use it for anything long.

## The route that is left, for whoever picks this up

**Use the XMA probe log as the screen oracle, and drop video entirely.**
`bgm-two-stems.md` records that sitting on the main menu decodes exactly two
streams — **3 876 864** and **3 930 112 B**, `BGM_103`'s two declared waves. So:

1. boot `--gpu=null --apu=alsa --mute=false --xma_param_probe=true`, profile signed
   in (`title-a-press-fault.md`);
2. tap Ⓐ on a schedule to skip the movie and enter the menu — blind is acceptable
   because the guest runs near real time here;
3. **confirm arrival from the log, not the screen**: `BGM_103`'s two `byte_size`s
   appearing is the menu.

That replaces the video oracle with a log one, which is better provenance for an
audio question anyway — it evidences what is being *recorded* rather than what was
on screen. Not attempted; the iteration ran out.

⚠️ **Do not read this page as "the menu is unreachable".** Ⓐ into the menu is
measured and works ([`title-a-press-fault.md`](title-a-press-fault.md), leg B,
final glyph 327). What failed is one specific *recording* configuration.