Why converting MP3 from 192k to 64k causes samples to protrude

Question

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

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:

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):

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

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

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

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

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

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 2

Zoom level 3

7. Final test

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

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

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

This very section of original file looks like this:

The command

ffmpeg -i 5outputfile_192k_mono_dan065.mp3 7outputfile.wav

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

Conclusion

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.

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!).