3a5f215179
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
105 lines
4.7 KiB
Markdown
105 lines
4.7 KiB
Markdown
# ✅ 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.
|