Opened 8 years ago

Closed 8 years ago

#3967 closed defect (invalid)

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

Reported by: svpv Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: lame
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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.

Attachments (1)

libavcodec-mp3-q.patch (538 bytes ) - added by svpv 8 years ago.

Download all attachments as: .zip

Change History (5)

by svpv, 8 years ago

Attachment: libavcodec-mp3-q.patch added

comment:1 by Carl Eugen Hoyos, 8 years ago

Keywords: lame added
Resolution: invalid
Status: newclosed

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.

comment:2 by svpv, 8 years ago

Resolution: invalid
Status: closedreopened

In FFmpeg MP3 Encoding Guide found at 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.

comment:3 by Carl Eugen Hoyos, 8 years ago

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!

comment:4 by Carl Eugen Hoyos, 8 years ago

Resolution: invalid
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.