01b8191d90
Recorded per 'do not improvise around a blocker'. The question is what the game does at BGM_103's loop seam, where the corpus has 'not a seamless loop, no loop-point field found, so the menu loop is authored' and the port measures a 3.4 s near-silent seam. Audio needs the ALSA tee; detecting the title needs video, so --gpu=null was unavailable. Measured twice: the guest runs at ~0.20x real time (76.5 s of audio in 378 s of wall clock) and the title is not reached in 300 s even after tapping A to skip the movie, with the tee's slave ending in a broken pipe and Xenia in underrun recovery. Not a crash -- rss 701 MB with 9.5 GB free, and the 'Killed' line is this harness's own cleanup. REFUTED along the way: CONTAINER-NOTES says --gpu=null runs here die at ~70 s. The intro-audio capture ran 148.02 s under --gpu=null and ended on its probe's timer with the emulator alive and the whole ADV movie decoded. More than twice the quoted lifetime. That note had been the reason not to use --gpu=null for anything long, which is exactly what a clean audio capture needs. The route left, written down rather than attempted: use the XMA probe log as the screen oracle instead of video. Sitting on the main menu decodes exactly BGM_103's two waves, so their byte_sizes appearing IS the menu -- which is better provenance for an audio question than a screenshot anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
3.5 KiB
🟡 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). 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 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) 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:
- boot
--gpu=null --apu=alsa --mute=false --xma_param_probe=true, profile signed in (title-a-press-fault.md); - tap Ⓐ on a schedule to skip the movie and enter the menu — blind is acceptable because the guest runs near real time here;
- confirm arrival from the log, not the screen:
BGM_103's twobyte_sizes 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, leg B,
final glyph 327). What failed is one specific recording configuration.