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: LAME defaults (Read 7854 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME defaults

I've pretty much made the switch from ogg to LAME mp3 for all my lossy needs. In the end, universal hardware support 'brought me to my senses' 

I recently became aware that LAME's default setting is CBR 128. If you just run the following command:

Code: [Select]
lame myaudio.wav


the resulting file is CBR 128.

Also, if you read through the LAME command line reference, it states that V4 is the default for VBR (I have no idea if this document is updated - there is no revision date).

If you read through the HA wiki, there are recommendations based on consensus and ABX testing.

Do LAME's developers still target optimizations toward their internal 'default' targets? Does anyone prefer CBR 128 these days?

LAME defaults

Reply #1 –
if you type "lame --help", lame will recommend -V2:
Code: [Select]
RECOMMENDED:
    lame -V2 input.wav output.mp3

OPTIONS:
    -b bitrate      set the bitrate, default 128 kbps
.
.
.


Maybe the current default is some kind of legacy support... to get maximum compatibility or something like that; as there still are devices that do not support VBR.

LAME defaults

Reply #2 –
The documentation is not updated. It has received corrections where the data was wrong, but not much.

In that regard, i redone it and made it available for evaluation in this thread:
http://www.hydrogenaudio.org/forums/index....showtopic=65756

The developers have agreed to include it in a newer version, but they first want to spend some time revising and changing what needs to be changed.


About your question, the defaults do not get a special (as in more than anything else) attention.
Lately (last versions) it got improvements on the VBR model in general, tweakings of killer cases, and other improvements that should affect most if not all the modes.

LAME defaults

Reply #3 –
Raiden, that's really interesting. I never noticed it. It's not surprising given the language for the presets. V2 is called 'standard', which suggests a default in a way, don't you think?

Thanks, JAZ. That's exactly the kind of info I was looking for. I'll give it a read.

In reading through LAME's early history, I see that Mike was targeting 128 CBR mostly because of the hardware/software available at that time in history. Would it be too radical to suggest that the default be changed?

Assuming that the goals for a default setting are hardware independence combined with a great quality/size ratio (these are obviously my assumptions - I wouldn't try to speak for the developers), what would be the optimal default? There is something to be said for a 'set it and forget it' default that most users are happy with.

Of course, in a perfect world, your user base would be educated about the software settings and perform their own ABX tests, but for mainstream users?

LAME defaults

Reply #5 –
Quote from: dyneq on
Assuming that the goals for a default setting are hardware independence combined with a great quality/size ratio (these are obviously my assumptions - I wouldn't try to speak for the developers), what would be the optimal default? There is something to be said for a 'set it and forget it' default that most users are happy with.
Any MP3 player with full MP3 standards compliancy will play LAME VBR encodings flawlessly, so why hasn't -V3 become the new default? It seems to offer the best quality to size ratio thanks to the enforced -Y switch and seems to be considered by at least some of us around these parts to now match -V2 in earlier versions of LAME in terms of perceived transparency.

I realise that not all MP3 players are fully MP3 standards compliant, but why dismiss the use of VBR encoding as a default setting on the basis that a tiny minority of players are broken?

Just my 2 Shekels.

Cheers, Slipstreem. 

LAME defaults

Reply #6 –
A suggestion: how about if the main goal for a standard setting is to achieve transparency for 68.27% of the ABX population (1 standard deviation)? In HA's last listening test, LAME did very well at almost V6 (except for finalfantasy). If that value ends up not being a whole number (i.e. V4.5), round it up quality-wise to keep it simple.

The question would then be: are there enough results and a broad enough set of styles of music represented in the tests?

The other challenge is that when LAME improves, we would need to hold more tests to figure out the new transparency level since there would be some disk space savings. For now, the wiki still seems to be the best guide to quality settings for new users.

LAME defaults

Reply #7 –
I don't think you should change the default behaviour.

People who are using lame without any switches are either very well informed (they know exactly what this will do, and it's exactly what they want), or haven't got a clue. In either case, you risk breaking something by making a change.

e.g. if you're making podcasts, you don't suddenly want your 128kbps podcasts to go out at ~220kbps V2 - or even VBR at all (probably).

There's also the issue with less informed users that if most other encoders default to 128kbps CBR, and lame defaults to something else, they might think it's less efficient, or not working.

Maybe the first link in the documentation, and on the official website, should be to...

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

...because at the moment, Googling Lame isn't going to give you that information immediately.

Cheers,
David.

LAME defaults

Reply #8 –
I'd keep the defaults as they are. Most people use LAME with a ripper or a frontend anyway so changing the defaults wouldn't make a difference.

LAME defaults

Reply #9 –
Why have a default setting at all then? Why not have it require a parameter to function?

To me, a default setting usually represents some kind of 'best practice' or algorithmic optimization target.

LAME defaults

Reply #10 –
Thinking about it, the problems seem to lie with badly written front-ends more than anything. Let's face it, the vast majority of LAME users are never going to either see or use the command-line anyway. Here are a few of my thoughts concerning LAME 'in the wild'. No offence intended to anyone, but I feel the need to speak my mind.

I was recently asked to analyse some LAME MP3 encodings generated with MythMusic. As the user was an MP3 novice, it was quicker for him to just upload a few samples for me. The options given for lossy encoding when LAME was the selected encoder are just "High", "Medium", and "Low", with VBR available but disabled by default.

With VBR off...

"High" = CBR256,
"Medium" = CBR192
"Low" = CBR128.

With VBR on...

"High"" = -V0,
"Medium" = -V2
"Low" = CBR128.

All encodings were in Joint Stereo, thankfully.

But how is a person who doesn't understand MP3 encoders and doesn't know what an ABX test is supposed to have any idea what's going on or what's recommended by 'those in the know'. The data above came from my own tests with Foobar2000 and EncSpot, but I decided to take the approach of "Mr Average" by Googling for an answer, and my Google-Fu is usually strong, but it took me over half an hour to find out what the "High", "Medium" and "Low" settings names actually meant. Even if I had gone to look at the LAME WIKI either first or after, it wouldn't have helped as the 'lingo' used is totally different in both places.

CDex seems to be a major culprit too as it offers the possibility to play with nearly all of the more common mentioned switches, including the ones that most of us advise people to never touch even with their worst enemy's bargepole. The madness of this approach in CDex drove me to write a tutorial on another forum for setting up CDex to give default VBR behaviour for CD conversions. My only two personal gripe with CDex are the fact that I had to effectively write a user's manual for the damn thing, and the knowledge that it has a "Come in and break me!" mentality about it that still drives me nuts!

I'm not the only person to have been spurred into writing a guide, and the number of people who do and then come up with some bizarre "mine is better" recommendation for the settings is quite frightening. At least I stuck strictly by the HA recommendations when writing the guide. The ones who don't are damaging LAME's reputation and outweigh me by at least a factor of 10.

If people were chased more about the wording they use in their GUIs and forced to just offer switches that are healthy for any given mode with a clear and meaningful label beside it, everybody's lives would become so much easier. Surely it's just as easy (if not easier) to write a GUI with a choice of CBR, ABR and VBR, then a slider that jumps in the appropriate steps to just show all valid CBR, ABR or VBR 'bitrates'. Everything else gets left at default so you know the encoder is running optimally as tuned.

I've said it before and I'll say it again. The current 'free-for-all' when it comes to switches can undo a lot of the good work that's been carried out on LAME development in the eyes of casual but fussy users. I think that the allowance of any potentially damaging switches 'into the wild' needs to be very carefully considered as it puts power in the hands of those who, with all due respect, have the least idea of what they should do with it. Why give hand grenades to monkeys? You already know what's going to happen!

This is how the rumours spread amongst the non-ABXers and audiophiles. For example, I've lost track of the number of arguments I've had with people who claim that Joint Stereo isn't proper stereo, and that's just one aspect of the problem. Please lock LAME down to stop this continued abuse.

It makes me wonder how many LAME encoders are actually running default recommended settings and nothing else? Is this problem truly epidemic and 'breaking' the majority of encodings? How does it make a software developer feel if his/her finely tuned work is effectively being abused on a wide scale? I'd love to know the answers to those questions. It certainly jars me off pretty badly!

 

Cheers, Slipstreem. 

LAME defaults

Reply #11 –
Most of the people reading these threads don't mind the current state, because they have educated themselves. I am out of touch with 'mainstream' LAME users, so I can't comment on how the latest front ends are implementing the parameters.

I guess I'm not as opposed to the status quo as Slipstreem, I just wanted to open it up to discussion and see if anybody else thought that the current default met the needs of mainstream users or...?

LAME defaults

Reply #12 –
Does anyone know where can I find FhG commands?
 

LAME defaults

Reply #13 –
I was looking for info re: why LAME defaults to CBR, and ran across this statement by 2Bdecided:

Quote from: 2Bdecided on
if you're making podcasts, you don't suddenly want your 128kbps podcasts to go out at ~220kbps V2 - or even VBR at all (probably).

The fear that podcasts have to be CBR is unfounded, AFAIK.

A podcast is just a static audio file (or a set of them), usually with some kind of program content (radio show, DJ mix, lecture series, not a single song), optionally distributed with the aid of an RSS feed announcing the availability of the files (so the client can subscribe to the feed and download the files automatically). The audio file format can be anything supported by the receiver.

I'm not sure any of the arguments presented for LAME continuing to default to CBR, despite overwhelming recommendations to people to choose VBR, are that compelling. Nero AAC defaults to VBR. But I guess that's not compelling, either