90b7c6ea26
A human says something is missing on the title. Something is: it plays BGM, and two different cues. Method with the control built in rather than bolted on. R4 wants a negative to show the method finding the menu's cue first; this method cannot produce a false negative for one screen because it does not look at one screen. It finds every call of the play function in the image and reads the cue each passes: 34 callers, cue ids 1103 x24, 1102 x3, 1107 x2, 1108, 1106, 1104, category 4 on every one. 1103 is the cue the corpus already attributes to the menu, and the method finds it 24 times. GamePart_Title's neighbourhood is 0x821C4xxx-0x821C7xxx per the registry page, and seven play sites fall inside it: 1103 at 0x821C52D0, 0x821C5620 (inside the phase handler sub_821C5580), 0x821C6188 and 0x821C6294; 1102 at 0x821C53B0, 0x821C5BA0 and 0x821C6DE0. So the title plays BGM_103 and BGM_102, and 1103 is the SAME cue as the menu's -- which is why a port playing nothing on the title sounds like something is missing rather than merely quieter. The sting is NOT answered and the page says exactly why: this play function carries ids in the 1102-1108 BGM range, the UI stings are SE_* cues with ids 1-322, and not one of the 34 sites passes an id in that range. SE goes through a different call and this method is blind to it by construction. That is a bounded negative about the instrument, not the game, and reading it as "no sting" would be the third time this corpus mistook a blind spot for a fact. Reach: exhaustive over every bl to 0x8217ACF8, so complete for that function. The GamePart attribution is by address neighbourhood and carries the registry page's own "by position and convention, not proven" caveat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
3.9 KiB
✅ F3 — the title does play music: cues 1102 and 1103, from its own GamePart
Status: ✅ decoded from the image for the BGM; ❔ not answered for the
sting. Instrument: ⟨image⟩ — every call site of the play function, read out of
/image/sylpheed.pe. 2026-09-02.
A human says something is missing on the title. Something is: the title plays BGM, and it plays two different cues.
Method — and the control is built into it, not bolted on
R4 requires a negative to show the method finding the menu's cue first. This method cannot produce a false negative for one screen, because it does not look at one screen: it finds every call of the play function in the whole image and reads the cue each passes.
sub_821C5580's call is play(this, category, cue_id)
(f2-no-gain-field-in-tables.md), so scanning
bl 0x8217ACF8 and back-resolving li r5,<imm> gives the map:
34 callers. cue ids passed: 1103 ×24, 1102 ×3, 1107 ×2, 1108, 1106, 1104
category argument: 4 on every one of them
✅ The positive control passes by construction. 1103 is the cue the corpus
already attributes to the menu (bgm-102-decoded-during-boot.md),
and the method finds it — 24 times. A method that returned nothing for the title
while also finding nothing for the menu would prove only that the method was
broken; this one demonstrably finds the thing it is supposed to find.
The answer
GamePart_Title's neighbourhood is 0x821C4xxx…0x821C7xxx — the phase store at
0x821c4fbc, the phase handler sub_821C5580, sub_821C6458, and the registered
creator sub_821C7D98
(boot-config-and-gamepart-registry.md).
Seven play sites fall inside it:
| site | cue | |
|---|---|---|
0x821C52D0 |
1103 | |
0x821C53B0 |
1102 | |
0x821C5620 |
1103 | inside sub_821C5580, the phase handler |
0x821C5BA0 |
1102 | |
0x821C6188 |
1103 | |
0x821C6294 |
1103 | |
0x821C6DE0 |
1102 |
The title plays cue 1103 (
BGM_103) and cue 1102 (BGM_102) — two cues, from seven sites, alternating across the part's phases.
📌 1103 is the same cue as the menu's. That is the useful shape for the port: the title and the menu are not two different pieces of music, and 1103 running across both is why a port that plays nothing on the title sounds like something is missing rather than merely quieter.
❔ The sting is NOT answered, and here is exactly why
The play function scanned here carries cue ids in the 1102–1108 range — the BGM
vocabulary. The UI stings the question asks about (SE_UI_DECIDE on Ⓐ, something
on the plate's arrival) are SE_* cues with ids 1–322
(data/se-ui-cues.txt), and not one of the 34 sites
passes an id in that range.
So SE goes through a different call, and this method is blind to it by construction. That is a bounded negative about the instrument, not about the game: it says nothing about whether a sting exists. Finding the SE play path — and running this same census on it — is the next step, and it is the same shape of work that just succeeded here.
⚠️ Do not read "no SE in this census" as "no sting". That inversion is exactly what R4's control requirement exists to prevent, and it would be the third time this corpus mistook an instrument's blind spot for a fact about the game.
Reach
⟨image⟩, exhaustive over every bl to 0x8217ACF8 in the whole 9.2 MB, so the
census is complete for that function. The GamePart attribution is by address
neighbourhood, which is the same convention boot-config-and-gamepart-registry.md
flags as "by position and convention, not proven" — the cue ids are certain, the
label "these seven are the title's" carries that page's caveat.