From e3c5eeae584eb33d8058c1f3f1b4ec8ab8a0ef18 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 04:18:53 +0000 Subject: [PATCH] re: check whether the scan's 99.62% transfers to the banks it is actually used on The labelled set has a RIFF and the scan is unbounded, so it reads past the RIFF there -- the headline number could have been borrowing discrimination that a RIFF-less bank cannot offer. Confining the scan to the leading region gives 69.98%, which looks like exactly that problem. It is not. Split by how much leading audio there is: on the 989 banks with >=24 packets of it, the scan is 100% correct with ZERO ties, whether or not the RIFF is in range. The 69.98% is an artifact of short leading regions, where two or three packets are not enough to separate candidates. A RIFF-less bank is a whole pak entry, so 24 packets are always available. The 99.62% is conservative for the population the scan serves, not optimistic. --- docs/re/structures/slb-data-offset.md | 31 +++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/re/structures/slb-data-offset.md b/docs/re/structures/slb-data-offset.md index f62cfcfe..ec7886d2 100644 --- a/docs/re/structures/slb-data-offset.md +++ b/docs/re/structures/slb-data-offset.md @@ -120,6 +120,37 @@ with a unique winner. `scan_data_offset` therefore falls back to 1392 on a tie. This is used only for the `RIFF`-less banks. Where a `RIFF` exists the offset is derived from it exactly, never scanned. +### Is that 99.62 % transferable? — checked, and it is conservative + +The labelled set has a `RIFF`; the population the scan actually serves does not. +Since the scan is unbounded it reads *past* the `RIFF` on labelled banks, so the +99.62 % could have been borrowing discriminating power that a `RIFF`-less bank +cannot offer. That would make the headline number optimistic for the only case +it is used in — worth checking before trusting it. + +Confining the scan to the leading region drops it to **69.98 %** with 1 910 +ties, which at first looks like exactly that problem. It is not. Splitting by +how much leading audio there is separates the two explanations: + +| | correct | ties | +|---|---|---| +| unbounded, all 7 358 labelled banks | 99.62 % | 28 | +| confined to the leading region, all 7 358 | 69.98 % | 1 910 | +| **≥24 packets of leading audio (989 banks), unbounded** | **100 %** | **0** | +| **≥24 packets of leading audio (989 banks), confined** | **100 %** | **0** | + +The last two rows settle it. Where there is enough audio to score, the +discriminator is perfect **whether or not the `RIFF` is in range** — so it is +not leaning on the `RIFF`. The 69.98 % is an artifact of *short* leading +regions: with only two or three packets to judge, candidates tie and the +tie-break decides. Unboundedness helps those banks by giving the scan more bytes, +which is why the two columns differ at all. + +A `RIFF`-less bank is a whole pak entry, tens of kilobytes, so 24 packets are +always available — it is always in the 100 % regime. **The 99.62 % figure is +therefore conservative for the population the scan is used on**, not optimistic. + + ## What this does not settle * **Why the offset takes those four values**, and what the bytes before it are.