From 1591481ca086457052fb9bec58791ca9e6da4a1e Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 05:52:02 +0000 Subject: [PATCH] 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. --- .../structures/isl-message-dialogue-link.md | 40 +++++++++++++++++-- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/docs/re/structures/isl-message-dialogue-link.md b/docs/re/structures/isl-message-dialogue-link.md index 2caa890..a0cfe5c 100644 --- a/docs/re/structures/isl-message-dialogue-link.md +++ b/docs/re/structures/isl-message-dialogue-link.md @@ -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"*.