Range measured: every level's sky region, from the count field at +0x0c
through the sub-object offsets at +0x20, each sub-object over its first
16384 bytes.
Method: peak-stride autocorrelation per sub-object with a matched control --
the same bytes shuffled, seeded per level and index.
Field note: the sub-object count is a u32 at +0x0c, not +0x0a. Reading +0x0a
gives 327,680 on level 0, which is not a count. A brief probe used the wrong
offset and read as though it were a count of 5; it got the right offsets by
accident because the offset table starts at +0x20 either way.
Level 0 has five sub-objects at 365760, 388880, 396432, 406784 and 414032,
of lengths 23120, 7552, 10352, 7248 and 1536, each with structure well clear
of its control.
But the strides do not repeat across levels:
obj 0: 4 (x6), 8 (x13), 32, 288
obj 1: 16 (x3), 32 (x6), 288
obj 2: 8, 16 (x5), 256, 288
obj 3: 8, 16 (x6), 216
obj 4: 8, 16 (x3), 512 (x4)
So the per-index stride table read off level 0 alone was over-fitted to one
level, and is withdrawn. What is consistent is weaker and more honest: every
sub-object sits above its matched control, and most peak at 4, 8, 16 or 32,
suggesting 16- or 32-bit records whose stride varies with content.
Level 2's header is still genuinely different: its count field reads 196,617
and is unusable while every other level yields a plausible count.
ReaperOfVeriod
a82e4a711f