Skip to content

ffmpeg 5.1 silenceremove with stop_periods=-1 + stop_silence cuts speech, not just long pauses (Debian 12 apt ffmpeg)

TL;DR.

On ffmpeg 5.1 (Debian bookworm's apt package), silenceremove=...:stop_periods=-1:stop_duration=1.5:stop_threshold=-50dB:stop_silence=0.5 removes 50-1000 ms chunks inside speech even when the clip has no 1.5 s pause, so playback sounds sped up in spots. ffmpeg 9.0.1 with the identical filter removes nothing. Check the ffmpeg version in your container, not on your laptop.

Symptom

A voice app plays a rendition with long pauses trimmed: silenceremove=start_periods=1:start_threshold=-50dB:stop_periods=-1:stop_duration=1.5:stop_threshold=-50dB:stop_silence=0.5, which should shorten only pauses of 1.5 s or more, down to 0.5 s. Users said the playback sounded 'sped up in spots', and the staff 'leveled' (un-denoised) rendition did it too. The browser originals (WebM/Opus from Chrome, Safari, and Firefox) were clean.

Cause (measured)

The production image is python:*-bookworm with apt-get install ffmpeg, which gives ffmpeg 5.1.x. In 5.1, silenceremove with stop_periods=-1 plus stop_silence drops short pieces (30 ms to about 1 s) around brief dips under the threshold, in the middle of phrases. Measured on 75 real 5-45 s clips: ffmpeg 5.1 removed a median of about 1.1 s per 14 s clip beyond the legitimate pause cuts, and up to 60% of one 45 s clip. The removed regions had RMS around -17 to -35 dBFS with peaks near 0 dBFS, so they were speech, not silence. Cross-correlating 0.5 s windows of the output against the original showed the offset climbing in small steps through the speech. Sometimes the output length matches the input even though content is gone, so comparing durations undercounts the loss. ffmpeg 9.0.1 with the identical filter string removed nothing on clips with no real 1.5 s pause. The filter was reworked in the 2023-05 series (af_silenceremove: switch to activate and follow-ups, released in 6.1), and there is an earlier 2022-08 fix, 'do not trim non-silence from start'. I did not bisect which commit fixes this. Without stop_silence (the STT trim), 5.1 and 9.0 agreed on most clips.

How to check yours

Run the filter inside the production image and in a recent ffmpeg on the same clip. Then compare the output durations, or slide 0.5 s windows of the output over the original by FFT cross-correlation and look for offsets that keep growing.

Fix options

Use an ffmpeg of 6.1 or later in the image (a static build or a newer distro base), or drop silenceremove and cut pauses yourself from silencedetect intervals with atrim/aselect plus concat. Then regenerate the stored renditions.

No signals yet