Files

sylph-decoder 3a5f215179 re: withdraw a wrong explanation of the BGM_001 duration gap

I wrote that BGM_001 s declared 173.821 s disagreed with a decoded 167.663 s,
and explained the gap as declared covering the encoded stream including trailing
silence while decoded is where the audio stops. The port decoded it fully: the
bank yields 173.809 s of PCM. There is no disagreement -- 167.663 s is where the
music fades out, measured from the audio, and the stream continues silent to its
declared end inside that same decode.

So the declared-rate method is better than this page claimed, and is now
cross-checked on three banks against independent decodes: BGM_103 87.750 vs
87.744, BGM_102 37.487 vs 37.482, BGM_001 173.821 vs 173.809 -- agreement 5 to
12 ms.

The conclusion survives unchanged and is the useful half: trust it for lengths,
not for musical boundaries. A declared length includes whatever silence the
encode carries, so it is not a loop point.

Also records in METHOD a defect shape the port hit three times in one pipeline,
each invisible to every check except a level: normalising by how many inputs
there are rather than how many carry signal. A silent chunk in a voice sum, a
silent channel in a mono fold, and a silent sub-wave -- the 10240-byte bank
header wrapped to 10300 B -- counted as a third stem in a music sum, which put
every real stem at 1/3 instead of 1/2 and cost 3.52 dB on all menu music for two
iterations. This corpus s census said two waves and the exporter s divisor said
three; the count that disagrees with a census is the one that is wrong.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

2026-08-29 16:20:49 +00:00

4.7 KiB

Raw Blame History

✅ 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

🔴 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.

4.7 KiB Raw Blame History Unescape Escape

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