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

re: the seek chunk's layout is readable, its packet count is not

Browse Source 
Identified the structure: a little-endian size field after the tag, then
0x01000000, a varying word, a zero, then a strictly ascending table. Sizes 64 /
108 / 348 bytes for three sample banks.

Neither obvious reading gives the declared packet count. Entry count minus the
three header words is exactly right for VOICE_D_452 (13) and wrong for the other
two (24 vs 17, 84 vs 371) -- a one-of-three fit, recorded as FAILED rather than
as a rule with exceptions, because two measurements today already returned
plausible numbers for questions they could not answer.

The ascending values step by 1.5-2.2 million, far too large to be packet
indices, so they are on some other scale. Recorded what the next attempt should
know, including that auto/slb-loader chains seek packet counts successfully by
some field that is not either of the two tried here.
This commit is contained in:
Sylpheed RE agent
2026-08-26 05:16:12 +00:00
parent a047e095c0
commit 975d5b6519
1 changed files with 44 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -392,3 +392,47 @@ What survives:
* ❌ Both my "69.8 % are truncated" and my attempted reversal of it are off the
table. The measured fact is unchanged and narrow: **the declared `data` size
exceeds the TOC window for 5 296 of 7 586 banks.**
## ❔ The `seek` chunk's layout — identified, but it does not yield a packet count
The decoder-independent boundary signal this page called for is the `seek`
chunk. Its **shape** is now readable; its **arithmetic** is not.
Immediately after the `seek` tag sits a little-endian size, then a short header,
then a strictly ascending table:
eng\etc\VOICE_D_452 seek at +3 440 size 64 -> 16 words
eng\Voice\VOICE_TCAF_592 seek at +9 660 size 108 -> 27 words
eng\Voice\VOICE_TCAF_608 seek at +28 092 size 348 -> 87 words
words after seek+8 (big-endian):
0x01000000, <varies>, 0, then ascending: 0, 1572864, 3932160, 6160384, ...
Word 0 is `0x01000000` in every bank examined — a version or entry-size marker.
Word 1 varies and its top byte is 14 / 25 / 85 for the three above. Word 2 is 0,
and the ascending run begins after it.
**Two readings tried, both fail:**
| reading | D_452 | TCAF_592 | TCAF_608 |
|---|---|---|---|
| declared `data` size ÷ 2048 (packets) | 13 | 17 | 371 |
| `seek` size ÷ 4 (entries) | 16 | 27 | 87 |
| entries − 3 header words | **13 ✅** | 24 ✗ | 84 ✗ |
The third row is the near-miss that would be easy to adopt: it is exactly right
for `VOICE_D_452` and wrong for the other two. That is a one-of-three fit, and
this page has already recorded two measurements today that returned plausible
numbers for questions they could not answer — so it is recorded as **failed**,
not as a rule with exceptions.
The ascending values are not packet indices: the steps (≈1.5–2.2 million) are far
too large for a bank of a few hundred packets, so they are sample or
fixed-point offsets on some other scale that has not been identified.
**What the next attempt should know**: the chunk is real, its size field is
little-endian, three header words precede the table, and the entry count is
*not* the packet count. `auto/slb-loader` reports chaining `seek` packet counts
successfully across consecutive entries — whatever field it used is not one of
the two tried here, and reconciling the two readings is the cheapest way in.