I was looking for something else, and it took me by here

http://www.audiofora.com/yabbse/index.php?...id=3009;start=0
(see my post)


http://www.audiofora.com/yabbse/index.php?...did=75;start=75
(see my post)



Some of what I've written is nonesense, but the idea that a user should be able to type...

lame -cbr 128

and get the best 128kbps CBR encoding possible, or

lame -abr 200

and get the best ~200kbps ABR encoding possible, or

lame -vbr standard

and get the excellent VBR encoding as standard...


these still seem like good ideas to me!



I note that we currently have

--alt-preset standard
for VBR,

--alt-preset <number>
for ABR, and

--alt-preset CBR <number>
for CBR.


So, we're nearly there, and more recent (though not yet recomended compiles) are moving even closer.


I don't follow the alphas, so (at the risk of making an idiot of myself if it's there already!), can I remind people of this idea, in the hope that it might happen - please?

Cheers,
David.

P.S. The idea is nearly 20 months old.

hmm. can't see many advantages. is your naming scheme much clearer? I'd just stick with the current existing ones.

--preset <name> which is vbr, that is superior to abr and cbr, so use it.
--preset <number> which is abr and you just have to specify your disired target bitrate
--preset cbr <number> use cbr settings just for compatibility reasons, again choose your bitrate which is now constant.

sounds like logic to me. and the vbr naming scheme is similar to other codecs like mpc.

I think it's clearer your way. LAME documentation makes it clear that there are 3 modes to select, so you should always have to specify. Aliases to the current --alt-presets would be cool, anyhow.

VBR should be defaulted if nothing is specified.

One of the advantages would be that magazines or websites publishing MP3 encoders comparisons would get a better idea of Lame when they use it with the default settings (lame -b192 input.wav output.mp3).
We should also consider what happens if a user uses "-b192 -ms". For example a warning saying "Warning : using -ms decreases the encoding quality".

Now, the --presets are used for everyday encoding, and the standard encoding, well, not even for testing purposes.
So it's the bare encoding that should get a line of its own : lame --nopreset input output.

I wish they'd do this.

Most people don't want to wade through a page or two of command line options to figure out how to use the codec. They just want to encode and be done.

I agree with 2BDecided.

A while ago I posted this:

http://www.hydrogenaudio.org/forums/index....6038&hl=presets

That's specific to RazorLame, but obviously it would be much better if it was actually implemented in the Lame exe.

Just to highlight some points I made there, I still find it ridiculous that a newbie can just select options which infinately degrade the sound without it being their fault - if options are set as default (like pure stereo) then why should people think they're doing anything wrong? Also, if -q 0 is still experimental, then why is there no warning when using it? It's just as bad as using a beta version of the exe to encode with.

A lot of people get fed up when people post here and ask things like "which is better, joint stereo or forced stereo?" But you can hardly blame them, can you?

Pio is right, the presets should be default. Then at least when poeple decide to encode using their homemade crazy long command lines, or insist on forcing "pure" stereo, it's 100% their own doing.

I agree with 2Bdecided also, and would add this: keeping in mind
that I'm not sure whats involved in "compiling" a Lame build, and even
less so, in constructing a .DLL, if someone could complile the best
version of Lame, (3.90.3 I assume), and construct it into a .DLL
with only the --alt-preset standard operability, then call it
something like lame_standard.dll we'ld have the best of both
worlds.

You'ld select the internal encoder for your everyday ripping/encoding
projects, and still have the option to select Lame.exe when you wanted
to "experiment" with something else.

If I knew how to compile and construct, I'ld do it myself.

Dex

One of the LAME devs (Gabriel, I think) posted some time ago that a major change to the command line interface like this one won't happen before LAME 4.0, as it would break backward compatibility with applications that support LAME.EXE. However, because LAME 4 is to be regarded as a totally new encoder, the interface will definitely be changed in that version, he said if I remember correctly. (I'm too lazy to search for the particular post where this was said, but you get the idea...)

Yes, I suggested the same thing a couple of times here before too, but sort of lost hope that it would ever happen without forking LAME. My point of view seems to be that most of the lame crew are enamoured by their own GSPYCHO and would not allow an independently developed NSPSYTUNE to be defaulted and will forever brand it as experimental even though it has been proven that NSPSYTUNE is superior. Remember this was one of the main factors causing Dibrom to leave lame developement.

Tangent, are you serious?

Indeed. I remember from way back in the R3Mix/Audiofora forums I stated that if someone drags a wav onto Lame.exe that it should use --alt-preset standard, not the "Internet standard" at 128 kbps CBR.

After all, --alt-preset standard is what we've all been saying is the standard encoding quality to use, therefore it should be made the standard switch to use if no preset is specified. First time user's of Lame would have a good lasting first impression and known how good Lame really is.

I'd love to see the day when all one would have to do is use a command like:
lame input.wav output.mp3
and the results would end up being an --alt-preset standard encoded mp3, of course the presets would stilll need to be in the .exe for those who prefer other switches.

2Bdecided:
I can see the point that you're making which would simplify Lame switches. I must say however that if that were the direction to go it may cause a mass confusion since many people never read or print the manual.

If you mean all the VBR stuff, I'm not convinced by my own idea anymore! It has its merrits, but they're not overwhelming.

But the dead simple:

lame -cbr 128
lame -abr 128
lame -vbr standard

seems like a no brainer to me. (I can't believe I've just used that expression!)

The --nopreset or --testmode or --options or --letmemesswiththepresetseventhoughIwillpropbablymakethemsoundworse to give the user access to other options seems like a nice idea too - so the user actually has to select or type something before wrecking the presets!

Or, maybe (here's a radical suggestion) stable releases don't have switches that can reduce quality. Just take them out. Only allow "experimental" switch in alpha and beta releases.

Or maybe this is the job of a frontend!

Cheers,
David.

This is exactly the job of a frontend. Our current frontend (lame.exe) is quite messy, but we should keep compatibility.

It means that already existing switches must be preserved in the 3.x timeline. What is planned for 3.94 is:

*--preset/--alt-preset for presets (already done)
*new experimental options only in alpha or debug mode (already done)
*default config using presets (not yet done)


--cbr xxx/--abr xxx/--vbr xxx scheme seems a good idea, and should be possible


edit: Current options should be kept in 3.x, but nothing prevents anyone to do an "easy" frontend to replace lame.exe

that's it what the consensus was those days.

Having taken a 'watching brief' on this thread, I offer you a new compile of 3.90.3 for testing and criticism, constructive I hope!! You can download from here: http://homepage.ntlworld.com/jfe1205/test3.90.3.zip

What's in it? I hear you ask. The following:

1. Specify a command line of 'lame input.wav', and it will use --aps and generate input.wav.mp3.
2. Specify a command line of 'lame input.wav output.mp3', and it will use --aps and give you the expected output.
3. Specify 'V n' in the command line where n is < 2, and it will use --ape.
4. Specify 'V n' in the command line where n is > 1 and < 4, and it will use --aps.
5. Specify 'V n' in the command line where n is > 3 and < 6, and it will use --preset medium.
6. Specify 'V n' in the command line where n is > 5, and it will behave as normal; ie., no preset usage.
7. Specify '--abr n' in the command line and it will map to the --preset abr settings.
8. Specify '-b n' in the command line as a CBR setting; ie., not as a min VBR bitrate; and it will map to the --preset cbr settings.

All other settings remain unchanged in interpretation. In other words, the only settings that don't map to the new presets are VBR settings 6 - 9.

Feedback would be much appreciated and please note that the various help options have NOT yet been amended to reflect these changes. I'd like to know whether the above meets with general approval before I go to the trouble of changing the help notes and other docs.

Hi John,


I wonder if many folks do really have a need for a file a file called input.wav.mp3
Wouldn´t it be easier to use :

1. Specify a command line of 'lame input.wav', and it will use --aps and generate output.mp3 instead.
2. Specify a command line of 'lame input.wav output.wav.mp3', and it will use --aps and give you the expected output.

instead.




So,... does that mean:
V -n, V 0, V 1 = --ape
V 2/3 = --aps
V 4/5 = --preset medium
V 6/...= no preset ?

... seems a bit complicated to me (... but maybe I just don´t understand the reason behind this ) , why don´t just simplify all presets:

3. Specify "--extreme", and it will use --ape
4. For --aps see point 1 (no further arguments).
5. Specify "--medium", and it will use --preset medium.



Yes


6. Specify something else and it will behave as normal; ie., no preset usage


That´s how I see it to be the most simple, but I also see the point as already stated by Andavary:



... but if the old switches are not disabled, everything will still be OK even for the "manual-non-readers".

I don't disagree with you, I was just trying to preserve as much as possible in terms of what people are used to getting, but also make it more difficult to create crap!!


Yes it means exactly that. The idea was that if people use the existing VBR quality settings, they get a good preset at the higher bitrate end. There isn't currently really anything to which to map the lower quality settings.


I can certainly add those as further aliases to the current presets, if that's what people want.

The objective, following the trend of this thread , was to change as little as possible, but make it easy to good encodes and relatively difficult to get bad ones.

My humble comments:

I like the idea of making things easier for a non-technical user.
As it has been said already, most people deal with some kind of a frontend. If the modifications to the command line is aimed at the normal user, I think it will miss. I think the target will be the I'm-so-clever-but-have-no-clue-what-I'm-doing people, that has their own "unbeatable" command line that is half a mile long.
What I'm trying to say is that if reducing the use of CBR 128 or CBR in general is the goal, you need to get the attention from the people that makes the defaults for all the programs, that people actually use for making mp3's.

Another interesting thought, is whether people will accept the increase in filesize or not, when using aps. If they don't hear a diffence, because CBR 128 is transparent to them, they may look elsewhere. The part that may profit from this in the end is Microsoft's wma that offers this great "cd quality" at 64/96 kbps and considerably smaller filesizes.

At last a possibly stupid question for john33:
Why not use the -quality setting used in vorbis and musepack instead of this:

I guess there is a good reason that I'm not aware of.

Did any of this make sense?

I appreciate what you're saying. All that I've attempted to do here is to reflect the comments/wishes that have been entered here. If I've missed the mark, or people have decided that this is not worth doing for whatever reason, I have no problem, I'm merely trying to move things along in some way!!

Well the only good reason really was that I was trying to bend the command line options that people are already familiar with. If I were starting with a clean slate, I would certainly consider using a 'quality setting' as the best way of handling VBR, although to be fair, the '-V' settings are meant to be exactly that!

Certainly did, thanks.

John33 - Your build is just what I have been waiting for!!! The way that you have remapped the presets is excellent B) . My only piece of advice is this - disable all the other switches currently available in LAME!! People use command lines such as "-b192 -ms" all the time. By disabling all switches such as --lowpass, -ms, -mm, -k, and so forth, it makes it impossible for new users to get themselves into trouble . Now, I know that people will scream that this would ruin LAME's versatility, and to a point it does make LAME less powerful for specialized applications. People who NEED to make simple stereo files (why? I have no idea ) and change the presets lowpass values / other settings can use the traditional build. On the other hand, disabling all the switches except YOUR specified ones above along with the --alt-preset and the --preset switches would give users high quality files ALL the time, no matter how much they try to "tweak" their command lines! Just a suggestion…. Thanks again for all you hard work!

@ViPER1313:

Thanks for the feedback. All things are possible and disabling most of the other switches would certainly make sense for a 'standard' build. These same switches could be re-enabled in an 'advanced' build that included appropriate warnings about messing with switches whose real purpose you know nothing about!

What I've done so far, was with the aim of changing the 'look and feel' as little as necessary so that users would be largely unaware that anything had changed other than, maybe, that their encoded files suddenly sounded rather sweeter!!

In fact, and this is really addressed to Gabriel, I can see no reason why the CBR and ABR settings shouldn't be mapped into the preset versions now, even if none of the other stuff is adopted.

Anyone else any views on any of this?

IMHO, disabling ALL the other options is severely flawed an option.

First off, I'd agree with Gabriel's post. Compatibility SHOULD be preserved rather than going all out just for quality. If ever there should be a need to break compatibility, it should have been done in a major version change, not in the existing 3.9x branch. As it stands right now, HA's Lame (3.90.3) has changed quite a lot from the official Lame builds... and one thing IMHO that users should/must know is that 3.90.3 is forked from the main branch.

The other most serious objection I have against removing all the other switches is that you remove choice from the end-user. Removing / remapping existing switches equates to the developer making the choice for the user. It takes away the right of the user to decide exactly what he/she wants to do, and most importantly, doesn't solve the problem at all.

Is it better to simply impose and dictate what you view as the right choice on the end-user, or is it better to educate them to understand why certain options should / should not be made?

I really think links/messages in the help files explaining the choice of the --presets would be the ideal solution, and not simply FORCING the user into only certain choices.

Yeah, in this case its better to impose. Ogg or musepack could expose tons of advanced switches that could seriously degrade quality a la Lame, but they don't, and no one complains that they don't have choice. The devs have done the tweaking for us with these codecs (as has Dibrom with Lame), so why not just take advantage of their time and effort?

Of course there can still be dev versions of Lame with options enabled - for those serious about creating alternative command lines and for general testing. But the average person just doesn't need this functionality, and 9 times out of 10 will encode there stuff with a sub-optimal preset/switches.

As for education, thats what Hydrogen Audio is here for, but unfortunately its likely that the majority of those using Lame won't stumble upon this great forum...

I agree... it isn't really an imposition when many/most of the advanced options tend to degrade quality with common sorts of usage. Looking at it another way, having those options tends to 'impose' poor quality encodes and funky "look at me" command lines. It's hardly like removing -k or -x turns Lame into something like "clippy" in MS-Word.

Edit -- it would even be cool to see a minimal front-end included in v4.0 (since a lot of people use one), altho I don't know if this is possible given the development methodologies already in place, and the fact of running on a number of different OS's/GUIs.

I disagree that its better to impose. To me, the option of having a choice is above all essential, even if it means that quality has to be sacrificed.

Last I checked, MPC exposed plenty of option switches. Ogg doesn't however, but you can forcefully limit the min/max bitrate, which should be slightly akin to tweaking. But the difference is that for the two, encoding with the --quality (or something like that) options were by design, rather than in Lame, where the presets were pretty much a recent development in the history of the encoder itself.

If you were to tell me that Lame 4 would have presets mapped to most options, or that HA were to distribute a LAME version which was clearly seperately labelled as being modified , that would be fine with me. I'm not sure if I'm at all qualified to make a comment, but to change the options while leaving the user unaware ( as John33 suggested ) isn't very nice. At the very least, the user should be informed... ( hope I didn't insult anyone with those 2 lines, if I did, apologies )...

Above all, I believe that choice and transparency is essential.

An interesting philosophical argument here!

The mistake, if you can really call it that, was to expose the user to all these wonderful, and mostly experimental, switches in the first place. Outside the core developers, there are very few people who really understand what all the various switches do and how they interact. Whilst in an ideal world, education regarding how to get the best out of LAME is the best option, it is really too late for that, IMHO.

Surely the whole purpose of Dibrom's extended tuning exercise that resulted in 3.90.2 in the first place was to create an almost complete range of settings that would enable users without the in-depth knowledge of LAME to create the highest quality mp3s at any given desired bitrate. I don't think that anyone here would suggest that this wasn't achieved. Given this scenario, isn't it absurd to allow the inexperienced user the opportunity to create poor quality mp3s when the mechanism is already available to prevent that?

I believe the standard build that is offered should force people into creating the best quality mp3s. Ill informed people currently accept poor quality mp3s because they don't know there is better to be had. By all means offer a fully enabled version for those who wish to have the freedom to create command lines they don't understand and generate sub-standard mp3s ( ), or, more properly, to allow those with the knowledge the opportunity for further tweaking and tuning.

Anyway, just my thoughts; they don't carry any more weight than anyone elses.

The standard build in my opinion is the way to go for the fact being there is always a new person each day getting into mp3 compressed audio and more than likely will start using improper encoding methods that don't produce even medium quality mp3's.

I think that there should be some sort of 'ReadMe1st' document that comes with the compile that clearly states the purpose of the standard build:
* Archival quality.
* No room to use stupid settings.
* Staight forward and easy to use (simplification at its best).

What did you think of my idea of a minimal front end for v4.0? Just something that has a graphic interface with "add" and "encode" buttons, allows adding a bunch of .wav files in a batch and outputting MP3's -- much less "fancy" than something like Razorlame, and just uses the defaults (which by then could be the --a-p s).

Just an idea, I'm not a Lame developer & don't really know the issues...

As an extra, not a bad idea. The only real problem would, I think, be that most people are already using their own frontend of choice. However, for someone new to LAME, it may just work. Easily done for Windows, can't speak for the other platforms though.

That's what I was thinking. I've recommended Lame to "newbies" before (and those using other jukebox type proggies), and it really complicates things to explain going through the steps in finding, downloading & setting up a front end, etc (and even explaining exactly what a front end is ). I like the idea of some way to just dump the archive to a folder and start graphically encoding right away, by double-clicking some file.

Wish I was better versed in C/C++ (I forgot it all) or I'd see about getting approval to do something myself.

A front-end is a good idea, but frankly everyone should be using EAC if at all possible anyway, so it would be preferable to maybe bundle a very simple help file w/ info on getting LAME working great with EAC in as few steps as possible. Or maybe distribute an EAC config file /w LAME binaries.

Using something like Python + wxPython should make it fairly easy to build whilst still being cross-platform compatible I think. The only problem is that the majority of windows users don't have a python interpreter installed, but py2exe easily fixes that

IMO it'd be nice to have a nice standard GUI frontend that remains identical in behavior across different OS's.

While I somewhat agree that EAC should be used as the frontend for encoding the one or two CD's that one periodically does, for me it really isn't that practical for batch encoding say five to ten cd's unattended overnight while sleeping.

I like the ideal of a graphical frontend - rather it be for newbie's or even those of us that have been using Lame for awhile.

This is going on a bit of hope:
If possible a frontend developer could make the frontend into a reality, perhaps even something from Speek, or just ask him if All2Lame could be packaged in the Zip archive. Also it would be nice if Case's Tag could be in the mix somewhere for writting tag's into the files.

So I'll just pop off and learn Python, then!!

I was actually planning on doing some front-end work in Python this summer...
dev0

The current problem with LAME is that people DON'T read the manual, or take the time to understand what switches they are using, or even understand what options are available to them. Most new users are going to use a front-end, and never, ever type --longhelp at the command prompt. If a new user decides to use RazorLame, how is he or she supposed to know about the --presets? Many new users also use programs such as CDEX, EAC, and Audiograbber, which give the user the impression that settings equal to the equivalent of -b128 are the best solution (with the exception of the newest versions of CDEX and possibly latest EAC pre-beta...) If the users options are limited, than there is no room to mess up. A warning that the users attempted settings are being over-ridden is fine, as long as it explains that it is done to ensure the highest quality. Forcing the user to pick certain settings is not necessarily a bad idea, and as John33 and others have said, programs such as Ogg Vorbis and MPC have been doing this for a long time. Another fringe benefit of disabling the other settings is that it will increase the quality of older programs that do not allow the user to choose the --presets. The user will not even have to think about it. Even thought the user might think that his or her -b128 -ms -q0 setting is the way to go, he will get --alt-preset cbr 128 without thinking about it, and be happy that he or she got it as a result . Just my thoughts.....