VideoHelp Forum




+ Reply to Thread
Results 1 to 10 of 10
  1. As far as I know I can use two different mp3 codecs when re-encoding an audio track (of a video):

    mp3
    libmp3lame

    Are both built-in in ffmpeg or do (at least) one of them require a separate installation of a package?

    Which codec is recommended?

    Are both using the same syntax: In other words can I combine arbitrarily the target quality flags like

    .... -acodec mp3 -ab 128k ...
    .... -acodec libmp3lame -ab 128k ...
    .... -acodec mp3 -aq 5 ....
    .... -acodec libmp3lame -aq 5 ....

    When specifying -ab 128k the target bitrate is fix. But about the "-aq 5" flag. Is the output quality independent from input quality in this case or does "5" refer to the it?

    What if I don't want to specify a constant bitrate with -ab 128k but a variable bitrate VBR with a minimum bitrate of 128k and a maximum bitrate of 160k: How can I specify this?

    Thank you
    Peter
    Quote Quote  
  2. Are both built-in in ffmpeg or do (at least) one of them require a separate installation of a package?
    -acodec mp3 => uses the mp3 encoder of the libav library (which is part of ffmpeg even if it's build from source without additional libraries)
    -acodec libmp3lame => uses the mp3 encoder of the LAME library (libmp3lame is can be compiled into ffmpeg using '--enable-libmp3lame', assuming the library is present)

    Which codec is recommended?
    LAME

    can I combine arbitrarily the target quality flags like

    .... -acodec mp3 -ab 128k ...
    .... -acodec libmp3lame -ab 128k ...
    .... -acodec mp3 -aq 5 ....
    .... -acodec libmp3lame -aq 5 ....
    yes

    When specifying -ab 128k the target bitrate is fix.
    No, the average target bitrate is fix.

    But about the "-aq 5" flag. Is the output quality independent from input quality in this case or does "5" refer to the it?
    The output quality always depends on the input quality, no way around that.
    "-aq " specifies some kind of loss-levels, meaning it tells the encoder that it is allowed to make at most a specific level of error.
    The exact effect of aq depends on the audio encoder, for LAME see: http://ffmpeg.org/trac/ffmpeg/wiki/Encoding%20VBR%20%28Variable%20Bit%20Rate%29%20mp3%20audio

    What if I don't want to specify a constant bitrate with -ab 128k but a variable bitrate VBR with a minimum bitrate of 128k and a maximum bitrate of 160k: How can I specify this?
    ffmpeg itself does not allow that much control over the bitrate (-aq 5 with average 130kBit min 120kBit and max 150kBit is near to that)
    If you want/need more control you could decode your audio with ffmpeg, pipe it to the normal LAME cli encoder and later switch out the old with the new audio.

    Cu Selur
    Quote Quote  
  3. Member
    Join Date
    Nov 2009
    Location
    United States
    Search PM
    Actually there is no built in mp3 encoder in FFmpeg, it was removed years ago because it was crap quality.
    When you use "-acodec mp3" it will still use libmp3lame to encode.
    Quote Quote  
  4. So if I build ffmpeg without lame mp3 support it can't create mp3 files nowadays?
    Strange, I remember I had to specifically add a repository to ubuntu which added the lame binaries to be able to use libmp3lame in ffmpeg and the normal ffmpeg version that comes with ubuntu does support mp3 encoding,...
    Quote Quote  
  5. Member
    Join Date
    Nov 2009
    Location
    United States
    Search PM
    That's correct, you have to build with "--enable-libmp3lame" to encode to mp3.

    Then Ubuntu's FFmpeg must use libmp3lame also, because as I said FFmp3 was removed because of very poor quality.
    I can't recall exactly when it was removed, but it was several years ago.
    Quote Quote  
  6. Originally Posted by gregalan View Post
    Actually there is no built in mp3 encoder in FFmpeg, it was removed years ago because it was crap quality.
    When you use "-acodec mp3" it will still use libmp3lame to encode.
    So why isn't "-acodec mp3" removed from syntax?

    This would clarify and make it visible to every user that the presence of

    libmp3lame

    is required.
    Quote Quote  
  7. probably for compatibility reasons,....
    Quote Quote  
  8. Originally Posted by Selur View Post
    The output quality always depends on the input quality, no way around that
    I think this can't be true. If this would true then the output level must be specified somehow as a percentage of the source audio bitrate.

    Lets assume the source audio quality is 56k bitrate and I specify "libmp3lame -aq 5"
    Then the resulting audio quality will produce a target audio quality of 120...150 --->That is INDEPENDENT of the input audio.
    Or it will produce a output audio quality of e.g. 70% = 39.2k (=56k*0.7).

    Whats true now?

    Furthermore I wonder whats the difference is between the flags

    ffmpeg libmp3lame -aq 5

    and

    ffmpeg libmp3lame -qscale:a 5

    Is it the same?
    Quote Quote  
  9. ffmpeg libmp3lame -aq 5

    and

    ffmpeg libmp3lame -qscale:a 5

    Is it the same?
    yes, different calls for the same thing.

    -------------
    About the quality thing:
    Seems like we have totally different understandings what quality means.
    For me (and the way ffmpeg understands it), quality of a reencode is defined by the difference between the uncompressed source and the uncompressed/decoded reencode. So a higher quality means less difference.
    Which means:
    a. the quality of your reencode can not be higher than the quality of your input.
    b. quality is not necessarily bound to bit rate (just because a file has a bit rate of X it doesn't have to be better than a file of bit rate Y; with X < Y)

    The quality value you specify with aq specifies a min and a max compression/quantization level (<> min, max distance to source).

    Assume the following:
    You start with a smooth sinus curve signal you wan to compress.
    After the first recompression your reencoded signal is basically still the sinus curve, but it now contains some small additional bumps.
    If you now decode the reencoded material it will require more bit rate than the source you started with since the additional bumps also require bit rate. -> you created a new signal which has lower quality but requires more bit rate when uncompressed
    => Welcome to the world of lossy compression.

    The aq/vbr now simply specifies the maximal size these new bumps are allowed to have. (higher the quality <> smaller bumps/errors)

    Hope this helps a bit.

    Lets assume the source audio quality is 56k bitrate and I specify "libmp3lame -aq 5"
    Then the resulting audio quality will produce a target audio quality of 120...150 --->That is INDEPENDENT of the input audio.
    Or it will produce a output audio quality of e.g. 70% = 39.2k (=56k*0.7).

    Whats true now?
    aq 5 will probably result in an average bit rate that between 120-150 kBit/s, but that doesn't mean the quality of the output is independent of the quality of the input. I only means that the bit rate of the output can be independent of the bit rate of the source.

    Cu Selur
    Quote Quote  
  10. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    When thinking of quality, one must remember that every re-encode requires a full-decode first (not counting DCT-based transcoding shortcuts), and that decode doesn't ever get you back to 100% (otherwise, it would be a LOSSLESS encode instead of a LOSSY one).

    If you have a beautiful shot of an apple and you encode it with a lossy codec and the resulting (decoded image) looks like a rotten apple instead, then when you re-encode, you are encoding a new lossy version of the rotten-looking apple, not the pristine, beautiful apple. This will make the apple even more rotten looking. (I know that's not how it makes apples look with encoding, it's just for analogy's sake).

    Another example:
    1. Source = 100% quality
    2. Lossy encode is 85% of source
    3. Decoded version of lossy encode of source = 100% * 85% = 85%. This is now the new "source" quality. It won't get higher than this ever again.
    4. Lossy re-encode is 85% of source from #3
    5. Decoded version of 2nd lossy encode of source = 85% * 85% = 72.25%. If you re-encoded from this, it would now become the new "source" quality ceiling. But note that this says nothing about bitrate required/expected.

    Hopefully that is clearer.

    Scott
    Last edited by Cornucopia; 10th Nov 2014 at 13:56.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!