re: name two fields inside the 12288-byte block's trailer

The trailer opens with two little-endian u32 words. w1 is the leading wave's
total sample count -- 282/282 exact, the same number as the last entry of that
wave's own seek table. And w0 < w1 with w1-w0 always a whole multiple of 512
(282/282), i.e. a whole number of XMA1 frames, 9 to 91 with a median of 14.

What w0 means is left at yellow: trailing the total by a whole number of frames
is the shape of a usable-length or loop-end field, but that is a reading of the
shape rather than a measurement, and nothing here separates the candidates.

Also corrects my own description: I called the region after the seek chunk 'zero
padding'. It is not padding -- about 48 non-zero bytes are scattered thinly
across the 12 KiB, roughly 17 per KiB in blocks 1, 3 and 7. That is a sparse
table, still unidentified, and the distinction matters to anyone skipping it.

docs/re/structures/slb-data-offset.md

@@ -564,5 +564,40 @@ strict by a constant I had not yet discovered.
 the checkable set**, which is much stronger than the 96.30 % it replaced. It
 still cannot be *verified* on headerless entries — there is no `RIFF` there to
 check against — but "100 % wherever it can be checked, with a named structural
-reason for every case" is a materially better basis than before. ❔ What the
-47–57 non-zero trailer bytes hold is unidentified.
+reason for every case" is a materially better basis than before. The trailer's first two words are now identified — see below.
+
+
+## ✅🟡 Inside the 12 288-byte block's trailer
+
+**2026-08-26.** The block is `seek` chunk, then a trailer of 47–57 non-zero
+bytes, then zeros. Two of those bytes-groups are now named.
+
+The trailer opens with **two little-endian u32 words**, and across **all 282**:
+
+* ✅ **`w1` is the leading wave's total sample count** — 282 / 282, exact. It is
+  the same number as the last entry of that wave's own `seek` table, so the
+  block restates the wave's length in a directly readable field.
+* ✅ **`w0 < w1` in every case**, and **`w1 − w0` is always a whole multiple of
+  512** — 282 / 282. 512 samples is the XMA1 frame, so the difference is a whole
+  number of frames: **9 to 91, median 14**.
+
+Examples:
+
+    packets  w0        w1        leading wave's samples
+    63       409 600   445 440   445 440
+    61       375 808   410 624   410 624
+    12        68 608    75 264    75 264
+
+🟡 **What `w0` *means* is not settled.** A value that trails the total by a whole
+number of frames is the shape of a usable-length or loop-end field — decoder
+priming and the final partial frame are both counted in frames — but that is a
+reading of the shape, not a measurement, and nothing here distinguishes the
+candidates. It is recorded as 🟡 for that reason.
+
+❔ The remaining **~48 non-zero bytes** are scattered thinly across the 12 KiB
+rather than clustered — roughly 17 per KiB in blocks 1, 3 and 7, the rest empty.
+That is the shape of a sparse table, and it is unidentified.
+
+**A correction to how I described this block**: I called the region "zero
+padding" after the seek chunk. It is not padding — it is a sparse structure that
+is *mostly* zero. The distinction matters for anyone who tries to skip it.