Skip to content

Long-form transcription deterministically drops ~7 s of clear speech at a chunk boundary (95 s repro WAV linked) #758

Description

@maboa

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

  1. Download and transcribe chunk-seam-drop-1235s.wav (95 s, 16 kHz mono, conference Q&A audio, English).
  2. 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.

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:

  1. Fully deterministic: repeated runs produce word- and timestamp-identical output, so these are reproducible merge decisions, not sampling noise.
  2. 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.
  3. dualDecodeArbitration: true was a no-op on this file beyond its processing overhead — output byte-identical to plain melChunkContext: false.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions