re: withdraw my own generalisation -- decoded length cannot locate a bank boundary

Generalising the TCAF_608 test across the 5296 over-declaring banks first looked
like a clean reversal: 59 of 60 gained audio (median 2.10x) from reading the full
declared size instead of stopping at the TOC window.

Then I tested whether the declared size is an honest boundary by reading TWICE
it. 33 of 40 yield >1.5x more audio, median ratio 1.64. The decoder keeps going
indefinitely, because XMA1 packets are self-contained -- the next bank's packets
decode perfectly well and are simply not this bank's. A byte count cannot tell
them apart.

So the 59/60 is withdrawn as evidence for anything. Same error as the unanchored
'data' search earlier on this page: a measurement returning a plausible number
for a question it cannot answer.

What survives: TCAF_608 is genuinely anomalous (86x more input, zero extra
output, where the typical bank yields without limit); the honest-size question
is unresolved and needs a boundary signal independent of the decoder, such as
the seek-chunk packet chain; and the only measured fact is that the declared
size exceeds the TOC window for 5296 of 7586 banks.

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

@@ -348,3 +348,47 @@ and worth stating exactly:
 * ✅ for `VOICE_TCAF_608` the missing bytes cannot be recovered from the stream;
 * ❔ whether that generalises is **untested** — the same decode would have to be
   run across the population, which is the obvious next step and was not done.
+
+
+## ❌ Decoded length is not a valid test of where a bank ends — my own test withdrawn
+
+I set out to generalise the `VOICE_TCAF_608` result across the 5 296
+over-declaring banks, and the first pass looked like a clean reversal: on a
+random 60, reading the **full declared size** instead of stopping at the TOC
+window gained audio in **59**, median **2.10×**, up to 59×. That reads as
+"the data really does continue past the window", i.e. the other branch is right
+and my truncation reading was wrong.
+
+**Then I checked whether the declared size is an honest boundary at all**, by
+reading *twice* it. If the stream ends where the header says, doubling the input
+should add little:
+
+| | |
+|---|---|
+| reading 2× the declared size yields >1.5× the audio | **33 of 40** |
+| ratio of decoded bytes, 2× input vs 1× | median **1.64**, p90 1.75 |
+
+It keeps producing audio indefinitely. **XMA1 packets are self-contained**, so
+feeding the decoder the *next* bank's packets yields perfectly good audio that
+simply is not this bank's. The decoder cannot tell the difference, and neither
+can a byte count.
+
+**So the 59-of-60 result is withdrawn as evidence.** It does not show that the
+declared size is honest; it shows only that *something* decodes after the window,
+which was never in doubt — the bytes there are audio, just possibly someone
+else's. This is the same error in a new costume as the unanchored `data` search
+earlier on this page: a measurement that returns a plausible number for a
+question it cannot actually answer.
+
+What survives:
+
+* ✅ `VOICE_TCAF_608` is still special, and now more clearly so: for it, reading
+  86× more bytes gained **nothing**, where the typical over-declaring bank keeps
+  yielding audio without limit. Whatever is at its offset does not decode at all.
+* ❔ **Whether the declared sizes are honest is unresolved by this method** and
+  cannot be resolved by it. A valid test has to identify the bank boundary
+  independently of the decoder — the `seek`-chunk packet-count chain used on
+  `auto/slb-loader` is exactly such a signal, and is the right next step.
+* ❌ Both my "69.8 % are truncated" and my attempted reversal of it are off the
+  table. The measured fact is unchanged and narrow: **the declared `data` size
+  exceeds the TOC window for 5 296 of 7 586 banks.**