Skip to content

fix: handle mid-stream sample rate/format changes in decode_audio - #1472

Open
g0rdonL wants to merge 1 commit into
SYSTRAN:masterfrom
g0rdonL:fix/audio-fifo-mixed-samplerate
Open

fix: handle mid-stream sample rate/format changes in decode_audio#1472
g0rdonL wants to merge 1 commit into
SYSTRAN:masterfrom
g0rdonL:fix/audio-fifo-mixed-samplerate

Conversation

@g0rdonL

@g0rdonL g0rdonL commented Jul 27, 2026

Copy link
Copy Markdown

Bug

decode_audio crashes on audio files whose stream changes sample rate or sample format partway through. _group_frames writes every decoded frame into a single AudioFifo, but AudioFifo locks onto the format/layout/rate of the first frame it receives and raises ValueError on any later frame that differs:

  File "faster_whisper/audio.py", line 96, in _group_frames
      fifo.write(frame)
    File "av/audio/fifo.pyx", line 81, in av.audio.fifo.AudioFifo.write
  ValueError: Frame does not match AudioFifo parameters.

AudioResampler has the same locking behavior and can hit the equivalent error in _resample_frames once frames from different source-parameter groups reach it (this surfaces after fixing the FIFO issue alone).

Fix

Catch the ValueError in both _group_frames and _resample_frames, flush what's already buffered, and start a fresh FIFO/resampler for the frame with the new parameters. The final AudioResampler step still normalizes everything to the requested output format/layout/rate, so decoded output is unaffected in the common (single sample-rate) case.

Verification

  • Reproduced the crash on macOS arm64 with the exact sample file (whisper-french-mixed-samplerate.mp3) attached to decode_audio crashes with "Frame does not match AudioFifo parameters" on files whose sample rate/format changes mid-stream #1451 — the file's stream switches 44100 Hz → 48000 Hz partway through (confirmed via ffprobe).
  • After the fix, decode_audio succeeds on that file (17.08s of mono 16kHz float32 audio).
  • Confirmed decode_audio output is byte-identical before/after this change on all 5 existing fixtures in tests/data/ (jfk.flac, multilingual.mp3, physicsworks.wav, stereo_diarization.wav, hotwords.mp3), including split_stereo=True — this fix is a no-op on the happy path.
  • Added tests/test_audio.py with a regression test using the reporter's sample file (added as tests/data/mixed_samplerate.mp3).
  • Full suite: pytest tests/ → 20 passed (19 existing + 1 new).
  • black, isort, flake8 all clean per CONTRIBUTING.md.

Fixes #1451


Drafted and verified with AI assistance (repro, fix, and test run locally); reviewed before submission.

_group_frames wrote every decoded frame into a single AudioFifo, but
AudioFifo locks onto the format/layout/rate of the first frame it
receives and raises ValueError on any later frame that differs. Files
whose audio stream changes sample rate or sample format partway
through (e.g. a spliced/transcoded recording) crashed decode_audio
with:

    ValueError: Frame does not match AudioFifo parameters.

AudioResampler has the same locking behavior and can hit the
equivalent error in _resample_frames once frames from different
source parameter groups reach it.

Catch the ValueError in both places and start a fresh
FIFO/resampler (flushing the previous one first) for the frame with
the new parameters. The downstream AudioResampler still normalizes
everything to the requested output format/layout/rate, so results
are unaffected for the common case; verified decode_audio output is
byte-identical before/after this change on all existing fixtures in
tests/data.

Fixes SYSTRAN#1451
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

decode_audio crashes with "Frame does not match AudioFifo parameters" on files whose sample rate/format changes mid-stream

1 participant