re: enumerate all 9661 waves, and measure a bank-to-wave assignment rule
Scanning the flat stream for seek chunks satisfying size == 8+4*count with a non-negative implied start yields 9661 waves and rejects NOTHING -- no false positives in a gigabyte of audio. Each wave's extent is [seek_pos - count*2048, seek_pos). Assignment rule 'an entry names the first wave starting at or after its offset' is 96.30% correct (7338/7620) against entries whose answer is independently known from their RIFF. The 282 exceptions are one class: the gap between the earlier wave's seek and the first RIFF is EXACTLY 12288 bytes in all 282. I guessed they were leading segments, which would put that seek AT the RIFF; refuted, 0 of 282. Recorded at yellow. Correcting by 12288 would reach 100% on this set but is curve-fitting until the region is identified, and the rule cannot yet unblock headerless durations -- there is nothing to check it against there.
This commit is contained in:
@@ -503,3 +503,43 @@ back to mono only when there is no `RIFF` to read. 7 disc tests pass.
|
||||
validate = 'seek' magic at data_at + declared_size (7 620/7 620)
|
||||
samples = the LAST u32 LE entry in the seek table
|
||||
channels = byte at RIFF + 49 <-- read it, never assume
|
||||
|
||||
## 🟡 Enumerating every wave on the disc, and a bank→wave assignment rule
|
||||
|
||||
**2026-08-26.** `auto/slb-loader` leaves open *"which bank in a window belongs to
|
||||
the entry's name"*. This is a measured attempt at it, short of settled.
|
||||
|
||||
**Every wave can be enumerated without reference to the TOC.** Scanning the
|
||||
1.01 GB flat stream for `seek` and keeping only chunks satisfying
|
||||
`size == 8 + 4·count` with a non-negative implied start gives **9 661 waves and
|
||||
rejects nothing** — not one false positive in a gigabyte of audio. The identity
|
||||
is that strong. Each wave's extent is then `[seek_pos − count·2048, seek_pos)`.
|
||||
|
||||
**The assignment rule.** Take an entry to name the **first wave starting at or
|
||||
after its offset**. Against the 7 620 entries where the answer is independently
|
||||
known (they carry a `RIFF`, so the wave is `data_at` for `declared_size`):
|
||||
|
||||
correct 7 338 / 7 620 = 96.30 %
|
||||
otherwise 282
|
||||
|
||||
**The 282 are one class, not a scatter.** In every one, the first wave ends
|
||||
earlier than the `RIFF`, and the gap between that wave's `seek` and the first
|
||||
`RIFF` is **exactly 12 288 bytes — the same value in all 282**. A constant that
|
||||
sharp is structural, not noise. 12 288 is 6 packets, and also 3 × the 4 096-byte
|
||||
`RIFF`+`Dmmy` block the other branch identified.
|
||||
|
||||
I first guessed these were leading segments, which would put the earlier wave's
|
||||
`seek` **at** the first `RIFF`. That is refuted: it happens **0** times out of
|
||||
282. Whatever occupies those 12 288 bytes is something else.
|
||||
|
||||
❔ **Not settled**: what the 12 288-byte region is, and therefore whether the
|
||||
rule should be "first wave at or after the offset" (96.30 %) or that rule with a
|
||||
12 288 correction (which would reach 100 % on this set but is curve-fitting
|
||||
until the region is identified). **First step**: dump those 12 288 bytes for
|
||||
several of the 282 and see whether they are a second `RIFF` block, a padded seek
|
||||
table, or audio.
|
||||
|
||||
⚠️ Consequence for the open duration question: this does **not** yet unblock
|
||||
headerless bank durations. The rule is 96.30 % on entries whose answer is
|
||||
checkable; on headerless entries there is nothing to check it against, so
|
||||
applying it there would be assuming the very thing that needs proof.
|
||||
|
||||
Reference in New Issue
Block a user