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:
@@ -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`
|
||||
|
||||
Reference in New Issue
Block a user