fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: the menu BGM loop is NOT captured -- and the rig that cannot take it

Browse Source 
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
This commit is contained in:
sylph-decoder
2026-08-30 09:21:47 +00:00
parent 93e63b22f6
commit 01b8191d90
2 changed files with 75 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/agents/CONTAINER-NOTES.md
View File

@@ -96,6 +96,13 @@ python3 tools/re-capture/gmem.py find hex:820af844 400
silence and 0.01 gaps/s, against 9.98 % / 8.37 rendered. ⚠️ No video, so
screen-based provenance is unavailable (use the XMA probe), and `--gpu=null`
runs here die at ~70 s with `PM4_DRAW_INDX: Failed in backend`.
🔴 **REFUTED 2026-08-30 — that lifetime does not hold.** A `--gpu=null` capture
ran **148.02 s** and ended on its own probe's timer with the emulator still
alive, having decoded the whole `ADV` movie
([`intro-audio-output-census.md`](../re/structures/intro-audio-output-census.md)).
More than twice the quoted figure. Whatever produced the ~70 s was fixed or was
never general, and this note had been the reason not to use `--gpu=null` for
anything long — which is exactly the configuration a clean audio capture needs.
⚠️ **Do not read Canary's 6-channel PulseAudio stream as evidence the GAME is
5.1.** `pactl` will show `float32le 6ch 48000Hz`, channel-mapped to a full 5.1

68
docs/re/structures/menu-bgm-loop-not-yet-captured.md Normal file
View File

@@ -0,0 +1,68 @@
# 🟡 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.