Summary
AsrManager.transcribe on the long-form path (ChunkProcessor, 15 s chunks / 13 s stride) deterministically loses multi-second spans of clearly audible speech at chunk boundaries. On the linked 95-second clip, ~7 s of speech is dropped entirely — reproducibly, byte-identical output across runs.
Environment
- FluidAudio 0.15.4 (exact-version pin),
parakeet-tdt-0.6b-v3 via AsrModels.downloadAndLoad(version: .v3)
AsrManager with ASRConfig.default, called from a macOS app (Apple Silicon, macOS 26)
- Input: 16 kHz mono PCM WAV, so no resampling/decode variability
Repro
- Download and transcribe
chunk-seam-drop-1235s.wav (95 s, 16 kHz mono, conference Q&A audio, English).
- Observe the output around t = 71.6–78.8 s.
Expected (what's audibly in the clip, and what the model itself produces for this span when the audio is windowed differently):
…expectations from different communities? Yes, I I can s uh give you some examples that will be uh uh uh more in depth with the next talk too…
Actual: the last word before the gap is "communities?" (ends ~71.6 s); the next emitted word is "more" at 78.8 s. Everything between — the entire start of the answer — is missing. Note the gap terminates at 78.0 s = 6 × 13 s, i.e. exactly on the chunk-stride grid.
The clip is cut from a ~30-min recording that exhibits 2–3 such drops plus occasional boundary garbles ("language in" → "languag ines"). Things we verified while investigating:
- Fully deterministic: repeated runs produce word- and timestamp-identical output, so these are reproducible merge decisions, not sampling noise.
melChunkContext relocates the failures rather than fixing them: with melChunkContext: false the full file's three drops are all fixed — and a different ~7 s span drops at a different boundary instead, plus a new artifact class of duplicate token pairs emitted ~80 ms apart ("Okay Okay", "check check"). Neither mode dominates.
dualDecodeArbitration: true was a no-op on this file beyond its processing overhead — output byte-identical to plain melChunkContext: false.
- Failures depend on decoder state, not just seam-local audio: cutting this clip on the 13 s grid (so all chunk boundaries fall on the same audio positions as the full file) made the full file's drops disappear and a new one appear at a different seam. Drops always land at low-SNR moments (applause, crosstalk, soft speech) adjacent to a boundary.
Offer
We'd be glad to submit a PR if you can advise which direction you'd accept:
- a fix in the chunk merge itself (if you can point at the suspected mechanism), or
- a detection + re-decode pass: flag inter-word gaps > ~2 s near a chunk boundary that contain speech-level energy, re-decode a single 15 s window centred on the gap (so the seam doesn't exist in the re-decode), and splice at silence-verified points. On our 30-min test file this would repair every observed drop at ~2% extra compute.
Happy to provide the full-file A/B/C transcripts or further clips.
Summary
AsrManager.transcribeon the long-form path (ChunkProcessor, 15 s chunks / 13 s stride) deterministically loses multi-second spans of clearly audible speech at chunk boundaries. On the linked 95-second clip, ~7 s of speech is dropped entirely — reproducibly, byte-identical output across runs.Environment
parakeet-tdt-0.6b-v3viaAsrModels.downloadAndLoad(version: .v3)AsrManagerwithASRConfig.default, called from a macOS app (Apple Silicon, macOS 26)Repro
chunk-seam-drop-1235s.wav(95 s, 16 kHz mono, conference Q&A audio, English).Expected (what's audibly in the clip, and what the model itself produces for this span when the audio is windowed differently):
Actual: the last word before the gap is "communities?" (ends ~71.6 s); the next emitted word is "more" at 78.8 s. Everything between — the entire start of the answer — is missing. Note the gap terminates at 78.0 s = 6 × 13 s, i.e. exactly on the chunk-stride grid.
What we've established (fuller data in https://github.com/hyperaudio/glider/issues/83)
The clip is cut from a ~30-min recording that exhibits 2–3 such drops plus occasional boundary garbles ("language in" → "languag ines"). Things we verified while investigating:
melChunkContextrelocates the failures rather than fixing them: withmelChunkContext: falsethe full file's three drops are all fixed — and a different ~7 s span drops at a different boundary instead, plus a new artifact class of duplicate token pairs emitted ~80 ms apart ("Okay Okay", "check check"). Neither mode dominates.dualDecodeArbitration: truewas a no-op on this file beyond its processing overhead — output byte-identical to plainmelChunkContext: false.Offer
We'd be glad to submit a PR if you can advise which direction you'd accept:
Happy to provide the full-file A/B/C transcripts or further clips.