re: refuse a seek-based recovery of headerless bank durations

343 English headerless banks carry a valid seek chunk, which would lift dialogue
duration coverage from 62% to ~75%, with a median 3.25 s that looks exactly like
in-mission voice.

It is wrong. A seek sits immediately after its OWN data, so the implied wave
start is seek_pos - packets*2048 -- and for 277 of the 343 that start lies
BEFORE the entry begins, meaning the seek describes the previous bank's wave.
Applying it would attach a neighbour's duration to 81% of the recovered rows.
The 66 that start inside the entry are not proven to be that entry's wave
either; 'starts inside' is necessary, not sufficient.

Recorded as refused rather than applied with a caveat, because a plausible
median is exactly what has misled this work twice today. Recovering these needs
the bank-to-wave assignment settled first.
This commit is contained in:
Sylpheed RE agent
2026-08-26 05:52:02 +00:00
parent 652795e2b1
commit 1591481ca0

View File

@@ -174,6 +174,40 @@ The difference is not academic:
MSG_VOICE_D_342 "Katana, Ellen, good work." eng 4.18 s jpn -
❔ Not settled: the 38 % of call sites with no English duration. They are
headerless banks, so the audio exists but its length is not recoverable from a
`seek` table — it would have to come from the packet count, which for a
headerless bank means the whole entry, and the entry is not the wave boundary.
headerless banks. **A `seek`-based recovery was tried and does not work** — see
below.
### ❌ Recovering headerless durations from the `seek` chunk — tried, refused
A headerless bank has no `RIFF`, so no `data` size to read. But a `seek` chunk
describes the wave *ending* at its own position, so an entry carrying one looks
like it should yield a length for free. Across the bank set:
| | eng | jpn |
|---|---|---|
| has a `RIFF` (already covered) | 3 686 | 4 301 |
| headerless **with** a valid `seek` | **343** | 419 |
| headerless, no `seek` | 353 | 380 |
| no entry for that language | 753 | 35 |
343 recoverable English durations would lift coverage from 62 % to about 75 %,
and the numbers look right — median **3.25 s**, p90 5.18 s, which is exactly the
shape of in-mission voice.
**It is still wrong.** A `seek` sits immediately after *its own* data, so the
implied wave start is `seek_pos packets × 2048`. Checking that:
wave starts BEFORE the entry begins : 277 of 343
wave starts inside the entry : 66 of 343
**For 277 of the 343, the `seek` describes the previous bank's wave, not this
entry's.** That is the same pairing rule that made my earlier `seek` readings
fail; taking the length anyway would attach a neighbour's duration to 81 % of the
recovered rows. Even the 66 that start inside the entry are not *proven* to be
that entry's own wave — "starts inside" is necessary, not sufficient.
The median 3.25 s is precisely the kind of plausible-looking figure that has
already misled this work twice today, so the approach is recorded as **refused**
rather than applied with a caveat. Recovering these lengths needs the bank→wave
assignment settled first — the open question `auto/slb-loader` records as *"which
bank in a window belongs to the entry's name"*.