Range measured: level 0 post-shrub, 16047040..16737344, 690304 bytes.
Method: scan for a 16-byte header ending 0xff, then 10 zero bytes, then a run
of u32 whose top nibble is 0xF.
Result: 28 chunk headers on level 0, present on all 27 levels. Each chunk is
+0x00 16 bytes, last byte 0xff (opaque, differs per chunk)
+0x10 10 zero bytes
+0x1a N tagged offsets, top nibble 0xF
Within a chunk the offsets step by a chunk-specific stride. On level 0:
148, 340, 368, 288, 320, 236, 272, 384, 116, 160, 250, 580, 576. Near-constant
within a chunk, different between chunks.
This resolves two earlier results, both of which were half-right.
The 368-byte period is one chunk's stride, not a region property. That is why
the region-wide autocorrelation is flat: ~15 strides averaging to noise. The
15360-byte window where 368 scored +0.315 is the third chunk at region+30066,
whose stride is 368.
The "ten-entry table" earlier disconfirmed is real. Chunks carry 5 to 30 tagged
offsets, 10 most common on level 0. It was disconfirmed because I tested for a
fixed 148 stride across a whole region; the table exists, but 148 is one
chunk's stride among many.
Both errors were the same one: reporting a local measurement as a regional
property. Twice now. The control methodology caught neither, because a matched
control bounds significance but says nothing about scope.
Not decoded: the 16-byte header, the 0xF tag, where chunk data lives, and what
any chunk means. Framing established, contents not.
ReaperOfVeriod
1d6cddf3bb