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: Will this ever make it into lame? (Read 9285 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Will this ever make it into lame?

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.

Will this ever make it into lame?

Reply #1 –
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.

Will this ever make it into lame?

Reply #2 –
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.

Will this ever make it into lame?

Reply #3 –
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.

Will this ever make it into lame?

Reply #4 –
Quote
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.

Will this ever make it into lame?

Reply #5 –
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.

Will this ever make it into lame?

Reply #6 –
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

Will this ever make it into lame?

Reply #7 –
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...)

Will this ever make it into lame?

Reply #8 –
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.

Will this ever make it into lame?

Reply #9 –
Tangent, are you serious?

Will this ever make it into lame?

Reply #10 –
Quote
VBR should be defaulted if nothing is specified.

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.

Will this ever make it into lame?

Reply #11 –
Quote
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.

Will this ever make it into lame?

Reply #12 –
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

Will this ever make it into lame?

Reply #13 –
Quote
Or maybe this is the job of a frontend!

that's it what the consensus was those days.

Will this ever make it into lame?

Reply #14 –
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.

Will this ever make it into lame?

Reply #15 –
Hi John,

Quote
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

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.


Quote
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.


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.


Quote
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.

Yes

Quote
6. Specify 'V n' in the command line where n is > 5, and it will behave as normal; ie., no preset usage.

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:

Quote
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.


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

Will this ever make it into lame?

Reply #16 –
Quote
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.

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!! 

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

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.

Quote
... 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.

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.

Will this ever make it into lame?

Reply #17 –
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:
Quote
V -n, V 0, V 1 = --ape
V 2/3 = --aps
V 4/5 = --preset medium
V 6/...= no preset  ?

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

Did any of this make sense? 

Will this ever make it into lame?

Reply #18 –
Quote
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.

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!! 
Quote
At last a possibly stupid question for john33:
Why not use the -quality setting used in vorbis and musepack instead of this:
Quote
V -n, V 0, V 1 = --ape
V 2/3 = --aps
V 4/5 = --preset medium
V 6/...= no preset  ?

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

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!
Quote
Did any of this make sense? 

Certainly did, thanks.

Will this ever make it into lame?

Reply #19 –
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!

Will this ever make it into lame?

Reply #20 –
@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?

Will this ever make it into lame?

Reply #21 –
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.

Will this ever make it into lame?

Reply #22 –
Quote
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?

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...

Will this ever make it into lame?

Reply #23 –
Quote
Quote
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?

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?

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.

Will this ever make it into lame?

Reply #24 –
Quote
Quote
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?

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 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.