Archilyzer · Source

archilyzer

Archilyzer
git clone https://archilyzer.pages.dev/source/archilyzer.git
Log | Files | Refs | README | LICENSE

commit cf38a358bc11d38230c8d51b3f40a9a49fe380c5
parent 96b5989805a420125788b41dbd53d490fd90a1e5
Author: I Mean I'm Just Saying <imeanimjustsaying@kiwifarms.st>
Date:   Sat,  8 Aug 2026 05:41:15 -0400

Confirm what the isRealAudioFile bug costs, from the running backfill

The 3 predicted videos failed at [15/87]-[17/87] in 0s each. Reproduced
read-only to a temp path: ffmpeg reports 'Output file does not contain any
stream' on the VTT, and no sidecar is written anywhere.

The directory holds no real audio at all -- only audio.en-orig.vtt, a subtitle.
So the honest outcome is no-audio and the bug reports failed instead, which
collapses the exact distinction DiarizeOneOutcome was designed to preserve
('not set up' vs 'tried and broke'). Expect a final tally of 84 diarized + 3
failed, and 3 videos reported 'awaiting diarization' permanently.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Diffstat:
Mplans/FACTS.md | 36++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+), 0 deletions(-)

diff --git a/plans/FACTS.md b/plans/FACTS.md @@ -1717,3 +1717,39 @@ Bounded (913 real audio files against 3 fakes), but it is not only cosmetic: **Not fixed here.** Tightening the predicate to require a known media extension changes cleanup behaviour and touches several exact-string e2e assertions; it wants its own branch and a full e2e run, not a drive-by during a 25-hour job. + +### Confirmed in flight: what the `isRealAudioFile` bug actually costs + +The 3 predicted videos failed at **[15/87]–[17/87]**, in **0 s each** (fail-fast, +no wasted engine time). Reproduced read-only on +`chrissie-mayr/5UHN0qEoyVM`, output to a temp path — no sidecar written anywhere: + +``` +[out#0/f32le] Output file does not contain any stream +Error opening output files: Invalid argument +diarize-sherpa: ffmpeg failed (234) +diarize: engine exited 4 +``` + +That directory contains **no real audio whatsoever** — only `audio.en-orig.vtt`, +a subtitle, beside the usual `transcript.*`. So the honest outcome for these +videos is **`no-audio`**, and the bug makes them report **`failed`** instead. + +That is not cosmetic. `DiarizeOneOutcome` documents `not-configured` as +"reported distinctly from a failure so an operator can tell 'not set up' from +'tried and broke'" — the same distinction `no-audio` carries. A predicate that +invents audio collapses "there was nothing to do here" into "the engine broke", +which is precisely the signal an operator triages on. + +Two consequences to expect, both small and both permanent until it is fixed: + +1. The backfill's final tally will be **84 diarized + 3 failed**, not 87, and + those 3 fail identically on every re-run. +2. With the guard armed they are transcribed-and-undiarized forever, so the + cleanup sweep will report **3 videos "awaiting diarization" permanently**. + Ironically the guard is now the thing preventing `audioFilesToDelete` — which + shares the broken predicate — from deleting that subtitle as if it were audio. + +The fix is to require a known media extension rather than denylisting; it is +deferred to its own branch because it changes cleanup behaviour and several +exact-string e2e assertions.