From 0f0c6610c4d89e9aa415097d60052a5aed341acd Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Wed, 2 Sep 2026 17:36:59 +0000 Subject: [PATCH] re: F2 second site checked -- sound.pak carries no readable bank header either Continued F2 at the site the previous page named as the first thing to do. dat/sound.pak is a 114 KB index over ~1 GB of payload across sound.p00-p04. Its 9519 entries carry no readable signature at all: the most common first-four-bytes pattern is "...." on 3830 entries and no entry begins with an ASCII magic. Exactly one entry is under 4 KB (#9454, 533 bytes), where a bank header or wave index would be small and structured. So the SE bank's metadata is not reachable as a header in sound.pak. The entries are audio payload, high-entropy by nature, and a gain beside a wave index is not sitting in front of them. Stated as a negative about REACHABILITY, not existence: a per-wave gain could live inside a container these entries are compressed into and I have not decompressed one. Two of three sites now checked, both negative; the executable around sub_821C5580 remains. Classification unchanged at undecodable-with-reach, but better bounded. Records the shape the answer is taking: if the executable also has no per-cue gain, the honest conclusion is that the game does not author a per-cue mix at all and the levels come from the user-facing sound options screen as runtime state. That makes the port's job authoring a master balance rather than transcribing a table -- undecodable rather than decoded, which it must know, because a mix authored in ignorance and one authored deliberately look identical in the file and differ entirely in how far they can be trusted. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- docs/re/f2-no-gain-field-in-tables.md | 42 ++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 7 deletions(-) diff --git a/docs/re/f2-no-gain-field-in-tables.md b/docs/re/f2-no-gain-field-in-tables.md index b7fbc84d..30385364 100644 --- a/docs/re/f2-no-gain-field-in-tables.md +++ b/docs/re/f2-no-gain-field-in-tables.md @@ -48,17 +48,27 @@ one" into "one is not there **in this file**". ## ⚠️ Reach — the two places I did NOT look -1. **The `.slb` bank headers.** `BANK_SE` names a single bank, `Static.slb`, and a - per-wave gain beside a wave index is the other conventional home for this. The - banks are **inside paks** — no `.slb` exists on the extracted disc as a loose - file — so inspecting the header costs a pak extraction I did not have budget - for this iteration. **This is the first thing the next attempt should do.** +1. ~~**The `.slb` bank headers.**~~ ✅ **CHECKED 2026-09-02 — also negative, and + for a structural reason.** `dat/sound.pak` is a **114 KB index over ~1 GB of + payload** (`sound.p00`…`.p04`). Its **9 519 entries carry no readable + signature at all**: the most common first-four-bytes pattern is `"...."` on + 3 830 entries, and no entry begins with an ASCII magic. Exactly **one** entry + is under 4 KB (#9454, 533 bytes) — a bank header or wave index would be small + and structured, and there is essentially no such thing here. + + **So the SE bank's metadata is not reachable as a header in `sound.pak`.** The + entries are audio payload, which is high-entropy by nature; a gain beside a + wave index is not sitting in front of them. + ⚠️ This is a negative about **reachability**, not about existence: a per-wave + gain could live inside a container these entries are compressed into, and I + have not decompressed one. 2. **The executable.** A mix could be immediates in the sound-play path; `sub_821C5580` is a decoded entry point into it. **So this is not yet "the mix is not on the disc".** It is *"the mix is not in the -table where a cue's fields live"*, which is a real narrowing and not the whole -answer. +table where a cue's fields live, and not in front of the bank payload either"* — +**two of the three sites checked, both negative.** The executable is the one that +remains. 📌 One adjacent fact, offered as a pointer and not a finding: object #15 lists `po_sound_scr.prt → SOUND` among `GP_OPTIONS`' screens. **There is a user-facing @@ -85,3 +95,21 @@ matters.** The cue *records* in `tables.pak` carry an id and a name and no volum But "beside its wave index" points at the **bank**, not the table, and the wave index lives in the `.slb`. The framing is sound; it just aims at a file this page did not open. + +## Status after the second site — still `undecodable, with reach`, and now better bounded + +| site | checked | result | +|---|---|---| +| `tables.pak` cue records | ✅ exhaustive, with a passing control | **no gain-like field** | +| `sound.pak` bank headers | ✅ all 9 519 entries | **no readable header to carry one** | +| the executable, around `sub_821C5580` | ❌ **not checked** | — | + +**For the port, unchanged: author nothing yet.** But the shape of the answer is +now visible. If the executable also has no per-cue gain, the honest conclusion is +that **this game does not author a per-cue mix at all** — and the levels a player +hears come from the user-facing sound options screen (`po_sound_scr.prt`, object +#15) applied as runtime state. That would make the port's job authoring a master +balance rather than transcribing a table, and it would be *undecodable* rather +than *decoded* — which the port must know, because a mix authored in ignorance +and a mix authored deliberately look identical in the file and differ entirely in +how much they can be trusted.