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

re: ran the decode test -- the bank data does not continue past the TOC window

Browse Source 
Read VOICE_TCAF_608's full declared 759808 bytes out of the flat stream ignoring
window boundaries. It decodes to the same 896 bytes (0.01 s) as stopping at the
window end -- 86x more input, zero extra samples. Control VOICE_D_452, whose
declared size fits, decodes to 2.18 s normally. No segment join is crossed, so
the packing phase is not a confound.

So 'the bytes are outside the window but still in the stream' does not hold for
the one bank the other branch named as not truncated. I still withdraw my word
'truncated' as an over-claim about the other 5295 banks: I measured that their
declared size exceeds their window, not what lies beyond it, and have now tested
exactly one. Recorded the three claims at their actual strengths.
This commit is contained in:
Sylpheed RE agent
2026-08-26 05:04:50 +00:00
parent a3c6a6502c
commit e368c7064c
1 changed files with 27 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/re/structures/slb-data-offset.md
View File

@@ -321,10 +321,30 @@ with a bank's data simply continuing past its window. But "declared sizes are
exact" requires a wave to span many named entries, which is a much stronger
claim than "the bytes are outside the window".
❔ **Unresolved.** The other branch's own open question — *"which bank in a window
belongs to the entry's name (some windows hold two, ids drift)"* — is the same
question from the other side, and settling it is what would decide this.
**First step**: take `VOICE_TCAF_608`, read 759 808 bytes from its `data` chunk
straight out of the flat stream ignoring window boundaries, and decode. If it
yields ~8 s of continuous speech, the data really does span windows; if it turns
to noise at the window edge, it does not.
### ✅ The experiment was run — the data does not span windows
Read `VOICE_TCAF_608`'s declared 759 808 bytes straight out of the flat stream,
ignoring the window boundary, and decoded through FFmpeg's `xma1`:
| read | bytes in | decoded |
|---|---|---|
| `data` → window end | 8 864 | 896 bytes = **0.01 s** |
| `data` → full declared size | **759 808** | 896 bytes = **0.01 s** |
| control `VOICE_D_452`, declared fits | 26 624 | 208 970 bytes = **2.18 s** |
**Reading 86× more bytes yields not one extra sample.** The bytes past the
window are not this bank's audio, so "the bytes are outside the TOC window but
still in the `.pNN` stream" does not hold here — and this is the very bank the
other branch named as *not* truncated. (No segment join is crossed: the read
sits inside `sound.p02`, so the packing phase is not a confound.)
So for `VOICE_TCAF_608` the audio really is not present. I still withdraw the
word **"truncated"** as an over-claim about the other 5 295 banks — I measured
that their declared size exceeds their window, not what is in the bytes beyond
it, and I have now tested exactly one of them. What is established is narrower
and worth stating exactly:
* ✅ the declared `data` size exceeds the TOC window for 5 296 of 7 586 banks;
* ✅ for `VOICE_TCAF_608` the missing bytes cannot be recovered from the stream;
* ❔ whether that generalises is **untested** — the same decode would have to be
run across the population, which is the obvious next step and was not done.