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

re: refute the block-id chain -- 8 of 281 is coincidence

Browse Source 
Last iteration I noticed BR09_04's block id names BR10_03, itself the next
exception entry, and flagged it as suggestive but untested. Tested: sorting all
282 by offset, entry[i].field equals entry[i+1]'s own id in 8 of 281 (2.8%),
indistinguishable from chance -- and BR09_04 was one of the eight.

Recorded rather than dropped because it is exactly the kind of pattern that
reads as a discovery when spotted in a sample of one.

The offset from the entry's own id is broadly spread, 7 to 14 and beyond with a
peak at 9-11, so the field is near the entry's id without standing in any fixed
relation to it.
This commit is contained in:
Sylpheed RE agent
2026-08-26 06:34:59 +00:00
parent f189f5fc1f
commit 2634632787
1 changed files with 16 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -702,10 +702,22 @@ this reads as an XACT cue record. That is a reading of the shape and is marked
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.
The offsets vary, so it is not a fixed stride.
**❌ The chain reading is refuted.** I noticed `BR09_04`'s field names `BR10_03`,
which is itself the next exception entry, and flagged it as suggestive but
untested. Tested: sorting all 282 by offset, `entry[i].field == entry[i+1]`'s own
id in **8 of 281 (2.8 %)** — indistinguishable from coincidence, and `BR09_04`
was one of the eight. Recording it because it is exactly the kind of pattern
that reads as a discovery when spotted in a sample of one.
The offset from the entry's own id is broadly spread — 7 to 14 and beyond,
peaking at 9–11 — so the field is *near* the entry's id without standing in any
fixed relation to it:
BR01_02 own 8501 field 8504 = BR02_01
VOICE_A_027 own 5027 field 5036 = VOICE_A_036
VOICE_A_152 own 5152 field 5166 = VOICE_A_166
❔ **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