fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: F2 second site checked -- sound.pak carries no readable bank header either

Browse Source 
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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-02 17:36:59 +00:00
parent 02d7f9062b
commit 654c4f1e99
1 changed files with 35 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
docs/re/f2-no-gain-field-in-tables.md
View File

@@ -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.