Here's a weird one. I'm using Pedalboard to apply a small effects chain (denoise, declick, deplosive) to files recorded in the browser. Since Chrome records to webm natively, my backend converts these to 16-bit PCM wavs using FFMPEG. No problem. Until today when a user shared some files they received back that were full of dropouts (gaps, not cut outs) and corrupted audio. After I checked and it worked fine, they continue seeing it with every recording they upload.

I found their uploaded webm and the locally-converted wav files on the server and both sound just fine. No errors in the log files.

I found if I convert the webm file to WAV in Audition, then upload that file, the problem persists. but if I replace the audio data inside that WAV file, it's fine. It seems perhaps how the audio samples are encoded in the original recording persists through conversion to PCM16LE and affects how Pedalboard processes DSP.

I ran ffprobe on the original .webm file, but I can't see anything that looks out of the ordinary. Any ideas what sample data might be affecting the DSP?

ffprobe -v error -show_format -show_streams ./tmp9u8ejtec.webm [STREAM] index=0 codec_name=opus codec_long_name=Opus (Opus Interactive Audio Codec) profile=unknown codec_type=audio codec_tag_string=[0][0][0][0] codec_tag=0x0000 sample_fmt=fltp sample_rate=48000 channels=1 channel_layout=mono bits_per_sample=0 initial_padding=0 id=N/A r_frame_rate=0/0 avg_frame_rate=0/0 time_base=1/1000 start_pts=0 start_time=0.000000 duration_ts=N/A duration=N/A bit_rate=N/A max_bit_rate=N/A bits_per_raw_sample=N/A nb_frames=N/A nb_read_frames=N/A nb_read_packets=N/A extradata_size=19 TAG:language=eng [/STREAM] [FORMAT] filename=./tmp9u8ejtec.webm nb_streams=1 nb_programs=0 nb_stream_groups=0 format_name=matroska,webm format_long_name=Matroska / WebM start_time=0.000000 duration=N/A size=228446 bit_rate=N/A probe_score=100 TAG:encoder=Chrome [/FORMAT]