From 379c12f8ec97c97a431b168b7d6895804dcc18c5 Mon Sep 17 00:00:00 2001 From: ReaperOfVeriod Date: Sun, 11 Oct 2026 04:28:12 +0200 Subject: [PATCH] Identify the chunk header as a type ID that determines the record stride Range measured: all 27 levels, 1123 chunks. Method: group chunks by their 16-byte header; for each distinct header, collect the set of strides seen across every level it appears on. Result: only 64 distinct headers across 1123 chunks. The header is a type identifier, not a per-chunk descriptor -- the same 16 bytes recur on every level. And 63 of those 64 imply exactly one stride, so header to record layout is very nearly a function. The exception is header 7542eff271b522a79e45348cca4509ff, seen with strides 76, 92 and 104. Either three types share a header or one is a misparse. This also settles the previous entry's open question about D/E/F being incidental. Grouping by header bytes 9 and 13: DE 26 chunks, 2 strides (184, 344) EE 1050 chunks, 46 strides EF 34 chunks, 2 strides (268, 640) FF 13 chunks, 1 stride (520) Rare tags are tightly coupled to their layouts -- FF is a single stride across all 13 chunks -- while EE is heterogeneous. That is what a type tag looks like. Consequence: a chunk can be dispatched on its header to a record layout, and 63 of 64 headers give that layout's size without inspecting a record. First point in this container where a field does real work rather than correlating. Still open: what the 64 types mean, which record fields are index/length/offset, and whether any type is moby_anim. --- docs/formats/core-data-regions.md | 42 +++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index c14aa8d..2393675 100644 --- a/docs/formats/core-data-regions.md +++ b/docs/formats/core-data-regions.md @@ -832,3 +832,45 @@ so the ASCII in bytes 9 and 13 could be incidental. tags, which record fields are index/length/offset, and whether a chunk is moby_anim. The `D`/`E`/`F` values are suggestive enough to be worth testing against a known type table, but that has not been done. + +## The header is a type ID, and the type determines the stride + +**Range measured:** all 27 levels, 1,123 chunks. + +**Method:** group chunks by their 16-byte header; for each distinct header, +collect the set of strides observed across every level it appears on. + +**Result: only 64 distinct headers across 1,123 chunks.** The header is a +type identifier, not a per-chunk descriptor -- the same 16 bytes recur on +every level. + +**63 of the 64 headers imply exactly one stride.** So header to record layout +is very nearly a function: the type determines the record size. + +The single exception is header `7542eff271b522a79e45348cca4509ff`, which +appears with three strides, 76, 92 and 104. Either three types share a header, +or one of the three is a misparse. Not resolved. + +**The ASCII reading is confirmed as a type tag.** Grouping by header bytes 9 +and 13: + +| tag | chunks | distinct strides | +|---|---|---| +| `DE` | 26 | 2 (184, 344) | +| `EE` | 1050 | 46 | +| `EF` | 34 | 2 (268, 640) | +| `FF` | 13 | 1 (520) | + +The rare tags are tightly coupled to their layouts -- `FF` is a single stride +across all 13 of its chunks -- while `EE` is heterogeneous with 46. That +pattern is what a type tag should look like, and it settles the earlier +suggestion that the D/E/F bytes were incidental: they are not. + +**What this is good for.** A chunk can now be dispatched on its header to a +record layout, and 63 of 64 headers determine that layout's size without +inspecting any record. That is a usable parse entry point, and it is the first +point in this container where a field is doing real work rather than merely +correlating. + +**Still open:** what the 64 types mean, which record fields are +index/length/offset, and whether any type is moby_anim.