re: F3 -- the title plays BGM cues 1102 and 1103, from seven sites in its GamePart

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

docs/re/f3-title-plays-bgm-102-and-103.md

@@ -0,0 +1,84 @@
+# ✅ 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`](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`](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`](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`](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.