Find a 40-byte period in the sound bank SBlk, on all 27 levels

Range measured: each level's SBlk region -- the descriptor table between
sblk_offset and daw_offset, from the sound bank header rather than from
core_data. 17-20 KB per level.

Method: peak-stride autocorrelation with a matched control, the same bytes
shuffled with the same seed on every level.

The peak is at exactly 40 bytes on all 27 levels, every one with excess above
0.2. On level 0 the peak is sharply isolated: 0.454 excess at stride 40
against 0.207 to 0.278 for strides 36 through 44, so it is a period rather
than a broad tendency.

This is the first structural result about the sound bank beyond the container
framing already committed.

Record counts are 487, 443, 428, 494 and 447 whole records on levels 0, 1, 2,
13 and 26, and the region is not an exact multiple of 40 on any level --
19484 leaves 4 bytes over -- so 40 is a period rather than a record size with
no remainder.

Unexplained: which byte positions are constant varies by level. Level 0 has
7, 11, 31 and 35 constant; level 1 has 15, 19, 23, 35 and 39; level 2 has 7,
23, 27 and 31. A fixed 40-byte layout would share its constant positions, so
either the records have a variable tail or 40 is a period in something the
records sit inside.

Also measured: DAW shows no stride above threshold against its control,
consistent with ADPCM nibble-packed audio and with the container framing being
the only part worth decoding. gameplay.bin peaks at 16 bytes. gs_ram.bin has
almost no stride structure but a lag-8 correlation of +0.503, so it is smooth
rather than tabular.

docs/formats/core-data-regions.md

@@ -458,3 +458,40 @@ that holds everywhere rather than on one level.
 **Not decoded.** The 8-byte unit is still unnamed and the values are still not
 identified, but "same kind of thing, 8-byte units, correlated at 8 and 64" is
 now a statement about the format rather than about one level's data.
+
+## Sound bank SBlk has a 40-byte period (27/27 levels)
+
+**Range measured:** each level's `SBlk` region -- the descriptor table between
+`sblk_offset` and `daw_offset`, from the sound bank header rather than from
+`core_data`. 17-20 KB per level.
+
+**Method:** peak-stride autocorrelation with a matched control (the same bytes
+shuffled, same seed, every level).
+
+**Result:** the peak is at **exactly 40 bytes on all 27 levels**, every one with
+excess above 0.2. The peak is also sharply isolated on level 0 -- 0.454 excess
+at stride 40 against 0.207 to 0.278 for strides 36 to 44 -- so it is a period
+rather than a broad tendency.
+
+That is the first structural result about the sound bank beyond the container
+framing already committed.
+
+**Record count:** 487, 443, 428, 494 and 447 whole 40-byte records on levels 0,
+1, 2, 13 and 26. The region is not an exact multiple of 40 on any level
+(19484 leaves 4 bytes over), so 40 is a period rather than a record size with
+no remainder.
+
+**Unexplained:** which byte positions are constant varies by level -- level 0
+has 7, 11, 31 and 35 constant; level 1 has 15, 19, 23, 35 and 39; level 2 has
+7, 23, 27 and 31. A fixed 40-byte layout would have the same constant
+positions everywhere, so either the records have a variable tail or 40 is a
+period in something else that the records sit inside.
+
+Also measured, for the record:
+
+- `DAW`, the sample region, shows **no** stride above threshold against its
+  control. Consistent with ADPCM nibble-packed audio, and consistent with the
+  container framing being the only part worth decoding.
+- `gameplay.bin` peaks at 16 bytes (excess 0.267 at strides 16, 32 and 64).
+- `gs_ram.bin` has almost no stride structure (0.043 at 32) but a lag-8
+  correlation of +0.503, so it is smooth rather than tabular.