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

re: withdraw the 'Japanese banks are a separate format' item, one iteration later

Browse Source
This commit is contained in:
Sylpheed RE agent
2026-08-26 03:57:08 +00:00
parent d15b3d8d85
commit d6127a049e
3 changed files with 17 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/re/BACKLOG.md
View File

@@ -6,7 +6,7 @@ unknown, what evidence exists, and what the first step would be. Move an item in
---
## ⚠️ OPEN (2026-08-26) — the Japanese voice banks are not decoded
## ❌ WITHDRAWN (2026-08-26, same day) — the Japanese voice banks are NOT a separate format
The `sound.pak` census (see
[`structures/sound-pak-contents.md`](structures/sound-pak-contents.md)) shows
@@ -19,10 +19,13 @@ exactly, so this is a limit of the finding, not a defect in the reader.
Since `FILES` names the **Japanese** set and the game substitutes the language
directory, the undecoded half is the one the table actually points at.
**First step**: take one misaligned `jpn\` bank and one `RIFF`-less one, and
locate the audio by scanning for XMA1 packet structure rather than assuming a
fixed data offset. The English aligned banks are the control — the same scan
must find their known leading region.
**Resolved by that first step.** Scanning instead of assuming showed the offset
is simply `first_riff % 2048`, which takes four values disc-wide (1392, 1468,
1600, 1728) by language and subdirectory. The Japanese banks decode fine at
their own offset — median **70×** more audio on a 140-bank FFmpeg-verified
sample — and the same bug was silently affecting 1 873 `eng\Voice` banks. I had
mistaken a constant derived from `eng\etc\` for a property of the format. See
[`structures/slb-data-offset.md`](structures/slb-data-offset.md).
**Also open**: 2 of the 9 519 TOC entries are unaccounted for, and 55 English
banks have their first `RIFF` at or before offset 1392.