Hello, I know of at least one switch which is not documented in LAME help but has an effect on the output ("--psymodel"). Is there a full list of all switches available somewhere?

Second question is, wouldn't it be a good idea to remove the switches which have no effect, from the LAME help? Such as -X n, -Y, -Z (and similar, I'm not sure about all of these but I know that at least one does not work).

EDIT: I'd also advise to remove the non-working switches from help of final Lame versions, which cause them to crash (ATH related etc.)

Yes. parse.c
By the way, this switch should be enabled only for alpha and debug versions of LAME 3.97 and it is absent in LAME 3.98


-Y switch works as usual.

Actually I believe the functioning of the -Y switch is the reverse of what it originally was.

Wouldn't it be much easier for everybody to just remove all of the switches that we keep having to repeatedly tell new users not to use? If every current preset setting is already fully optimised, then what's the point in keeping these additional switches anyway?

Cheers, Slipstreem.

Slipstreem, but nobody can force you to use these switches. Where is the problem?

I'm not saying that anyone can force a person to use them. I'm saying that almost every first post from new members relating to LAME on this forum consists of "What happens if I mess around with these switches?", and ends in us being frequently ignored or told that we're wrong when we tell people to leave them alone.

If they're genuinely of no benefit to encoding quality, or fileaize without costing quality for typical encodings, then why give Joe Public access to them when they already have a fully optimised encoder to play with using standard presets and command-line switches?

Maybe two releases could be generated. One for the public with all unnecessary switches disabled, and another (not linked to for the general public) for experimentation and development work. I just can't see the logic behind us, the presets, and the WIKI telling people what to do, and the encoder offering them options to screw it up. Where's the logic in that?

I think it's true to say that the vast majority of LAME users have absolutely no idea what it does or how and also have no idea of the damage they can do to their encodings by using switches they don't understand. Take the options away and we don't get hassled and told that we're stupid every five minutes by strangers who know a lot less than we do.

Cheers, Slipstreem.

Although not a hidden switch but I for one would like to see the "--noreplaygain" to become default.
I have no use for it and I doubt anyone has but it sure does slow down the encoding a bit.

And I agree with Slipstreem.

Post cleaned due to being a duplicate

If advance settings are hidden, I hope it could be unlockable on the configure script switch for advance users. The switches on LAME are not bad since alot of users hardly use them, its the iTunes MP3 encoder that needs some options hidden such as Stereo mode and the sample rate. I have seen alot of podcasts encoded on iTunes at 128kbps on pure stereo at 48Khz .

the default (switch-less) settings are good for most users. for those who want to tweak settings, they have to use switches, and that's how it's usually done (and i see no problem with that)

Is there anybody who can tell me how is it in reality?

I mean... I'm using -Y all the time. With current Lame 3.98 my command line is -V2 -Y.

@ pdq: What you mean by "reverse" ?

My recollection (and I may be wrong) is that in its early implementation the -Y switch prevented bit bloat due to sfb21. Then later that became standard in -V3 to -V9, and optional for -V0 to -V2. Specifying -Y then toggled the default, making it the opposite of whatever was normal for that -V setting.

My understanding is that -V2 -Y is equivalent to -V3, and that -V3 -Y is equivalent to -V2.

why do you use it if you don't know the effect of it?

How you come to this conclusion?

I know what it does! I was just confused by pdq's post and wanted to know "the whole story"...
Read this thread: Lame 3.97 -Y switch especially the end of it...

Originally it was doing something completely different. For the last several years it has the same meaning, disabling the extra handling of sfb21/12 in VBR mode.

Another option, aside from disabling these switches, is to improve the documentation that comes with LAME. Take a look at LAME 3.98 bundle from Rarewares. I don't see the documentation recommending the -V settings. Also it does not warn about worse quality if other switches are used.

This issue of undocumented and experimental switches is a pretty old one and has been debated here many times in the past. I haven't paid much attention to LAME in the past couple of years, but it sounds like not much has changed regarding the user interface if these switches are still accessible.

My opinion is pretty much the same as before. I think undocumented and experimental switches should only be accessible if explicitly enabled during configuration and that the resulting binary should signify that it is a debug/test build.

The entire idea behind all of the preset work was to try and minimize the mess that existed at the time where everyone was using a different set of switches, many of which they barely understood. In some regards, the effort was successful, but the more ambitious goal of radically simplifying the LAME user interface for the better was never very popular with certain people.

Some of the argument against removing this stuff had to do with backwards compatibility, which never really made a whole lot of sense to me. The other half of the argument had more to do with the whole "freedom to tinker" mentality I think. This mentality is very common in open source projects. There's almost always a tradeoff between usability and polish of the UI of a product and how configurable it is. Open source projects almost always come down on the side of configurability, even when it's not necessarily sensible.

I think this tension has more significant implications for the success and usability of open source projects in general, but I won't really go into that here. Suffice to say, this was somewhat of a point of contention for me when I was still involved in anything related to LAME. At any rate, there is (or was) enough disagreement that it's not surprising to see that the LAME UI is the way that it is, and I wouldn't expect it to change drastically in favor of simplification in the future. There's still plenty to be happy about with how much LAME usability has improved since the r3mix days even if it's not perfect.

On the other hand, switchs.html still describes '-d' option (it was disabled at least since LAME 3.93.1: so for 4.5 years or more switchs.html describes nonfunctional switch). And it describes '--priority' as "OS/2 process priority control" Well, OS/2 was very interesting system... but 10 years ago.

Added: oops, these switches were removed by robert from switchs.html: -d, -k, --cwlimit, all --ath* and even some more And (accidentally?) definition for -c switch. Well, I never liked copyright. Looks like there never was definition for -c in the file.

Hmm, its interesting how much replies did the thread receive in 2 days

Because some people know what the switches do and use them, and for example optimise the presets for certain genre or bandwidth/bitrate configuration.
E.g. I listen to electronic music and I want my files to not go much over 128kbps but still have full 16k bandwidth (impossible with the current -V presets). I don't care about some additional noise or distortion here or there, what I care about is bad artifacts like ringing or dropouts. So I optimise the presets to eliminate the few obvious artifacts, introducing a lot of new ones but less noticable ones. And I think this is the purpose of the all the switches anyway, for this reason I use Alpha Lame versions because they can afford more configurability


One note: Its funny that switches for adjusting masking in certain sf bands (--ns-bass etc.) work in the final releases but ATH related settings are disabled. If one was to fine-tune the presets, I think he would rather make use of the ATH settings instead of masking settings.

-J.M.

Here - http://www.pazera-software.com/products/lame-front-end/ - you can download modified version of LAME 3.98 with all developer switches enabled... So if somebody wants to use "--cbr -b320 -m d -q0 --noreplaygain --athshort --athtype 1 --athaa-type 0" what can you do?

Not the point. The point isn't making it impossible for an mp3 encoder, to do this stuff. The point is that the developers of the lame project are complicit in the abuse. As slipstream said: If certain stuff almost always makes no sense, and is only interesting for testing purposes, then why put it in a release build? If there is a tool which explicitely makes something senseless possible, then there are two parties which cause the resulting issues: The developers SUPPORTED it AND the users which used it. This isn't really something which from a logical POV can be argued about - its a fact, unless you want to break causality.

Now, if a certain tool is often abused for pointless things.... and the people here get constant support overload because of it..... yet even after years, the tool still officially supports it in production versions (releases), then it is only fair to say: We did our part in educating users.... and even the developers usually tend to propose to just use basic settings.... so why are they still creating an app, which actively supports abuse?

I'm not talking about features which are actually efficient in a significant amount of cases, like -Y ..... i am talking about stuff, which creates inferior results, insignificant improvements or unpredictable results, in 9999 cases out of 10000. And no, that "One in ten-thousand" is NO reasonable argument for keeping it in.... if you were to support all the possible "One in ten-thousand" cases, the app would need hundreds of exotic options. If you really depend on such exotic cases, modify the source yourself and compile it - or ask someone else to do a personal custom build.

...but to make less possible for inexperienced user to shoot his/her leg? Ok, I get it.

Here's the full relevant argument, for people who cannot read past the first sentence of a post:

The fractional V setting works great.

Try -V5.8 .. -V5.2

LAME 3.98 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used)
Using polyphase lowpass filter, transition band: 15826 Hz - 16360 Hz
Encoding 16493_visual_Effecto_Q1.wav to 16493_visual_Effecto_Q1.wav.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=5.8)

http://www.hydrogenaudio.org/forums/index....showtopic=65755