Record that incremental transcription was not built, and why - #12
Merged
Conversation
The document recommended engaging the live segmenter at 45 seconds and cutting every 30, taking it from 8% to 20% of dictations. That was written before the measurements that mattered, and it is now wrong in the direction that would cost users quality. Segmenting does not recover content: 0 of 10 long recordings gained more than 15% more text, six Mandarin recordings were consistently worse, and the maintainer's review of 258 aligned disagreements preferred the whole-file transcript. Blanket segmentation would trade a frequent small quality loss for protection against a rare large one, and the rare one now has a direct fix in the model. What the investigation actually found was a silent data-loss bug — gemini-3.5-flash truncating a long recording on 6 runs in 10, returning fluent text missing two thirds of what was said — and that the near-miss suite is structurally blind to it, because its cases are short clips and truncation only happens on long audio. That blind spot is the most reusable thing here and it is now stated first. The body/tail split, the rolling context, the `whole` policy and the aggressive live policy are all removed as recommendations and kept only as recorded rejections, so nobody re-derives them. Four more mistakes added to the list, each of which cost time: trusting a suite outside what it measures, scoring a Mandarin transcript with a Latin-only tokenizer, a synthetic fixture with less pause than real speech, and assuming a C# record struct honours its primary constructor's defaults. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015XKX6zEAGiZFE5wAxJgYbV
This was referenced Aug 25, 2026
This section said 'measured, not yet shipped'. It is shipped, so the document would have contradicted the code the moment both landed. Records what the streaming implementation costs, and the two edges that were wrong on the first attempt: a still-open speech run has to count when finding the newest gap, and fewer than two runs must hand the decision back to the energy finder rather than refuse to cut. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015XKX6zEAGiZFE5wAxJgYbV
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
docs/INCREMENTAL.mdcurrently recommends engaging the live segmenter at 45 s and cutting every 30 s, taking it from 8% to 20% of dictations. That was written before the measurements that mattered, and it is now wrong in the direction that would cost users quality.What the measurements said
Segmenting does not recover content. Ten recordings, 136–312 s, whole vs Silero-policy segments, no screen context:
segmenting recovered >15% more text on 0/10 recordings. Six Mandarin recordings were consistently worse.The maintainer reviewed the disagreements by ear and preferred whole-file. 258 aligned differences judged against the audio — the only ground truth in the investigation.
So blanket segmentation trades a frequent small quality loss for protection against a rare large one, and the rare one now has a direct fix in the model (#8). Bad trade.
What it actually found
gemini-3.5-flashsilently truncates long recordings — 6 runs in 10 on one 90-second clip, returning fluent text missing two thirds of what was said. Nothing noticed, becauseHallucinationGuard's rate ceiling is a maximum and 1.1 chars/second passes it from below.The near-miss suite is structurally blind to this. Its cases are short clips; truncation only happens on long audio. It reported 3.6 ahead by 4 points — inside its own noise — when the real margin was 0 truncations against 6 in 10. That blind spot is the most reusable lesson here and it now leads the document: ask what a suite cannot see before citing it.
What changed in the doc
wholepolicy and the aggressive live policy are removed as recommendations and kept only as recorded rejections.Documentation only.
🤖 Generated with Claude Code
https://claude.ai/code/session_015XKX6zEAGiZFE5wAxJgYbV