It doesn't matter which software is used to convert, FFMPEG or CoolEdit 2000, it makes always the same effect.

The original file is WEBM. When I convert it to WAV PCM or MP3 192k using one of following commands

ffmpeg.exe -i "%1" -acodec libmp3lame -ar 44100 -ac 1 -ab 192k -af "dynaudnorm=f=50:p=0.65" "%1.dan.mp3"

the waveform is then even

Normal waveform

If I convert either the original WEBM or WAV PCM or MP3 192k to MP3 64k,

ffmpeg.exe -i "%1" -acodec libmp3lame -ar 44100 -ac 1 -ab 64k -af "dynaudnorm=f=50:p=0.65" "%1.dan.mp3"

waveform becomes this:

Protruding waveform

It doesn't even matter whether the dynaudnorm effect is used or it is a simple conversion - the effect is always the same.

Entire file contains a voice stream. The protruding regions contain voice with distortion effect.


Update - the whole story

The original file is a WEBM file inputfile.webm and cannot be opened in my audio editor, so all screenshots are here after conversion.

Duration of the whole audio file is 01:52:08

My audio editor can't handle variable bitrate, so I use constant bitrate.

1. Simple conversions

The result of the following two conversions

ffmpeg -i inputfile.webm outputfile.wav
ffmpeg -i inputfile.webm -acodec libmp3lame -ab 192k outputfile_192k_stereo.mp3

looks identical (here is stereo and not 2 files next to each other):

Original stereo

Here, the larger amplitude areas contain undistorted main audio that will be processed normally in the future. The image on the right contains a zoom of such an area.

Lower amplitude areas are from a mixed-in audio source and are already distorted. They do not become distorted during my FFMPEG processing! These are areas that will protrude after FFMPEG processing.

2. Dynamic audio normalization

The target is a 192 kbit/s MP3 file, dynamically normalized to level 0.9. The number of audio channels remains unchanged (2).

ffmpeg -i inputfile.webm -acodec libmp3lame -ab 192k -af "dynaudnorm=f=50:p=0.9" 2outputfile_192k_stereo_dan090.mp3

Stereo, dynaudnorm 0.9

Everything looks fine, but ... I need a monophonic file!

3. Simple conversion to mono

ffmpeg -i inputfile.webm -acodec libmp3lame -ab 192k -ac 1 outputfile_192k_mono.mp3

Stereo to mono

Oh no! What ist this?! The waveform becomes clipped.

4. Dynamic audio normalization to mono

192 kbit/s, level 0.9

ffmpeg -i inputfile.webm -acodec libmp3lame -ab 192k -ac 1  -af "dynaudnorm=f=50:p=0.9" 4outputfile_192k_mono_dan090.mp3

Stereo to mono dynaudnorm 0.9

It gets even worse. Now even more oscillations are cut. So FFMPEG promises to normalize to level 0.9 but it doesn't. (Note: if we convert a monophonic file to a monophonic file or stereophonic to stereophonic, it does its job fine. This only happens when stereo is downsampled to mono).

5. So, we'll try to change normalization level to 0.65

ffmpeg -i inputfile.webm -acodec libmp3lame -ab 192k -ac 1  -af "dynaudnorm=f=50:p=0.65" 5outputfile_192k_mono_dan065.mp3

Stereo to mono dynaudnorm 0.65

Perfect! Is there anything left to be desired? Actually yes. The file with 192 kbit/s rate takes 154 MB of disk space.

6. I'll try to get it down to 51MB using a 64kbps rate - the lowest bitrate at which I haven't noticed a significant drop in quality yet.

ffmpeg -i inputfile.webm -acodec libmp3lame -ab 64k -ac 1  -af "dynaudnorm=f=50:p=0.65" 6outputfile_64k_mono_dan065.mp3

Stereo to mono 64k dynaudnorm 0.65

Now the non-distorted areas with main audio still look fine, but distorted areas get protruded.

Although when I zoom the protruded areas in, it is not so bad as I thought (it just not obey the normalization level parameter):

Zoom level 1

Zoom level 1

Zoom level 2

Zoom level 2

Zoom level 3

Zoom level 3

7. Final test

Now I'll take the already normalized MP3 192 kbit/s mono file from step 5:

Original MP3 mono

and just convert it to a 64 kbit/s file without changing anything else:

ffmpeg -i 5outputfile_192k_mono_dan065.mp3 -acodec libmp3lame -ab 64k 7outputfile_192k-to-64k.mp3

192k mono to 64k mono

Now everything looks as in step 6, including zoomed views.

192k mono to 64k mono, zoomed

This very section of original file looks like this:

Original, zoomed

The command

ffmpeg -i 5outputfile_192k_mono_dan065.mp3 7outputfile.wav

produces a WAV output that looks just like the input file.


  1. Either FFMPEG is buggy and doesn't do what it promises,
  2. or I do not understand the FFMPEG parameters right,
  3. or the produced MP3 is fine and my audio editor cannot cope with all MP3 capabilities.
  • You mention that the 'dynaudnorm' filter doesn't have an effect but you use it on the two examples shown. It's unclear what you're asking.
    – audionuma
    Sep 30, 2022 at 18:16
  • Could you show us what a ffmpeg -i inputfile.mp3 outputfile.wavproduces ?
    – audionuma
    Oct 1, 2022 at 8:49
  • 1
    It would be good if we could view a section of samples from before and after in the protruding region. Zoomed in to the same duration, so we can see individual samples. I have a feeling I know what is happening.
    – n00dles
    Oct 1, 2022 at 18:23
  • 1
    I updated the question
    – Paul
    Oct 3, 2022 at 17:25
  • 1
    @n00dles: It seems really to be a screen representation problem and only for 64 k bitrate
    – Paul
    Dec 19, 2022 at 23:36

1 Answer 1


I'm going to take a shot here, I think your problems are all due to summing two identical (or very similar) audio signals to mono, thus increasing the amplitude by 3 - 6 dB (which then protrude/clip as you say).
I realised the relative amplitude between the high and low parts of different examples (without dynamics processing) is seemingly correct, i.e. the entire waveform seems to have increased in amplitude equally, not just the "protruding" sections.

There's an easy way to test this theory, well, there are a few, but we'll stick with the easiest for you - convert the original file to 64k but as a stereo file. If it's at a good level, then summing to mono is the cause of the problem.

To resolve this, if it is indeed the issue, all you need to do is lower the amplitude of the stereo file before compression (by maybe using a high quality intermediate format) or even better, if the WebM file is dual mono (two identical channels) use the left channel only as a mono file. I'm not sure how or if that can be done in FFmpeg. Remember also, that you ideally only want to compress to a lossy format once, at the end.

Note: I say I'm taking a shot because I'm not 100% sure it's a mono-summing issue, as the final test is a bit confusing, but that could just be to do with downsampling heavily clipped regions. I think the logic is sound; downsampling lowers the highest reproducible frequency, so some information from the square-like clipped waveform is inevitably lost, causing a reversion to a more sine-like wave. I've noticed this type of effect before, but I haven't actually studied it. It's just me putting two and two together (and hopefully making four!).

  • FYI; As for dunaudnorm (what an awkward name!) the Dynamic Audio Normalizer filter, I've had a quick read (just skimmed it really) and it seems to me it only increases gain by a certain evaluated amount for each given section. If you wanted to lower the peak value of the sections, you would need to use the "traditional compressor" switch, as they call it, s. This is just my interpretation from skimming the info, though.
    – n00dles
    Oct 4, 2022 at 18:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.