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

handoff: deliver the BGM_102 identification and the header-derived durations

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 16:16:34 +00:00
parent 05d278173d
commit b07f8984e3
1 changed files with 36 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/port/HANDOFF.md
View File

@@ -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 |