From c479d59f525b7c09a0c6f6eb60c03dc561c354f3 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 16:16:34 +0000 Subject: [PATCH] handoff: deliver the BGM_102 identification and the header-derived durations States the identification, the caution that it does NOT establish which screen BGM_102 belongs to, and the one thing the port can use today: BGM durations from the corrected XMA1 PsuedoBytesPerSec with no decoder. Flags that those durations include trailing silence -- BGM_001 reads 173.821 declared against 167.663 decoded, a gap matching the 6.15 s of silence this page already records -- so a menu loop point must use the decoded figure. Also records that a refutation attempt on this page s own BGM_103 wave sizes failed: both match the disc exactly. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/port/HANDOFF.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index ded10892..4608dacc 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -576,6 +576,42 @@ measurements *of channels*. ⚠️ **Reach: one cue, one boot.** That 28 cues are 3-stream is decoded from the bytes; that all three decode concurrently is measured on `ADV` alone. +## ✅ 2026-08-29 — the fifth and sixth streams were `BGM_102`, and you can now get BGM durations off the header + +[`bgm-102-decoded-during-boot.md`](../re/bgm-102-decoded-during-boot.md) + +The take-2 boot decoded **five** XMA streams and I could only account for three. +The other two — 1 150 976 and 1 269 760 B — are **`BGM_102.slb`'s two stems**, +found by searching every `sound.pak` entry for those payload sizes (one entry +carries *both*, which is the two-stem shape, not two coincidences) and recovering +the hash `9799c546` by candidate enumeration. So the boot was `ADV`'s three voice +streams plus one music bank, and nothing is unexplained. + +🟡 **Do not read that as "`BGM_102` is the attract music."** The window ran launch +→ t=253 s with the title at t=262 s, and the probe fires on *first decode* with no +timestamp on its line — a **title** BGM loaded moments before the title appears +fits the evidence equally. Cue 1103 is already your main menu, so 1102 as the +title is a live hypothesis, not a result. If you ever want it settled, say so and +I will timestamp the probe. + +✅ **Useful to you now: `sylpheed-cli audio info` gives BGM durations with no +decoder**, via the corrected XMA1 `PsuedoBytesPerSec`. Both stems of a bank agree: + +| bank | stem 0 | stem 1 | +|---|---|---| +| `BGM_102` | 37.487 s | 37.487 s | +| `BGM_103` (your menu track) | **87.750 s** | 87.749 s | +| `BGM_001` | 173.821 s | 173.821 s | + +⚠️ **These are declared durations and they INCLUDE trailing silence.** `BGM_001` +reads 173.821 s here against your decoded **167.663 s** — a gap of **6.158 s**, +and this page already records 6.15 s of silence after its fade-out. So the two +figures are consistent: declared = encoded stream, decoded = where the audio +stops. **For a menu loop point, use the decoded figure, not this one.** + +🟢 **Refutation attempt on this page's own `BGM_103` claim: it survived.** The two +declared waves read 3 876 864 / 3 930 112 B off the disc — exact. + ## Status | | Question | State | Answer / link |