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

re: the scattered block bytes are an XACT-shaped cue record naming a real cue

Browse Source 
Not noise -- a small structured record in three runs at about +1790, +3840 and
+7940. Across all 282: the leading 16-bit value names a real SOUNDS cue
282/282, the block carries two IEEE 1.0 floats in 281, and an 01/02/02/0x64 tail
in 281. Two unit floats and a 100 are the shape of volume, pitch and priority,
so this reads as an XACT cue record -- marked yellow, since every value is a
default and nothing varies enough to prove it.

The id is NOT this entry's own cue: it is consistently a different, higher one
(8501 -> 8504 = BR02_01; 5027 -> 5036 = VOICE_A_036), with a varying offset so
not a fixed stride. BR09_04's field names BR10_03, which is itself the next such
entry -- suggestive of a chain, but one observation and untested.

The practical point, which is settled: the block is a populated metadata record
naming a real cue, not padding.
This commit is contained in:
Sylpheed RE agent
2026-08-26 06:29:06 +00:00
parent 83493c848f
commit 090bf0cf36
1 changed files with 42 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -669,5 +669,45 @@ the same banks, `data_bytes / PsuedoBytesPerSec` gives 481 321 / 410 525 /
81 383 samples against `w1` of 445 440 / 410 624 / 75 264. `w1` lands within 512
of the true length in only **9 of 282**.
❔ The remaining ~40 scattered non-zero bytes in the 12 KiB block are still
unidentified.
### 🟡 The scattered bytes are an XACT-shaped cue record
**2026-08-26.** The ~40 remaining non-zero bytes are not noise; they are a small
structured record in three runs at roughly +1790, +3840 and +7940 within the
block. Two entries side by side:
+1790 2138 00000011 00000020 00000001 00000048
+1814 08000001a0c80000 2138 00000005 0010 0004 3f800000 3f80...
+3838 2138 00000011 00000001 ... 2138 00000011 ... 2138 ffffffff ... 01
+7935 00000001 00000002 00000002 00000064
+1798 214b 00000011 00000020 00000001 00000048 (the next such entry)
Measured across all 282:
| | |
|---|---|
| the leading 16-bit value **names a real `SOUNDS` cue** | **282 / 282 (100 %)** |
| the block contains `3f800000 3f80…` — **two IEEE 1.0 floats** | 281 |
| the block contains the tail `01 / 02 / 02 / 0x64` | 281 |
Two unit floats and a `100` are the shape of **volume, pitch and priority** —
this reads as an XACT cue record. That is a reading of the shape and is marked
🟡; the values are all defaults, so nothing here varies enough to prove it.
**❌ The id is not this entry's own cue.** It is a real id, but consistently a
*different, higher* one:
entry BR01_02 id 8501 -> field 8504 = BR02_01
entry BR03_06 id 8518 -> field 8523 = BR04_04
entry BR09_04 id 8553 -> field 8558 = BR10_03
entry VOICE_A_027 id 5027 -> field 5036 = VOICE_A_036
The offsets vary (+3 to +9), so it is not a fixed stride. Note `BR09_04`'s field
names `BR10_03`, which is itself the next entry in this list — suggestive of a
chain through the exception entries, but that is one observation and I have not
tested it.
❔ **Not settled**: which cue the id refers to and why, and what the `0x11`,
`0x20`, `0x48`, `0x0010`, `0x0004` constants are. What *is* settled is that the
block is a populated metadata record naming a real cue, not padding — which is
the practical point for anyone parsing past it.