suboptimal mp3 encoding, non-identical to lame(1)

[svpv]

In libavcodec/libmp3lame.c, algorithmic quality is set to 5 by default.
However, lame(1) internally uses the default value of 3. Thus ffmpeg
prefers faster encodes while compromising the quality and/or producing
larger output. Specifically, in VBR mode, when compared to lame(1),
mp3 files written by ffmpeg take about 2% more space.

$ lame -V2 in.wav out1.mp3
...
$ ffmpeg -i in.wav -aq 2 out2.mp3
...
$ diff -U1 <(mp3packer -i out1.mp3) <(mp3packer -i out2.mp3)
...
- 700795 bytes in file (186.624755 kbps)
- 700378 bytes in MP3 frames (186.513707 kbps) = current bitrate
...
+ 715329 bytes in file (190.495223 kbps)
+ 714838 bytes in MP3 frames (190.364467 kbps) = current bitrate
...
  Bitrate distribution:
-  112: 1,0
-  128: 2,0
-  160: 270,0
-  192: 792,0
-  224: 82,0
+   96: 1,0
+  128: 3,0
+  160: 186,0
+  192: 818,0
+  224: 139,0
   256: 3,0
...

The fix is rather trivial. Although the default/recommended algorithmic
quality is not specified by libmp3lame API, it is simply used by default,
and need not be set explicitly.

[Carl Eugen Hoyos]

I don't know if this change of behaviour is desirable or not but please send your patch to the developer mailing list where it can be discussed.

[svpv]

In FFmpeg MP3 Encoding Guide found at ​https://trac.ffmpeg.org/wiki/Encode/MP3 it is stated that "the option -qscale:a is mapped to the -V option in the standalone lame command-line interface tool". In fact, the output is not identical in a way which compromises the quality.

[Carl Eugen Hoyos]

As said, please send your patch (or a patch fixing the documentation) to the developer mailing list.
Reopening this ticket will not help with the reviewing process (that happens on the mailing list) unfortunately!

[Carl Eugen Hoyos]

Sorry, I misread your message: The wiki is of course not part of the FFmpeg documentation - it is unmanaged, everybody may edit.