Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: A few questions about LAME options (Read 10223 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

A few questions about LAME options

I'm using LAME 3.98.4.

What exactly does the --cbr option accomplish?  If you use, for example, '-b 256', isn't that enough to force all frames to be encoded at 256 kbps?

Do I understand correctly that the quality level (-q) when using either CBR or ABR defaults to -q 5, but when using VBR it defaults to -q 2 (aka -h), so if using either CBR or ABR you need to explicitly stat the -q level if you want anything better than 5?  If that's so, I'm a little surprised that all encoding doesn't simply use -h by default.

Does using -q N with VBR encoding override the default quality level?  For instance, adding -q 1.

A few questions about LAME options

Reply #2 –
Quote
-cbr: http://lame.cvs.sourceforge.net/viewvc/lam...tailed.html#cbr


Ok.  Strange.  But I see what it does now.  Can't see why you'd ever use it, as I imagine there are more straightforward ways of accomplishing anything shown in those examples.

Quote
-q: http://lame.cvs.sourceforge.net/viewvc/lam...detailed.html#q


That further confuses the matter, as it conflicts with other documentation.  That says that the default is -q 3, while the lame --help text states that it's 5.

Quote
-q <arg>        <arg> = 0...9.  Default  -q 5
                    -q 0:  Highest quality, very slow
                    -q 9:  Poor quality, but fast


The HTML documentation installed states that -h (alias for -q 2) is always enabled when using VBR:

Quote
-h    high quality
Use some quality improvements. Encoding will be slower, but the result will be of higher quality.
This switch is always enabled when using VBR.


A few questions about LAME options

Reply #4 –
Here's one difference between --cbr and -b:

The usage of --cbr ENFORCES, meaning it 100% forces, at all times, the usage of CBR.

-b doesn't do that.

In the example given in SourceForge's documentation, let's say you have the following command lines:

lame.exe -V 0 -b 192

lame.exe -V 0 -b 192 --cbr


In the first command line, -b 192 doesn't cause CBR encoding at 192kbps, because of the -V 0 that appears before it.  Instead, LAME just encodes at VBR, using 192kbps as the lowest bitrate to encode each frame.

However, in the second command line, --cbr causes lame to "IGNORE" the -V 0 specification, and STRICTLY ENFORCE encoding at 192kbps CBR (specified by the -b 192 switch).  Use --cbr when you want to 100% make sure that you are encoding using CBR, no matter any of the other switches that may be used.


Furthermore, take the following example:

lame.exe --abr 200

lame.exe --abr 200 --cbr


The first command line causes LAME to encode at an average bitrate of 200 kbps.  It will more closely match 200kbps than, say, the -V2 setting.  Bitrates closer to the one specified will be used more frequently than with -V, even if they are silent frames (32kbps won't be used).

The second command line will cause LAME to abandon the usage of ABR, and instead use CBR at the pre-defined bitrate closest to the one specified in the --abr setting.  In this case, it would be 192kbps.  Thus, the second command line will cause LAME to encode at 192kbps CBR.


EDIT:  When I mean 'predefined bitrate', I'm talking about the bitrate buckets that LAME uses.  Those would be 32kbps, 40kbps, 48kbps, 56kbps, 64kbps, 80kbps, 96kbps, 112kbps, 128kbps, 160kbps, 192kbps, 224kbps, 256kbps, 320kbps.



If you specified

lame.exe --abr 280 --cbr

then LAME would actually use 256 kbps CBR to encode, since that is the CBR bitrate closest to the one specified in the --abr switch.

A few questions about LAME options

Reply #5 –
@ WonderSlug

I suppose the question is, "Why would you use switches like that in the first place?" Those examples remind me of the topics where people seem to randomly throw switches into the soup because they think that the longer the command is, the better the quality will be somehow. If you wanted to use ABR, you wouldn't add --cbr on the end, and if you wanted to use CBR, you wouldn't specify --abr in the first place. You wouldn't really need --cbr either, as

lame -b 128

would produce a CBR 128 kbps file, except for audio below ATH, which would use 32 kbps IIRC. If you wanted to disable that behaviour, you still wouldn't need --cbr, as you could use

lame -b 128 -F

to strictly enforce the minimum bitrate. It sounds like --cbr is more of a legacy command than anything else, unless I'm missing something...

Quote
That further confuses the matter, as it conflicts with other documentation. That says that the default is -q 3, while the lame --help text states that it's 5.

Remember that there are multiple encoding modes, CBR, ABR, old VBR and new VBR. --vbr-old uses the old -q system, but --vbr-new does not. The values for -q are completely different for --vbr-new and don't need editing. There are only two -q settings for --vbr-new, and the better of the two is enabled by default.

As lvqcl pointed out, the LAME documentation is stale.

A few questions about LAME options

Reply #6 –
Without following the forums or reading the source code, all anyone has to go on is documentation.  Shame that it isn't being maintained properly.

I wanted to do some listening tests, comparing a few CBR rates with different VBR levels and it struck me that if VBR is using -h and CPR -q 5, then I wouldn't necessarily be comparing apples to apples.  I suppose just using '-b nnn -q 2' would be closest.
 

A few questions about LAME options

Reply #7 –
Quote from: JJZolx on
I wanted to do some listening tests, comparing a few CBR rates with different VBR levels and it struck me that if VBR is using -h and CPR -q 5, then I wouldn't necessarily be comparing apples to apples.  I suppose just using '-b nnn -q 2' would be closest.


LAME uses -q 3 by default at least since 3.94beta (december 15 2003).

A few questions about LAME options

Reply #8 –
Quote from: lvqcl on
LAME uses -q 3 by default at least since 3.94beta (december 15 2003).


Right.  I've got that now.  Which means that parts of the documentation are almost seven years out of date.

A few questions about LAME options

Reply #10 –
Like I said, just for listening comparison.  I've never really done much critical listening to Mp3s encoded at different levels.  Would like to compare CBR 320 to some -V n levels and see what I find.

A few questions about LAME options

Reply #11 –
Well I would begin by using the recommended settings first and then esoteric switches once you've determined that you can tell a difference, to see if the results change.

For CBR use -b 320, for VBR use -Vx.

http://wiki.hydrogenaudio.org/index.php?title=LAME

A few questions about LAME options

Reply #12 –
Quality level doesn't strike me as an esoteric switch, but it only really stood out because the documentation is so poor that I thought that CBR was encoded a -q 5 by default and VBR at -q 2.  I'm thinking "Why automatically bump the -q level of VBR encoding to 2 while leaving CBR at 5?"

Also in the --help documentation there's this:

-h              Same as -q 2.  Recommended.

When you see "recommended" in the docs, it makes you take notice.

A few questions about LAME options

Reply #13 –
Unless you can demonstrate that additional settings beyond what I gave you result in an improvement, I think I am quite justified in relegating them to second-class status.  Perhaps I could have used a better word than esoteric, but to me the adjectives are simply not important.

A few questions about LAME options

Reply #14 –
Quote from: JJZolx on
The HTML documentation installed states that -h (alias for -q 2) is always enabled when using VBR:


That's partially true now. In 3.94, a new quality mode was added at -q 0 and all the modes moved up, so old -q 2 became -q 3, and so on. So I believe that VBR (old) uses -q 3. (vbr new, like said above, only has fast or high, and high is enabled by default).

Quote from: lvqcl on
BTW, http://lame.cvs.sourceforge.net/viewvc/lam...l/detailed.html is a bit incorrect too.


Please, tell me what is incorrect and needs to be fixed. I am the maintainer of the LAME documentation as of recently (i.e. I am the author of this new documentation)

Quote from: Aleron Ives on
It sounds like --cbr is more of a legacy command than anything else, unless I'm missing something...


Yes, it is. It is even older than the -Vx (uppercase) setting.

Quote from: JJZolx on
Without following the forums or reading the source code, all anyone has to go on is documentation.  Shame that it isn't being maintained properly.


As I've said above, I am the current responsible of maintaining the documentation. Tell me anything you see to be incorrect, and don't assume that lame --help and --longhelp is 100% correct.

Quote from: JJZolx on
-h              Same as -q 2.  Recommended.


-h setting didn't change, and is still -q 2 (which means the new q2, not the old q2). This implies also that is not the same as default. (except for vbr-new, where q4 to q0 mean the same. Mmm.. I guess these things should be added too to the detailed info....).

A few questions about LAME options

Reply #15 –
JAZ, nice to see that someone is picking up the documentation ball.  Would it be more appropriate to start another thread and solicit documentation corrections and changes?

First off, are you working only within the 3.99 alpha branch, or is there any possibility of a 3.98.5 release?

A few questions about LAME options

Reply #16 –
Yes, a new topic would be better.

I don't know what's the roadmap about the current development. I can only guess that if a .5 release is deemed appropiate, it will be released, but i doubt it would be done only to update the documentation.

A few questions about LAME options

Reply #18 –
Quote from: Aleron Ives on
@ WonderSlug

I suppose the question is, "Why would you use switches like that in the first place?" Those examples remind me of the topics where people seem to randomly throw switches into the soup because they think that the longer the command is, the better the quality will be somehow. If you wanted to use ABR, you wouldn't add --cbr on the end, and if you wanted to use CBR, you wouldn't specify --abr in the first place. You wouldn't really need --cbr either, as

lame -b 128

would produce a CBR 128 kbps file, except for audio below ATH, which would use 32 kbps IIRC. If you wanted to disable that behaviour, you still wouldn't need --cbr, as you could use

lame -b 128 -F

to strictly enforce the minimum bitrate. It sounds like --cbr is more of a legacy command than anything else, unless I'm missing something...


What if you are using a program that calls lame and gives it a bunch of switches (like EAC, dbPowerAmp, and Foobar)?  If one is unsure of the switch settings being passed in a given situation, they can always add something like "-b 192 --cbr" and know for sure that it will be encoding at 192kbps CBR regardless of any other switches passed to LAME. 

I do agree that --cbr does seem kind of moot in most cases, as one would actually test the command line switches and if they were predisposed to using CBR, would remove all switches and just use the -b option.  It looks like it remains just for the sake of compatibility with old command line configurations in encoding front-ends.

As greynol said, with the exception of 320kbps, why would anyone actually use CBR now anyway?

A few questions about LAME options

Reply #19 –
Quote from: WonderSlug on
What if you are using a program that calls lame and gives it a bunch of switches (like EAC, dbPowerAmp, and Foobar)?

I cannot speak for dBpa, but neither EAC nor foobar2000 pass Lame a bunch of switches.  EAC, if configured per our guide, passes absolutely no switches besides those that you specify.  I can also tell you what EAC passes if you have the Lame parameter passing scheme selected, but I see no reason to muddy the waters.