From 7992e9d8f3c0bde0a9bd8cfa72ff400032595dd4 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 04:09:02 +0200 Subject: [PATCH] Note that the SBlk period is not a record boundary Range measured: level 0 SBlk, 24..19508, read at 4-byte alignment. The most common u32 values are 0x0 (2261), 0x1 (369), 0x7f (168), 0x5a000000 (125), 0x1eff7f7f (125), 0x1dfcc (124), 0x19fc0 (93), 0x7c34240d (91), 0x7c3821c8 (91). That does not look like a table of records with typed fields. A 40-byte layout of index, length and offset would not produce 0x1eff7f7f and 0x7c34240d a hundred times each, nor would those values survive a byte shift. So either the 40-byte period is not a record boundary, or the region is an encoded stream that happens to have a 40-byte statistical period. The 0x7f values point at the latter: in a varint encoding 0x7f is the largest value representable in seven bits, so it appears as a frequent saturated byte -- consistent with a coded stream, inconsistent with fixed-layout records. Left open. The 40-byte period is solid -- 27 of 27 levels, sharply isolated, multiples confirming -- and so is the alignment with four constant zero positions. But those two are in tension in a way nothing else in this project has been: a confirmed period that is not a record boundary. Someone attacking this format should not assume the record framing that the autocorrelation suggests. --- docs/formats/core-data-regions.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 5cf12b9..7854f82 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -640,3 +640,33 @@ accounting for before reading any field at a fixed offset. **Not decoded.** The layout is established and the constant positions are known; the fields are not named, and which of the 40 bytes are an index, a length and an offset is still open. + +## SBlk: the field values do not read as record fields + +**Range measured:** level 0 `SBlk`, 24..19508. + +**Method:** read at 4-byte alignment and rank the most common `u32` values. + +**Result:** the common values are `0x0` (2261), `0x1` (369), `0x7f` (168), +`0x5a000000` (125), `0x1eff7f7f` (125), `0x1dfcc` (124), `0x19fc0` (93), +`0x7c34240d` (91), `0x7c3821c8` (91). + +**This does not look like a table of records with typed fields.** A 40-byte +record layout whose fields are an index, a length and an offset would not +produce `0x1eff7f7f` and `0x7c34240d` a hundred times each, nor would those +values survive a byte shift. + +So either the 40-byte period is not a record boundary, or the region is an +encoded stream -- something like varint or Huffman-coded data -- that happens +to have a 40-byte statistical period. + +The `0x7f` values are suggestive: in a varint encoding a byte of `0x7f` is the +last value representable in seven bits, so it appears as a frequent +saturated byte. That is consistent with a coded stream and inconsistent with +a fixed-layout record. + +**Left open.** The 40-byte period is solid (27/27 levels, sharply isolated, its +multiples confirm it), and the alignment with four constant zero positions is +solid. What sits in those bytes is not a record layout, and the two findings +are in tension in a way this project has not otherwise seen: a confirmed +period that is not a record boundary.