LAME presets

Topic: LAME presets (Read 24760 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #75 – 2001-11-08 22:45:38

Quote

Originally posted by Gabriel
You could start with the current frontend and heavily change it. (just one thing please: find a name for this one, not just lame.exe)

I know it .. call it BLAME (as in Better LAME or Beginners LAME)

Quote

Originally posted by Dibrom

I think that part of the problem with now removing options and having it cause compatibility issues though is due to having such a loose project (organizationally), slow releases, and way way too many options in the first place. I guess there isn't much that can be done at this point though..

This is partly a problem but also the beauty of LAME. Most "arbitrary" settings in LAME can be tuned from the outside. I seriously wonder if you would have become interested in tuning LAME if it didn't had all these switches?

The downside is clear: it takes knowledge, testing and good hearing to use all that for the better.

The real development and experimental switches should maybe be hidden in a "stable" or even an "beta" version. It would not be so hard to make a compile time setting like
-D DEVELOPMENT_VERSION to be set in the Alpha versions and removed in the finals (just a lot of #ifdefs in the frontend must be added)

I, for one, think at this point that I would prefer a version with optimal defaults (as you propose and have provided with the dm's) but with the possibility to overrule them if I want to. Some decisions when defining a preset are arbitrary, it may depend on the sample, the listener and the listening environment.

I could for example do with lower lowpass values most of the time. For some music (at let's say 128kbs) you might need --ns-bass -8 , for other music -4 is ok.

Just a thought,

Ge Someone.

LAME presets

Reply #76 – 2001-11-09 00:38:13

Quote

Originally posted by GeSomeone

This is partly a problem but also the beauty of LAME. Most "arbitrary" settings in LAME can be tuned from the outside. I seriously wonder if you would have become interested in tuning LAME if it didn't had all these switches?

I wonder about this sometimes also.. maybe, maybe not. But I do know that at this point the downsides to this approach probably are starting to outweigh the advantages. Especially given that many things are now known to be beneficial yet they are not defaulted, and the options which can seriously affect quality (and are known to do so) are still available.

Quote

The real development and experimental switches should maybe be hidden in a "stable" or even an "beta" version. It would not be so hard to make a compile time setting like
-D DEVELOPMENT_VERSION to be set in the Alpha versions and removed in the finals (just a lot of #ifdefs in the frontend must be added)

Yep, this is exactly what I was thinking. Most of these experimental options, if not removed entirely, should only be enabled if defined at compile time.

Quote

I, for one, think at this point that I would prefer a version with optimal defaults (as you propose and have provided with the dm's) but with the possibility to overrule them if I want to. Some decisions when defining a preset are arbitrary, it may depend on the sample, the listener and the listening environment.

Everything which is related to internal behavior should be defaulted and not modifiable at the command line. Stuff like -X, --nspsytune, -Y, -Z, --ns-bass/alto/treble, --ath-adjust, --athtype, etc... all that kind of stuff should be removed. It should just be automatic. The only real things that should be allowed at the command line are things like simple switches which favor speed vs quality vs size, highpasses and lowpasses, minimum and maximum bitrates. Only stuff which directly affects functionality.

Quote

I could for example do with lower lowpass values most of the time. For some music (at let's say 128kbs) you might need --ns-bass -8 , for other music -4 is ok.

In my opinion, the lowpass part is fine.. the ns-bass stuff should be automatic though. Having to use different fixed values to modify masking in different situations implies large flaws in the psymodel. Instead of promoting the use of switches like these, the psymodel itself should be fixed to just make the correct decisions in the first place.

I think one of the issues with LAME right now is that there are a lot of what appear to be "hacks" to various issues. This is kind of emphasized by the fact that many of these types of things are not defaulted or automatic. In fact, --r3mix and the --dm-presets themselves are really just hacks. If LAME worked properly in the first place in regards to quality, these switches wouldn't be needed at all. I'm seriously hoping that at some point things start to converge a bit more and all of these types of issues are cleaned up and consolidated. I'd like to even see --r3mix and --dm-preset removed entirely and just have the defaults work well enough on their own that external presets like that aren't necessary.

LAME presets

Reply #77 – 2001-11-10 02:32:26

Hi guys,

I just don't understand why the main developers of LAME wouldn't see the culminating point of simplifying LAME. Let me explain how I see the LAME community of users:

The current community of LAME users are intelligent and find a way to work out a decent commandline. There are another set of users who use any simple mp3 encoder they can get their hands on. This forms up the mp3 user-base. The simple-users don't like LAME because it's too complicated. They want a "set and forget" encoder, but they aren't opposed to high quality mp3s.

Coming up, the LAME version number is approaching 4.0. This is a perfect time to start working on a simplified frontend for independent freeware programmers to make rippers for. The version number would call attention to itself especially being labeled as "stable". The user base is not stupid, the news of a new LAME would spread like wildfire. 9 out of 10 users would abandon the older LAME versions for 4.0 stable. Simple mp3 users would be very likely to adopt the simplified LAME once freeware rippers and proggies come rolling out for it.

LAME is a well known project that will be accepted if the main body of developers stand together and hammer out a winner for the upcoming 4.0 version. I don't think anyone doubts this.

There is plenty of time between 3.90 and 4.0 to start making a stable and simple LAME encoder for all to use.

If the developers want to keep the old frontend alive for the purpose of testing experimental settings, then they can simply create a "experimentalLAME.exe" for the advanced users and developers. Then when the developers find a winning improvement, they can add it to the regular LAME and upgrade the version number but keep the "stable" tag on each upgraded version. Each setting can be upgraded with a new command line when one is proven to be a winner in testing, but the regular users of LAME won't really know it. They will still be using the same old compatible settings made starting in "4.0".

I guess my point is that there are two different camps in regards to LAME. There are users who make mp3's with it and there are "testers/developers" who use complex commandlines in LAME to improve quality. I feel there is a need to fork LAME, but not for the worse, but for the better. Both versions of LAME are geared toward the same goal, but with a different method. One LAME frontend for experimental work (the current frontend), and one frontend simplified for the common user of LAME (the new improved frontend that many people are asking for).

Gentlemen, this is a perfect world we are dealing with. You can have the best of both ideas, you just have to be willing to see the value in both and compromise. Perhaps the LAME .dll can utilize the simplified quality presets for freeware proggies and the .exe can be for the experiment? Or it can be two different implementations of LAME with the same goal. Independent, but one is supported by the other for the purpose of improvement, the other for utilizing a simple/high quality frontend.

You guys are all extremely intelligent and reasonable people. There is an answer in compromise and that starts by finding common ground you agree on and then following a logical thought process until you all get your answer together. Forking LAME isn't necessarily a bad thing, if it's done with all parties in agreement and knowing the purpose for the split. That purpose should be universal like the project itself and not split in bitter disagreement.

It doesn't even have to be a true split. One type of LAME is for experiments and the other for actual usage. Both are in reality linked to the same damn project!!! So quit fighting and start listening to each other. I think Dibrom isn't the problem here. Dibrom has listened to the user-base and is trying to take the list of user-level demands to the developers. It's the developers who haven't been listening. I applaud Dibrom's efforts in this matter. I would ask that the developers seriously consider a user-friendly LAME as the priority at this point. I'm telling the developers this because if they don't make a user-friendly LAME before v4.0, then someone else will!

mp3

LAME presets

Reply #78 – 2001-11-10 03:52:50

I agree with mp3fan. I mean look at the Vorbis devs. They have acknowledged the need also for a simple encoder, and that's why there exists OggDrop which has tweaked "presets".

LAME presets

Reply #79 – 2001-11-10 06:57:09

Yes, something similar to Audio Active would be nice. A simple GUI with only a few settings, utilizing the .DLL. Then programmers of rippers could use this pre-tuned .DLL and simplify LAME configuration in rippers.

Encoding options something like:
-VBR 1-5 (indicating quality levels, referring to presets)
-ABR xxx (bitrate, other options pre-tuned)
-CBR xxx - " -
-Joint Stereo On-Safe-Off

That's it?

Notice