From 5451e00806ff8a0ac653e0cd28fb0e4f6dd6a24f Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Mon, 31 Aug 2026 02:22:28 +0000 Subject: [PATCH] re: bgm-two-stems.md said the menu's bank is undecodable from the disc, and its own page decodes it The Status line and the section heading both read 'undecodable from the disc' while a later section of the same page decodes it three ways, one of them static from the executable -- GamePart_Title's handler does li r5, 1103. A reader who stops at the top concludes the opposite of what the page establishes. The surviving content is the reason the CUE TABLE cannot answer it: 32 BGM cues named by number with no screen name, with SOUNDS, FILES and the bank headers all searched. A negative about one search location, written as a negative about the disc -- the same method-versus-subject error as the SE-audio heading, in the first line a reader sees. It propagated: the port's BLOCKED.md carries 'which BGM the menu plays -- not on the disc' in the same words. Found by applying sylpheed-port's 'get the category right' discipline to my own noisy impossibility sweep, after measuring what the false positives actually were rather than assuming they were infrastructural. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/re/structures/bgm-two-stems.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/docs/re/structures/bgm-two-stems.md b/docs/re/structures/bgm-two-stems.md index 031384a1..8dfe5097 100644 --- a/docs/re/structures/bgm-two-stems.md +++ b/docs/re/structures/bgm-two-stems.md @@ -3,7 +3,7 @@ **Status:** ✅ `CONFIRMED` for the structure — **decoded**, with a disc-wide check over all 32 BGM banks. 🟡 for the *role* of the second wave — **measured** by signal analysis, and the two readings that survive are named below. ❔ which bank -is the menu's music is **undecodable from the disc**, with the reach stated. +is the menu's music was recorded here as **undecodable from the disc** — 🔴 **that was wrong and is corrected below**: it is **decoded**, `BGM_103`, named by the executable itself. The negative was true of the **cue table**, not of the disc. Answers [MISSION Q10](../../port/MISSION.md). It also **withdraws the premise**: the handoff said `BGM_001.slb` is *three* sub-waves of 10 KB / 4.47 MB / 4.67 MB. The @@ -162,7 +162,21 @@ over mono content). What would settle it is a runtime observation — whether th game submits both waves to the mixer at once — which needs an emulator with audio this container does not have. -## ❔ Which bank is the menu's music — undecodable, and here is the reach +## ~~❔ Which bank is the menu's music — undecodable, and here is the reach~~ + +> 🔴 **SUPERSEDED by this page's own "The menu's music is `BGM_103`" section +> below.** The heading is **false as written**: the bank *is* determined on the +> disc — `GamePart_Title`'s phase handler does `li r5, 1103` — so a reader who +> stops here concludes the opposite of what the page establishes. +> +> What survives is the reason the **cue table** cannot answer it: its 32 BGM cues +> are named `BGM_001`…`BGM_109`, pure numbers, with no screen name anywhere, and +> `SOUNDS`, `FILES` and the bank headers were all searched. That is a negative +> about **one search location**, and it was written as a negative about the disc. +> +> ⚠️ It propagated: the port's `BLOCKED.md` carries *"which BGM the menu plays — +> ❔ not on the disc"* in the same words. + The cue table binds cue names to sound ids and banks ([`sound-cue-table.md`](sound-cue-table.md)), and its **32 BGM cues are named