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
+ Reply to Thread
Results 1 to 10 of 10
-
-
Are both built-in in ffmpeg or do (at least) one of them require a separate installation of a package?
-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?
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?
"-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?
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 -
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,... -
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. -
-
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? -
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?
Cu Selur -
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.
ScottLast edited by Cornucopia; 10th Nov 2014 at 13:56.
Similar Threads
-
FFmpeg Runtime error / FFmpeg git-df82454 32-bit Static (2012-10-03)
By MashedPotatoes in forum Newbie / General discussionsReplies: 5Last Post: 6th Oct 2012, 17:22 -
ffmpeg - cannot encode with '-acodec copy' option
By hassoo in forum Video ConversionReplies: 8Last Post: 30th May 2012, 07:32 -
FFmpeg on Win only - FAQ can ffmpeg realize screen capture
By feelart in forum Capturing and VCRReplies: 1Last Post: 14th Feb 2012, 04:11 -
-acodec copy to 6 channel audio results in 2 channel?
By ninethirty in forum Video ConversionReplies: 1Last Post: 11th Feb 2011, 11:54 -
FFmpeg -acodec copy
By sldvd in forum AudioReplies: 2Last Post: 8th Sep 2010, 13:25