fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the .slb leading region is 1392+n*2048 — and my fix for it is withdrawn

Browse Source 
The structure is exact. In all five resupply banks the first RIFF sits at
HEADERLESS_DATA_OFFSET + n*2048, where 1392 is a constant this crate already
had and 2048 is the XMA1 packet size: n = 8, 1, 7, 22, 29. No free parameter
to tune, and the raw bytes agree -- high entropy from offset 0, then a zero
run immediately before the RIFF. VOICE_D_451 is the control, its single
packet being all zeros.

So I made the obvious fix, emitting that region as a sub-wave, and then
withdrew it on two measurements:

* It does not recover audio. Coverage went 5.4% -> 89.9% for VOICE_D_453, but
  the emitted stream decodes through FFmpeg to 1792 PCM bytes -- silence --
  while the RIFF sub-waves from the same banks decode to 150-270 KB. Byte
  coverage was the wrong success metric and it looked like progress.
* It is not narrow. The rule matches 1524 of the 8021 RIFF-bearing entries in
  sound.pak, including RT* movie banks that decode correctly today. Landing
  it would have risked a wide regression in order to not-fix five banks.

to_xma_riffs is back to its previous behaviour, verified by re-measuring:
coverage is 5.4% / 9.7% again. The refuted attempt is recorded in the code
beside the branch it would have changed, so the next person does not
re-derive the arithmetic and re-make the change.

XMA1_PACKET is kept as a named constant because the blast-radius scan uses
it. Artifacts: examples/voice_bank_shape.rs (structure), voice_bank_dump.rs
(sub-waves for decoding), slb_hybrid_scan.rs (the 1524 count).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE
This commit is contained in:
Sylpheed RE agent
2026-08-25 23:30:42 +00:00
parent fedb31a5f9
commit 6fa6564be8
6 changed files with 133 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/re/BACKLOG.md
View File

@@ -1047,9 +1047,19 @@ premise was wrong.**
its leading region being 100 % zero / 1 distinct value. 🟡 So the in-game
verdict tested a decode that had thrown away most of the bank and is **not**
evidence against the binding — though it does not confirm it either.
▶️ First step: decode the leading region (it is not padding and not a RIFF —
directory? seek table? raw stream?). Then a human has to listen; audio
judgement cannot be done in this container. See
✅ **(same day) The region's SIZE is now exact**: the first `RIFF` sits at
`1392 + n*2048` in all five banks (n = 8, 1, 7, 22, 29) — 1392 being the
crate's own `HEADERLESS_DATA_OFFSET` and 2048 the XMA1 packet size. No free
parameter.
❌ **But my fix for it is WITHDRAWN.** Emitting that region as a sub-wave took
`VOICE_D_453` from 5.4 % to 89.9 % byte coverage — and the stream decodes to
**1792 PCM bytes**, silence, while the RIFF sub-waves decode to 150–270 KB.
Byte coverage was the wrong success metric. The rule also matches **1524 of
8021** RIFF-bearing `sound.pak` entries, including `RT*` banks that work today,
so it risked a wide regression to not-fix five banks.
▶️ Next cheap probe: vary the synthesised `fmt` (channels / streams / sample
rate) instead of assuming the container. Then a human has to listen; audio
judgement cannot be done here. See
[`voice-bank-leading-region.md`](voice-bank-leading-region.md).
* ❌ **(2026-08-25) My own boot-nav diagnosis, MEASURED AND WITHDRAWN.** I said
the run died because `skip_intro.sh` gates the title test at `rmse <= 1500`

44
docs/re/voice-bank-leading-region.md
View File

@@ -84,11 +84,49 @@ tested.
⚠️ This does **not** establish that the binding is right. It removes the only
recorded evidence against it.
## ✅ The region's structure — and ❌ my own fix for it, withdrawn
The leading region is not shapeless. In **all five** banks the first `RIFF` sits
at exactly `HEADERLESS_DATA_OFFSET + n * 2048` — where `HEADERLESS_DATA_OFFSET`
(1392) is a constant this crate already had, and 2048 is the XMA1 packet size:
| bank | first RIFF | − 1392 | ÷ 2048 |
|---|---|---|---|
| `VOICE_D_450` | 17 776 | 16 384 | **8** |
| `VOICE_D_451` | 3 440 | 2 048 | **1** |
| `VOICE_D_452` | 15 728 | 14 336 | **7** |
| `VOICE_D_453` | 46 448 | 45 056 | **22** |
| `VOICE_D_454` | 60 784 | 59 392 | **29** |
Exact on 5/5, with no free parameter to tune. The byte layout is a 1392-byte
header, a whole number of 2048-byte packets, then the RIFF section — and the
raw bytes agree: high-entropy from offset 0, then a zero run immediately before
the `RIFF`. `VOICE_D_451` is again the control: its one packet is all zeros.
**So I made the obvious fix — emit that region as a sub-wave — and then withdrew
it.** Two measurements killed it:
* **It does not recover audio.** Coverage rose from 5.4 % to 89.9 % for
`VOICE_D_453`, but the emitted stream decodes through FFmpeg to **1792 PCM
bytes** — silence — while the RIFF sub-waves from the same banks decode to
150–270 KB. Byte coverage was the wrong success metric, and it looked like
progress. The region is shaped like a packet stream but is not XMA1 under the
synthesised format.
* **It is not narrow.** The rule matches **1524 of the 8021** RIFF-bearing
entries in `sound.pak` (1524 with a non-zero leading region), including `RT*`
movie banks that decode correctly today. Landing it would have risked a wide
regression in order to not-fix five banks.
The refuted attempt is recorded in `slb.rs` beside the code, so the next person
does not re-derive the arithmetic and re-make the same change.
## What this does not settle
* ❔ **What the leading region is.** It is not padding and not a RIFF. Whether it
is a directory, a seek table, an alternate codec stream, or the audio itself is
unestablished — I did not decode it.
* ❔ **What the leading region holds.** Its *size* is now exact (1392 + n·2048)
and it is neither padding nor a RIFF, but it does not decode as XMA1. A seek
table, a different codec, or a different channel/rate configuration all remain
open. The next cheap probe is to vary the synthesised `fmt` (channels, streams,
sample rate) rather than to assume the container.
* ❔ Whether `hokyu_DS_s13A` really plays `VOICE_D_452`. That needs the leading
region decoded *and* a human listening; audio judgement cannot be done here.
* ❔ Whether the same leading region exists across the other ~9 500 `sound.pak`