F3 — which cue, if any, does the title play? (positive control required) #5

New Issue

fabi · 2026-09-04T15:48:07Z

fabi commented

2026-09-04 15:48:07 +00:00

"I also think that there is a sound track or effect missing at the title screen."

The export carries exactly one music track, bgm/main_menu.ogg, and the port plays nothing on the title. Whether the game does is unestablished.

Two questions. Which cue, if any, does the title play — the menu's is decoded (cue 1103 = BGM_103 via sub_821C5580) and the same route should answer it. And is there a one-shot sting when the plate appears, or when Ⓐ is accepted? Either would read to a player as "something missing".

⚠️ A negative needs a positive control (R4). Show the method finding the menu's cue before concluding the title has none. A method that finds nothing because it finds nothing is the instrument failure this project keeps meeting.

> *"I also think that there is a sound track or effect missing at the title screen."* The export carries exactly one music track, `bgm/main_menu.ogg`, and the port plays nothing on the title. **Whether the game does is unestablished.** **Two questions.** Which cue, if any, does the *title* play — the menu's is decoded (cue 1103 = `BGM_103` via `sub_821C5580`) and the same route should answer it. And is there a one-shot **sting** when the plate appears, or when Ⓐ is accepted? Either would read to a player as "something missing". > ⚠️ **A negative needs a positive control (R4).** Show the method finding the *menu's* cue before concluding the title has none. A method that finds nothing because it finds nothing is the instrument failure this project keeps meeting.

fabi added this to the Menus milestone 2026-09-04 15:48:07 +00:00

fabi added the agent/decoder state/proposed kind/item labels 2026-09-04 15:48:07 +00:00

fabi added state/approved and removed state/proposed labels 2026-09-04 15:59:16 +00:00

fabi referenced this issue from a commit

2026-09-11 22:29:55 +00:00

re: F3's sting half -- the mechanism is decoded, the value isn't (issue #5)

sylph-decoder commented

2026-09-11 22:30:08 +00:00

BGM half: already ✅ decoded, no new work — f3-title-plays-bgm-102-and-103.md
(cues 1102/1103).

Sting half: docs/re/f3-title-sting-mechanism-found-not-value.md,
in #23 (dff5f77). R4's control still holds — this reuses the exact 34-call
census that demonstrably finds the menu's cue, and extends it.

What's new: the BGM census resolved a literal cue-id argument before
every call; two of the 34 calls don't have one (a register passthrough, a
memory load). One of those chains through a generic 6-caller wrapper into
slot 1 of GamePart_Title's own dispatch table (0x820a3dec, named by its
adjacent RegisterToFactory<0, class silph::GamePart_Title> string — not a
neighbourhood guess), reaching the same play primitive with a non-literal,
could-be-SE-range cue id.

Where it stops, honestly: the field that would pin the actual value
traces to a 19-caller shared helper's return value — too common to be
title-specific, reads as "allocate a handle" not "here is the cue". The value
is most likely set at whatever runtime moment the emitter is meant to speak,
which static analysis can't see. Classified undecodable, with reach — a
named call chain and a stated reason static analysis stops there, not "SE
goes through a different call" as before.

Every address cited was independently re-decoded from /image/sylpheed.pe's
raw bytes, not taken from the database's columns, and a refutation attempt
against the wrapper's "6 callers is exhaustive" claim (checking for indirect
dispatch) did not succeed — recorded either way per the adversarial-duty
requirement.

What would close it: --xma_param_probe=true during a title build-in, no
input, watching for a new stream when the plate reaches full alpha — the
same technique menu-audio-cues.md used for the menu's SE cues. Not run
this iteration; purely static work this time, dynamic is the next unit.

Not moving to state/needs-human — the BGM half was already answerable and
is; the sting half genuinely isn't closed, so this stays state/approved for
whoever picks up the dynamic half next (myself included, a future
iteration).

BGM half: already ✅ decoded, no new work — `f3-title-plays-bgm-102-and-103.md` (cues 1102/1103). Sting half: [`docs/re/f3-title-sting-mechanism-found-not-value.md`](../../docs/re/f3-title-sting-mechanism-found-not-value.md), in #23 (dff5f77). R4's control still holds — this reuses the exact 34-call census that demonstrably finds the menu's cue, and extends it. **What's new:** the BGM census resolved a literal cue-id argument before every call; two of the 34 calls don't have one (a register passthrough, a memory load). One of those chains through a generic 6-caller wrapper into **slot 1 of GamePart_Title's own dispatch table** (`0x820a3dec`, named by its adjacent `RegisterToFactory<0, class silph::GamePart_Title>` string — not a neighbourhood guess), reaching the same play primitive with a non-literal, could-be-SE-range cue id. **Where it stops, honestly:** the field that would pin the actual value traces to a 19-caller shared helper's return value — too common to be title-specific, reads as "allocate a handle" not "here is the cue". The value is most likely set at whatever runtime moment the emitter is meant to speak, which static analysis can't see. Classified `undecodable, with reach` — a named call chain and a stated reason static analysis stops there, not "SE goes through a different call" as before. Every address cited was independently re-decoded from `/image/sylpheed.pe`'s raw bytes, not taken from the database's columns, and a refutation attempt against the wrapper's "6 callers is exhaustive" claim (checking for indirect dispatch) did not succeed — recorded either way per the adversarial-duty requirement. **What would close it:** `--xma_param_probe=true` during a title build-in, no input, watching for a new stream when the plate reaches full alpha — the same technique `menu-audio-cues.md` used for the menu's SE cues. Not run this iteration; purely static work this time, dynamic is the next unit. Not moving to `state/needs-human` — the BGM half was already answerable and is; the sting half genuinely isn't closed, so this stays `state/approved` for whoever picks up the dynamic half next (myself included, a future iteration).

sylph-decoder referenced a pull request that will close this issue

2026-09-11 22:30:10 +00:00

re: land the F5/F6 title-clock corpus (docs/re, reference data, sylpheed-formats) #23

sylph-decoder commented

2026-09-12 12:40:46 +00:00

Sting half closed. docs/re/f3-sting-measured-no-new-stream.md,
in #23 (3d71388). Both halves of F3 are now answered:

BGM: ✅ already decoded (f3-title-plays-bgm-102-and-103.md, cues 1102/1103).
Sting: ✅ measured, no. Booted with --xma_param_probe=true (same
census menu-audio-cues.md used for the menu), no pad input, recording
continuously from window-open — a glyph time series plus every
newly-seen XMA stream, stamped on arrival.

R4's control is a real one: the probe's own log caught the title's two
BGM stems starting exactly when the already-established finding says they
should — proof it finds real streams before being asked to find nothing.
From the plate's first visible activity through 68 seconds of build-in
plus fully-settled pulsing, zero new streams appeared. No SE cue, no
second BGM, nothing.

Refutation attempt this iteration, recorded: my first read said BGM and
the plate's build-in start "at essentially the same moment" — the raw
per-sample series refutes that (first glyph activity is ~0.67s after BGM
onset, noisy rather than a clean climb). Corrected in the doc.

Reach: one boot, the boot title with no input. Doesn't cover the attract-loop
title or anything beyond the already-decoded confirm cue. Moving to
state/needs-human.

Sting half closed. [`docs/re/f3-sting-measured-no-new-stream.md`](../../docs/re/f3-sting-measured-no-new-stream.md), in #23 (3d71388). Both halves of F3 are now answered: * BGM: ✅ already decoded (`f3-title-plays-bgm-102-and-103.md`, cues 1102/1103). * Sting: ✅ **measured, no.** Booted with `--xma_param_probe=true` (same census `menu-audio-cues.md` used for the menu), no pad input, recording continuously from window-open — a glyph time series plus every newly-seen XMA stream, stamped on arrival. **R4's control is a real one**: the probe's own log caught the title's two BGM stems starting exactly when the already-established finding says they should — proof it finds real streams before being asked to find nothing. From the plate's first visible activity through **68 seconds** of build-in plus fully-settled pulsing, **zero new streams appeared.** No SE cue, no second BGM, nothing. Refutation attempt this iteration, recorded: my first read said BGM and the plate's build-in start "at essentially the same moment" — the raw per-sample series refutes that (first glyph activity is ~0.67s after BGM onset, noisy rather than a clean climb). Corrected in the doc. Reach: one boot, the boot title with no input. Doesn't cover the attract-loop title or anything beyond the already-decoded confirm cue. Moving to `state/needs-human`.

sylph-decoder added state/needs-human and removed state/approved labels 2026-09-12 12:40:47 +00:00

sylph-decoder referenced this issue

2026-09-12 12:40:49 +00:00

re: land the F5/F6 title-clock corpus (docs/re, reference data, sylpheed-formats) #23

fabi referenced this issue from a commit

2026-09-12 13:24:31 +00:00

re: fix two stale rows -- NEW GAME's destination, and my own repeat claim

fabi closed this issue

2026-09-13 11:16:19 +00:00

fabi removed the state/needs-human label 2026-09-17 19:02:19 +00:00

fabi referenced this issue from a commit

2026-09-19 20:29:48 +00:00