Third and last site: the executable's play path. sub_821C5580's cue-1103
site is li r5,1103 / li r4,4 / lwz r3,0(r29) / bl 0x8217ACF8, i.e.
play(this, category, cue_id). No volume is passed and no float argument is
set up by the caller at all; the callee's prologue confirms r5 is the cue
id with -2 and -1 sentinels.
Honest limit stated: the callee saves f30/f31 so it uses floats internally
and could look a level up for itself. "No gain is passed" is not "no gain
exists" -- but there is nothing at this site for the port to transcribe.
So F2 closes as undecodable-with-reach with all three sites checked:
tables.pak cue records (exhaustive, passing control, and numbers carry
names there so a gain would have had one), sound.pak bank headers (all 9519
entries, no readable header), and the play path (category, not level).
The port authors the mix and now knows it is authoring, which is what this
question existed to make explicit rather than accidental. The one authored
value the game exposes is the user-facing sound options screen -- a runtime
master, not a per-cue table.
Refutation of the play-test's premise that "a cue record commonly carries a
volume beside its wave index": REFUTED for this game across all three sites
where it could live. Recorded because it was a good prior -- it is what
sent me to the right three places -- and being wrong about where a value
lives is different from being wrong to look.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
7535cfa3fe