From effda99390b269523ca60a8d269ffce3ed2a5d5f Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Wed, 26 Aug 2026 06:22:56 +0000
Subject: [PATCH] re: w0 and w1 are the last two entries of the leading wave's
 seek table

Both, 282/282 exact: w0 == table[-2], w1 == table[-1]. The trailer's first two
words are a verbatim copy of the tail of the wave's own seek table.

That closes the question and kills the 'usable length or loop end' reading of
w0 -- it is just the previous seek point. It also explains why w1-w0 is always a
multiple of 512 without needing a separate fact: consecutive seek points advance
by whole 512-sample frames, so adjacent entries always differ by a whole number
of them. What I had recorded as a meaningful constraint was a property of the
table the values were copied from.

Neither word is the wave's true length -- w1 lands within 512 of the
PsuedoBytesPerSec length in only 9 of 282, consistent with the correction above.

Still unidentified: the ~40 scattered non-zero bytes elsewhere in the block.
---
 docs/re/structures/slb-data-offset.md | 29 +++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/docs/re/structures/slb-data-offset.md b/docs/re/structures/slb-data-offset.md
index 6c98eef0..3b14d207 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