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.