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 9310 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Will this ever make it into lame?

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

Will this ever make it into lame?

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

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

Will this ever make it into lame?

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

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

Will this ever make it into lame?

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

Will this ever make it into lame?

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

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.

Will this ever make it into lame?

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

Will this ever make it into lame?

Reply #31 –
Quote
Easily done for Windows, can't speak for the other platforms though.

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.

Will this ever make it into lame?

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

Will this ever make it into lame?

Reply #33 –
Quote
Quote
Easily done for Windows, can't speak for the other platforms though.

Using something like Python + wxPython should make it fairly 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.

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

Will this ever make it into lame?

Reply #34 –
I was actually planning on doing some front-end work in Python this summer...
dev0
"To understand me, you'll have to swallow a world." Or maybe your words.

Will this ever make it into lame?

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


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