fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: check whether the scan's 99.62% transfers to the banks it is actually used on

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-26 04:18:53 +00:00
parent b7b29dcb05
commit e3c5eeae58
1 changed files with 31 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/re/structures/slb-data-offset.md
View File

@@ -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.