diff --git a/docs/re/structures/slb-data-offset.md b/docs/re/structures/slb-data-offset.md
index 6c98eef..3b14d20 100644
--- a/docs/re/structures/slb-data-offset.md
+++ b/docs/re/structures/slb-data-offset.md
@@ -644,5 +644,30 @@ and not the *scale*: a uniform 10 % error preserves every ratio I checked. A
 self-consistency check cannot catch a systematic factor, and I should not have
 read it as confirmation of the value.
 
-🟡 `w0` remains unidentified. Neither trailer word matches the decoded length,
-so the "usable length" reading of `w0` is now less likely, not more.
\ No newline at end of file
+### ✅ `w0` and `w1` identified — they are the last two seek-table entries
+
+**Settled.** Both trailer words are a verbatim copy of the tail of the leading
+wave's own `seek` table:
+
+    w0 == table[-2]   282 / 282
+    w1 == table[-1]   282 / 282
+
+    packets  w0        w1        table[-2]  table[-1]
+    63       409 600   445 440   409 600    445 440
+    61       375 808   410 624   375 808    410 624
+    12        68 608    75 264    68 608     75 264
+
+That closes the question and disposes of the "usable length or loop end"
+reading of `w0` — it is simply the previous seek point. It also explains,
+without needing a separate fact, why `w1 − w0` is always a whole multiple of
+512: consecutive seek points advance by whole 512-sample XMA1 frames, so any two
+adjacent entries differ by a whole number of them. What looked like a meaningful
+constraint was a property of the table it was copied from.
+
+Consistent with the section above, neither word is the wave's true length: for
+the same banks, `data_bytes / PsuedoBytesPerSec` gives 481 321 / 410 525 /
+81 383 samples against `w1` of 445 440 / 410 624 / 75 264. `w1` lands within 512
+of the true length in only **9 of 282**.
+
+❔ The remaining ~40 scattered non-zero bytes in the 12 KiB block are still
+unidentified.
\ No newline at end of file