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

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

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 150270 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`