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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 02:22:28 +00:00
parent 761ee28a17
commit 9bacd69f6c

View File

@@ -3,7 +3,7 @@
**Status:**`CONFIRMED` for the structure — **decoded**, with a disc-wide check **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 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 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 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 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 game submits both waves to the mixer at once — which needs an emulator with audio
this container does not have. 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 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 ([`sound-cue-table.md`](sound-cue-table.md)), and its **32 BGM cues are named