Opened 5 years ago

Closed 5 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

Description

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 5 years ago.

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by svpv

comment:1 Changed 5 years ago by cehoyos

  • Keywords lame added
  • Resolution set to invalid
  • Status changed from new to closed

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 Changed 5 years ago by svpv

  • Resolution invalid deleted
  • Status changed from closed to reopened

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.

comment:3 Changed 5 years ago by cehoyos

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 Changed 5 years ago by cehoyos

  • Resolution set to invalid
  • Status changed from reopened to closed

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.