I think we should get some order to the LAME presets and format them in the MPC-style, getting rid of the --dm-preset and --r3mix.
-insane (dm insane or xtreme?)
-xtreme (dm standard)
-standard (--r3mix or similar bitrate producing MTRH variant - I think speed is also required for the standard. Bitrates should be competitive with 192kbps CBR)
-radio and/or -divx (abr 128kbps stuff?)
-thumb? (something small)
All these personalized presets are just confusing for the newbies I think.
Well I strongly agree that the current preset situation is not optimal at all, and is need of a restructuring. I'm not exactly sure what would be best though. I don't think I would mind what you proposed above (except for the issue below), but I think it may be hard to get other certain people to agree, expecially given the order you proposed. It would imply that certain presets are better quality than others, but a few people still seem to disagree with/deny this, even with all the evidence pointing to this.
Also.. in a situation like this, and given the fact that all of this AQ stuff is likely to make it into LAME, I think it is important to keep the "standard" mode still within the AQ category. As you see in this thread:
http://www.hydrogenaudio.org/forums/showth...st&threadid=108 (http://www.hydrogenaudio.org/forums/showthread.php?goto=newpost&threadid=108)
(last page especially)
--r3mix is NOT AQ since it can be shown with 95% certainty that the reference sample (MPC) is perceptually better.
So I'm not sure the solution would be quite as simple as what you proposed..
I don't think -standard needs to be such a high bitrate or quality as --dm-preset standard.
Is MPC -standard transparent? Or Psytel AAC -standard?
After standard is supposed to be "in the middle of the pack" solution. Also, I would definitely make the standard MTRH based, since COMMON users may give a damn about the speed too.
Originally posted by cd-rw.org
I don't think -standard needs to be such a high bitrate or quality as --dm-preset standard.
Is MPC -standard transparent? Or Psytel AAC -standard?
If --r3mix is transparent to some people, I can assure you that both of those are very much more transparent at those settings. If you want the truth, I would take mpc -standard over --dm-preset standard anyday. So yes, I would say they usually are to most people.
However, that wasn't my point. My point was that --r3mix which you proposed as "standard" was not AQ, and since AQ is being pushed very heavily by some, it doesn't seem to make sense to me that the default setting wouldn't even conform to that.
After standard is supposed to be "in the middle of the pack" solution. Also, I would definitely make the standard MTRH based, since COMMON users may give a damn about the speed too.
Well I can promise you right now that Roel will
NEVER agree to --r3mix being labeled as a "middle of the pack" solution. If you don't believe me, just go ask him what he thinks of this. Heh.. I can assure you he won't like it. He'll tell you something to the effect that --r3mix is transparent to most people on most equipment (despite the results from the AQ test) and marginalize the difference that --dm-preset standard provides, saying that to most people it doesn't matter. Either that or he will say "well no lossy solution is 100% perfect, --r3mix is good enough, etc, etc". So talking to me about all of this is kind of pointless if you can't even get the other party to agree to any of it first anyway. Perhaps you should go talk to him.
Anyway, my point was that the "standard" mode should be transparent to a certain degree to most people. As I understand it, this was the point behind Roel's AQ test, to determine which settings can be considered "Archive Quality" for most. --r3mix fails here. Considering that mpc's -standard mode is probably more transparent than --dm-preset standard even, and you made the comparison, this is important.
That being said, I do agree that the standard mode should be relatively quick. However, I gather that you think I have no interest in speed at all. This is not true, and infact many of the modifications I am working on I originally was going to try and implement with vbr-mtrh, but right now it is still not ready. It also still does not work with nspsytune optimally or correctly. This will change once Robert implements the new -X modes completely, but right now they aren't done yet.
I totally agree with cd-rw.
Simplicity is key here.
And obviously it shouldn't a problem of person (once again, Roel vs. Dibrom, etc...)?
If this relative quality issue cannot be solved, why don't we try it with speed?
- fastest
- fast (abr 128 stuff)
- normal (--r3mix)
- slow (--dm standard)
- slowest (--dm insane)
that could work, no?
Originally posted by jord
I totally agree with cd-rw.
I never said I disagreed with him.
Simplicity is key here.
I agree.
And obviously it shouldn't a problem of person (once again, Roel vs. Dibrom, etc...)?
Umm, the problem isn't Roel vs. Dibrom, the problem is getting someone to be willing to agree to this. That means agreeing to have their setting ranked lower than another setting. If someone is obviously unwilling to make this concession (and I go on past experience here), than how can this possibly work?
If this relative quality issue cannot be solved, why don't we try it with speed?
- fastest
- fast (abr 128 stuff)
- normal (--r3mix)
- slow (--dm standard)
- slowest (--dm insane)
that could work, no?
In this case, faster speed implies lower quality, so that will obviously not work. To add to that, none of the dm-presets are really going to be very different in speed. The exception may be that "insane" is actually faster than standard or xtreme, so again that won't work.
Just a pointer that I once did a blind test which included MPC -standard as well and it was considered far from transparent. In fact I think --r3mix (v.3.88) was rated higher, but the this was some time ago so I am not 100% sure and the test was a very limited test.
About the transparency...
I think if you take a player and headphones on the street and start asking people, you'll find out that more than 90% of the people will say that 192CBR is transparent.
Actually, one local hifi magazine (respected one) blind tested audiophiles, and they couldn hear the difference in between 192cbr Blade and the original.
I am not going to start arguing about this, but I have found that if you don't know what to look for in the signal (most of the people don't) then lossy compression defects are very hard to hear.
Originally posted by cd-rw.org
Just a pointer that I once did a blind test which included MPC -standard as well and it was considered far from transparent. In fact I think --r3mix (v.3.88) was rated higher, but the this was some time ago so I am not 100% sure and the test was a very limited test.
No offense, but I don't think the test was performed under the best circumstances, and the results may not have even been interpreted correctly. I don't think any of the group tests performed by the community up to the AQ test (except for ff123's test) were very accurate or even performed correctly. In any case, mpc -standard
will outperform MP3 and LAME just about every single time on critical samples. But that aside, MPC's quality here is not the point. You want decent quality for standard but I think that if this AQ stuff makes it through, the standard mode should actually still be categorized as AQ.
About the transparency...
I think if you take a player and headphones on the street and start asking people, you'll find out that more than 90% of the people will say that 192CBR is transparent.
Maybe. But supposedly a large portion of people participating in this test didn't think they could hear the difference either, and they did. Considering all of this, speculation about what people
should is useless in my opinion. It makes much more sense to actually work with the data that we
do have.
Actually, one local hifi magazine (respected one) blind tested audiophiles, and they couldn hear the difference in between 192cbr Blade and the original.
Heh.. if someone is an "audiophile" and they can't hear the difference between an original and blade at 192kbps, then they aren't really an audiophile. But in any case, I am not familiar with that test and don't know any of the details about how it was performed.
I am not going to start arguing about this, but I have found that if you don't know what to look for in the signal (most of the people don't) then lossy compression defects are very hard to hear.
This is probably true but I don't think the quality presets of a psychoacoustic encoder should be tailored with this in mind. They should be tailored to provide quality based on real information gathered from real tests. Not just on speculation.
I think if you take a player and headphones on the street and start asking people, you'll find out that more than 90% of the people will say that 192CBR is transparent.
This AQ thing is killing this idea. If 90% of the public think 192CBR is transparent that should be good enough for the standard tag. Anything that sounds better than that and is comparable in size would be a bonus (--r3mix). Just make it clear in the documentation that there are better settings if your ears need them.
Originally posted by cd-rw.org
Actually, one local hifi magazine (respected one) blind tested audiophiles, and they couldn hear the difference in between 192cbr Blade and the original.
Hmm, I have totally missed this test. Which magazine and when was it?
Personally I believe there's something wrong with the test settings or something, if audiophiles truely couldn't distinguish 192cbr blade from the orginal. Or, those people can't be called audiophiles. (It doesn't help if you have 1M$ audiophile equipments, you need at least decent ears too...)
Hmm, I don't think --r3mix quality is or ever has been near MPC standard quality. It's easy to hear distortions and transient smear with --r3mix. Actually --r3mix is more closer to --dm-preset standard quality, but dm standard has better overall quality less ringing, has better transient handling which can be easily heard for example with castanets.wav etc..
Originally posted by Drivenbydemons
This AQ thing is killing this idea. If 90% of the public think 192CBR is transparent that should be good enough for the standard tag. Anything that sounds better than that and is comparable in size would be a bonus (--r3mix). Just make it clear in the documentation that there are better settings if your ears need them.
Hmm, didn't check the very latest specualtion about r3mix AQ test statistical analysis, but recently the result were (If I'm not mistaken) that with over 95% confidence a group of people found both 192cbr and --r3mix worse than the MPC reference sample. It would be better if a group couldn't distinguish an AQ-setting with so high confidence... That's why I don't think --r3mix should be called archival quality by any means.
Originally posted by Drivenbydemons
This AQ thing is killing this idea. If 90% of the public think 192CBR is transparent that should be good enough for the standard tag. Anything that sounds better than that and is comparable in size would be a bonus (--r3mix). Just make it clear in the documentation that there are better settings if your ears need them.
As I've been trying to emphasize, it hasn't been proven that 90% of the public think 192kbps CBR is transparent. All I've seen so far is just speculation about what
should be
good enough, let alone anything which shows 192kbps is actually even remotely transparent.
For that matter though, this whole AQ thing was never actually my idea at all. I still don't agree with or like the idea behind it, and think it has no place in the LAME encoder itself, but at this point it is looking like we have no choice. So if it is actually going to make its way into the encoder, then the presets need to actually line up with the definition of what IS AQ. We know for a fact that 192kbps and --r3mix are not at the very least.
I think that if "high quality" presets are going to make it into LAME now and entirely replace the old ones, we need to make sure that the default setting will profide sufficient quality for the "average" user. Determining this threshold is the whole point behind Roel's AQ test. Unfortunately, the results from that test eliminate what cd-rw.org is proposing we use as the default setting itself.
JohnV,
Dig out the Tekniikan Maailma 12/99. Especially page 39, lower right corner has interesting comments about quality and the human ear.
Dibrom,
Perform a test so that you do not know which is the original, and throw those headphones to the trash can and use speakers in a normal room. Also a long time ago EmediaPro had similar test results than the "Tekniikan Maailma", also with Blade 192.
But 192cbr is not the issue here - the topic is VBR presets.
You seem to something against the AQ test. It may not have been the definitive and absolute truth telling test, but it also showed that --r3mix is better than 192cbr. Noe the "-standard" doesn't have to be --r3mix, but a MTRH variant targetting around 200kbs - in other words a 192crb replacement.
192 is THE standard, so "-standard" should be a replcament for it - offering improvoved quality, with little file size gain. Audio quality sufficient for most purposes.
Originally posted by cd-rw.org
but it also showed that --r3mix is better than 192cbr.
It did not.
1. mpc is better than abr224, r3mix, and cbr192
2. dm-xtrm is better than cbr192
3. dm-std is better than cbr192
From eyeballing the results, it's unlikely we can prove r3mix > cbr192 even with more sensitive analysis.
--
GCP
Originally posted by cd-rw.org
JohnV,
Dig out the Tekniikan Maailma 12/99. Especially page 39, lower right corner has interesting comments about quality and the human ear.
Umm, don't take this wrong, but I was afraid you say Tekniikan Maailma... But, before I totally condemn this general tech magazine old article, I should read it. I have a feeling though I have read it but didn't give it much credit even back then.
Everybody can do their own ABX tests which proves totally the opposite. And even non-audiophile r3mix AQ-test found Lame 192cbr (and --r3mix) not archival quality.
Of course you can find very very easy to encode piece of music which is near transparent with Xing128, but then there's something wrong with the test setups and settings if this kind of music is used. (A bit exaggerated but you get the point.)
I think some of you are forgetting few things: most of the people don't recognize artefacts of lossy compression-they may hear a difference, but can't tell which is the original. Most people listen to music with speakers which makes fiding artefacts a whole lot harder. I know this-I been into hifi for ten years and I have a pair of Genelec active studio monitors. I can hear a bad freq curve, sloppy bass, hard high register, or any other way in-balanced sound very easily. I can easily listen and give feedback on speakers, but hunting for MP3artefacts is still very hard for me. I have never bothered to look into them either, since they are not so bad if you are not aware of them. Also, not many people have good soundcards. You are the extreme cases and thats why there should be an extrme preset for you and the standard preset for the Joe Average.
Ok, now let's get back to topic, shall we? This wasn't supposed to be a -r3mix vs. dm issue?
Everyone agrees that we should dumb personalized presets, and make things more understandable with a "standard" preset setup in the fashion of MPC or Psytel AAC?
I proposed a MTRH variant settings that produces bitrates around 200kbs: In other words a solution that gives quality improvements over 192cbr, reasonable speed and maintains a good compression ratio. In the middle of the pack solution, a good compromise.
xtreme, like the name implies should the choice for high fidelity, extremely high quality.
insane, would be something to squeeze out the maximum theoretical quality.
I don't quite see the point why -standard should be as HQ as --dm standard, since that's propably not what Joe Average is after. And naturally the help/docs would describe the nature of the presets and incidate that hifi freaks should use -xtreme for improved quality.
Well, in my modest opinion, I think both cd-rw.org and Dibrom have the reason.
Newbies doesn't want any complication (and they are very numerous), but there is people that want quality.
For example, I'm reading those forums of audio-compression about 2 years, trying to find a good parameters to encode a good mp3.
I think to acomplish with both worlds maybe this classification:
-insane (dm insane )
-xtreme (dm xtreme)
-standard (dm standard)
-standard_fast (r3mix)
-divx (abr 128kbps stuff?)
-radio
-thumb? (something small)
or beetwen to standars, perhaps:
-standard_hq -- -standar_lq
-standard_high -- -standard_fast || vbr192
I think the both presets have sense, because to newbies the combination of speed, quality and size of r3mix could be really important. While dibrom standard (dibrom presets) could only be apreciated by a people concerned about audio quality.
I'm studying computer sciences, obtaining mp3 in my faculty is really easy...really. But the quality is really poor 128 (Xing). I have friends who don't want use lame because of it speed vs Xing, or because a good preset size results.
And yes I'm talking about advanced students of Computer Sciences. When I started in mp3 world I believe that if an mp3 encoder (xing) says 128 is cd quality, is true.
Well dibrom I'm trying to say you, that the vast majority of people isn't concerned absolutely nothing about quality(because 128-192 is enough for them), but they produce the majority of mp3 in Internet
This reason is why has sense r3mix in a standard preset, simplicity, speed, quality and size. Many people like I said before would never used dm_standard, even lame.
Personally I'm using dibrom_standard instead r3mix since I have knowlege of it, and it quality. But I couldn't distinguish beetwen them, I encode with db_standard because maybe in future I would have better equipment. Hence I want a standard that offers me a really high quality over speed and size.
Well, I'm only trying to help, if it's possible.
Excuse my poor English, this text is too large to my knowledge¡¡
Sergio
Originally posted by cd-rw.org
Perform a test so that you do not know which is the original,
Ever heard of ABX? I use it all the time...
and throw those headphones to the trash can and use speakers in a normal room.
Why? This is how I choose to listen to my music often. If the music doesn't sound good on headphones, I don't care of it sounds OK on speakers.
But 192cbr is not the issue here - the topic is VBR presets.
Exactly, so why did you bring it up?
You seem to something against the AQ test.
No, I have something against certain people spreading mistruths about the results, and meanwhile calling those trying to get something useful out of it liars.
It may not have been the definitive and absolute truth telling test, but it also showed that --r3mix is better than 192cbr.
Sadly it didn't. And this is one of the biggest problems. If you were to go on Roel's "interpretation" of the results, he would have you believe that there was no difference between
any setting and the original except for 192kbps. Lately he has gone so far as to say that MPC may not have even been shown to perform better than --r3mix, yet looking at Garf's and ff123's stastical analysis of the results there is such a high probability that there would be no possiblity for this not to be the case!
192 is THE standard, so "-standard" should be a replcament for it - offering improvoved quality, with little file size gain. Audio quality sufficient for most purposes.
Well first of all, I don't give a damn about what the mp3 council thinks is "standard". Their idea of "quality" is just laughable. What I care about is providing a preset which is sufficient quality also. But I think that preset should be one which is reasonably transparent to most people, and also, if the AQ bit goes in, even the standard mode should be considered AQ.
Originally posted by cd-rw.org
Ok, now let's get back to topic, shall we? This wasn't supposed to be a -r3mix vs. dm issue?
I don't think anyone ever said it was a matter of this issue. Some people seem to think that whenever I say something which is not necessarily favorable towards Roel or his switches that it comes down to this.. heh.
Everyone agrees that we should dumb personalized presets, and make things more understandable with a "standard" preset setup in the fashion of MPC or Psytel AAC?
Yes
I proposed a MTRH variant settings that produces bitrates around 200kbs: In other words a solution that gives quality improvements over 192cbr, reasonable speed and maintains a good compression ratio. In the middle of the pack solution, a good compromise.
Well for one, I would like to state that --dm-preset standard actually isn't too far from this bitrate. And once --vbr-mtrh is upgraded to support these new -X modes, I will be switching to that also. Plus with some of what I am working on, I'm already seeing bitrate decreases of up to 10kbps or more in some cases (though none of it is finalized yet). Considering that --dm-preset standard only averages about 10-20kbps more in bitrate over --r3mix... well you get the point. So it is very possible that in the near future, dm-standard could actually fit all of that criteria. Except for just being a "middle of the pack" solution.
xtreme, like the name implies should the choice for high fidelity, extremely high quality.
insane, would be something to squeeze out the maximum theoretical quality.
I agree on both of those points.
I don't quite see the point why -standard should be as HQ as --dm standard, since that's propably not what Joe Average is after.
1. Because it is possible to allow this.
2. Because AQ has been pushed so hard by some people, and now a standard setting should conform to this rating.
3. Because it may actually be possible to get dm-standard to overcome its current weaknesses (slower speed, and slightly higher bitrate) before too long.
I think just using something lower quality in a hasty manner wouldn't be the most prudent idea.
Hmm, didn't check the very latest specualtion about r3mix AQ test statistical analysis, but recently the result were (If I'm not mistaken) that with over 95% confidence a group of people found both 192cbr and --r3mix worse than the MPC reference sample. It would be better if a group couldn't distinguish an AQ-setting with so high confidence... That's why I don't think --r3mix should be called archival quality by any means.
That's my point. AQ is killing this idea. Who said the proposed --standard has to be "AQ"???
Also.. in a situation like this, and given the fact that all of this AQ stuff is likely to make it into LAME, I think it is important to keep the "standard" mode still within the AQ category.
I think that if "high quality" presets are going to make it into LAME now and entirely replace the old ones, we need to make sure that the default setting will profide sufficient quality for the "average" user. Determining this threshold is the whole point behind Roel's AQ test. Unfortunately, the results from that test eliminate what cd-rw.org is proposing we use as the default setting itself.
Although I agree with all parties involed that --r3mix is not AQ, I also don't believe the test Roel gave wasn't in any way taken by "average" users. "Average" users are the ones who share all those 128CBR files on winMX. "Average" users just want to slap on their headphones and throw some weights around while stuffing as many MP3's into their portable players as possible. The people who take the time to read these boards and understand the inner-workings of these programs are simply not your typical MP3 listener. The bottom line is this whole "AQ" threshold is going to be impossible to agree upon so why refer to it when deciding on new presets. --standard should be quick with decent quality to please the masses. I won't use it and neither will most users on this board but many will freak out when they see how much better lame --standard (--r3mix) sounds compared with what they have been using.
Sorry, I didn't read the last couple of posts, I'm kinda in a rush tonight. (wife not feeling good, 2 days overdue with our 2nd kid)
it may actually be possible to get dm-standard to overcome its current weaknesses (slower speed, and slightly higher bitrate) before too long.
i must agree with cd-rw.org, simplification needs to made, and i believe that --r3mix should be standard. common guys, almost everyone outhere is trading 128cbr mp3s claiming that those are cd quality, ovbiously --r3mix is better than that, and most of the times it is good enough for the vast majority of users. sure there will be people who require more quality than that, and there's where dibrom's presets kick in. i think it would be wrong to use all dibrom's presets (including standard) because they're are slow, and there are still some of us which are using slow computers, and to be honest speed is also important to me, and quality wise --r3mix is a good compromise between quality and speed and you must remember that after all it is lossy compression.
You may not give a damn about the MP3 council standard, but I do. Why? Because I don't look at this just as an encoding solution for me or you or the 50 mp3philes that hang around the "LAME scene". I wan't the world to change away from 128-192 to good quality VBR. Currently I am just waiting for your new presets in order to launch a new MP3 encoding article for tens of thousands of people, striking to the core of the MP3 scene.
The people have something against VBR. I think that if they are given dm standard as a default, they'll be scared by the large files and are less likely to use it. But if we can sell a decent VBR setting offering good quality and competitive bitrates, the step to talk them out to switch from -standard -> -xtreme is a whole lot smaller. But first we need to get them to use VBR.
Marketing Dibrom, marketing..
If you are able to cut the bitrate and use MTRH, then that's more than fine. As I said before, it does not have to be -r3mix, but any MTRH variant targeting to the same bitrate range. the dm standard currently shoots 20-30kbps above --r3mix (depends on the music, naturally, but in my case).
Talking about the AQ test, I think that the participants were far for the average. It might be useful info for determining AQ, but certainly it won't tell anything about the Joe Average. The LAME-people tend to have: great sound cards, good headphones, good amps/pre-amps, good speakers, quality wiring all the way...this is not the average people!
Originally posted by cd-rw.org
You may not give a damn about the MP3 council standard, but I do. Why? Because I don't look at this just as an encoding solution for me or you or the 50 mp3philes that hang around the "LAME scene". I wan't the world to change away from 128-192 to good quality VBR. Currently I am just waiting for your new presets in order to launch a new MP3 encoding article for tens of thousands of people, striking to the core of the MP3 scene.
Well I understand your point, I just don't think this is ever going to happen. I've actually been involved in parts of the mp3 scene before and know quite a few of the "higher up" people in the mp3 councils, and I can tell you, they just don't give a damn. I don't think there is anything you can say that is going to change their mind about quality. They are stubborn and they have been doing it the same way for a long time now, it is unlikely that anything is going to change that, except for switching to another format.
The people have something against VBR. I think that if they are given dm standard as a default, they'll be scared by the large files and are less likely to use it.
Well for one, I think it is a common misconception that dm-standard
always gives high bitrates. I have plenty of albums that encode in the 160-190kbps range with these settings. Sure, --r3mix may be lower on these particular clips, but while you are comparing --dm-preset standard to 192kbps, keep that in mind. The problem is when you encode metal that you start to see significantly higher bitrates.
But if we can sell a decent VBR setting offering good quality and competitive bitrates, the step to talk them out to switch from -standard -> -xtreme is a whole lot smaller. But first we need to get them to use VBR.
Marketing Dibrom, marketing..
People are so scared of VBR and joint stereo, I don't know how you can ever possibly convince them. There was a thread started recently on this board titled something like "I know sound quality" or something similar. Much of the line of "thinking" you see there, is the same you will see from the people out there convinced that 192kbps fhg is perfect.
Yes, I understand the point in actually trying to convince these people, I've tried before and I've seen many others try as well, and it never works. Considering that, yeah, I am much more willing to cater towards the crowd that
DOES care about quality (many of the people here and on r3mix.net). After all, it is these people that are likely to help convince others in the long run. So catering presets to a crowd that more than likely doesn't even care in the first place, doesn't seem to make quite so much sense for me. Not to say they couldn't use all of this though. They would probably rather use a smaller setting than -standard anyway, to save space and possibly get some sort of speed increase.
So the same people you keep talking about using 128kbps that "need" high quality vbr, are probably going to be the first people to ignore the efforts anyway.
Talking about the AQ test, I think that the participants were far for the average. It might be useful info for determining AQ, but certainly it won't tell anything about the Joe Average. The LAME-people tend to have: great sound cards, good headphones, good amps/pre-amps, good speakers, quality wiring all the way...this is not the average people!
Yeah, keep in mind though that the AQ stuff was not my idea. It was someone elses idea, and again, it is likely going to make it into LAME in some form or another. This means that anything else added to LAME should be taking into consideration all of that. If you promote AQ, but your default setting doesn't actually provide AQ, then what does that say? It tells everyone to use a higher quality setting, and basically kills the usefulness of having one setting as a default in the first place.
It may sound elitist of me, but I think those who actually want the higher quality should be those that are catered towards first. After all, they are the ones who have been spending the time and effort performing listening tests and learning all they can to achieve this. Nothing is stopping anyone else from doing the same.. they just aren't as interested. So why should we tailor for them? I'm just not convinced..
Also keep in mind that it would be far better to overshoot the quality margin than it would be to come up too short (at least in my opinion).
If you really want to include some lower quality presets as LAME defaults, that is fine. Just don't expect me to support that kind of thing. I'm not interested in lower quality, and neither are many of the people who's opinions I value the most, so asking me to place that as the highest priority overall is pretty much an impossibility.
I'm doing my best to increase the performance of LAME in regard to the --dm-presets in every way I can think of, and to help integrate all of this into LAME more smoothly, but quality is not something I am willing to sacrifice. For me to do so would be to go against everything I have worked towards so far. Maybe you can understand that, maybe not.
Oh yes I do understand your view. You consider this issue form your personal perspective, while I try to do it from the perspective of the general audience.
Yes, I know that dm-standard can go lower in some cases. Mellow rap tunes are one example where VBR settings usually dip rather low.
More opinions? Where are the LAME developers?
Originally posted by cd-rw.org
Oh yes I do understand your view. You consider this issue form your personal perspective, while I try to do it from the perspective of the general audience.
If you read my message, you would see many references to what other people think about this matter. Yes, I am considering other people's perspectives on this. I think the audience you are targeting (the mpc council audience) is not going to be interested. The people here
ARE interested though, so I think they are the ones that should have more influence in this case, as they are the ones that will be taking advantage of this the most anyway.
Regardless of what presets go in, LAME is still going to see
FAR more use at 128kbps CBR. You are not going to change this with a single article, or even a zillion articles. Therefore, going backwards in quality to "accomodate the majority" (of people who don't like or use VBR or js anyway) seems rather pointless to me.
Yes, I know that it is quite impossible to change the world in this. I however wan't to share and pass this good message to the maximum number of people, rather than keeping it as the valuable little secret of a small community.
If I contact 100.000 people with an article, I sure that couple of heads will turn. Turn again, my previus LAME article had quite a lot of reactions at the CDFreaks.
Maybe lame should use the original --preset command to accomodate any kind of preset. It already has phone/voice/fm/tape/hifi/cd/studio so it could be a matter of adding some more names. The difficult part would be choosing the proper names.
Originally posted by Artemis3
Maybe lame should use the original --preset command to accomodate any kind of preset. It already has phone/voice/fm/tape/hifi/cd/studio so it could be a matter of adding some more names. The difficult part would be choosing the proper names.
Hrm, I think that's what they're fighting over.
--
GCP
Originally posted by cd-rw.org
You may not give a damn about the MP3 council standard, but I do. Why? Because I don't look at this just as an encoding solution for me or you or the 50 mp3philes that hang around the "LAME scene". I wan't the world to change away from 128-192 to good quality VBR. Currently I am just waiting for your new presets in order to launch a new MP3 encoding article for tens of thousands of people, striking to the core of the MP3 scene.
The people have something against VBR. I think that if they are given dm standard as a default, they'll be scared by the large files and are less likely to use it. But if we can sell a decent VBR setting offering good quality and competitive bitrates, the step to talk them out to switch from -standard -> -xtreme is a whole lot smaller. But first we need to get them to use VBR.
I don't get it. You are basically trying to get the people putting out cbr192 files right now to switch over to a VBR setting.
The dm presets aren't good because
a) they're slower
b) they give big files (+- 200kbps)
Okay, fine, but why try to convince people to use VBR when you give them --r3mix?
a) it's slower than CBR
b) it doesn't seem to give better quality than cbr192
If speed is so important, then what's the advantage of r3mix VBR here?
Talking about the AQ test, I think that the participants were far for the average. It might be useful info for determining AQ, but certainly it won't tell anything about the Joe Average. The LAME-people tend to have: great sound cards, good headphones, good amps/pre-amps, good speakers, quality wiring all the way...this is not the average people!
The test included a lot of people not having experience with listening tests. It was a very good sample for people that are at least remotely interested in mp3 quality.
Edit:
My basic issue with this whole thing is that you guys are trying to get people to use VBR because of quality issues, but then immediately make a compromise (r3mix) that gives a minimal, it at all, quality improvement. What exactly are you advocating here??
--
GCP
Originally posted by MyMaster
i must agree with cd-rw.org, simplification needs to made, and i believe that --r3mix should be standard. common guys, almost everyone outhere is trading 128cbr mp3s claiming that those are cd quality, ovbiously --r3mix is better than that, and most of the times it is good enough for the vast majority of users. sure there will be people who require more quality than that, and there's where dibrom's presets kick in. i think it would be wrong to use all dibrom's presets (including standard) because they're are slow, and there are still some of us which are using slow computers, and to be honest speed is also important to me, and quality wise --r3mix is a good compromise between quality and speed and you must remember that after all it is lossy compression.
By the same reasoning, I recommend --abr 160 as --standard
a) it's better than cbr128
b) good enough for the 'vast majority of users'
c) if they want more, dm presets kick in
d) it's fast for the people with slow computers
e) good compromise between quality and speed
And, after all it's just lossy compression!
--
GCP
It seems to me that there are basically 3 categories of audience here:
1) Those for whom size is all important; ie. how many MP3s can I squeeze in to my portable player. These people are mostly going to use 128CBR and Real Jukebox, MusicMatch, or the like. Few of these people will be likely to pay any attention to the "quality" arguments here. At best, you might "sell" them a better 128 mode.
2) Those who are interested in quality but are also size limited.
3) Those for whom quality is of more importance than size.
Spending time on the first category seems to me to be a noble but fruitless exercise. Surely the only real target audiences are categories (2) and (3)?
Most of the people who fall into category (1) wouldn't know quality if it hit them between the eyes. For them VHF stereo radio is as good as it gets!!
I agree with both parties on this one, but am leaning towards Dibrom's opinion on the issue. The fact is, people who just want low filesize and don't care about quality will always first try the -standard preset. Then, when it comes out too large for them (probably without them even listening to the quality), they'll just use a preset that gives a lower filesize (personally, I think these presets shouldn't have names at all, but should be identified by numbers, preferrably with an even amount of choices, e.g. -preset 1-4). So, what's the point in making -standard lower quality than transparent as it is? The ignorant will STILL go for a lower filesize, since they will believe the filesize they reached with -standard is, naturally, "standard", so they'll always go lower from that, despite if the audiophile community considers it transparent or not! You can see the basic reasoning here like this:
Of course, there will also be the "unsalvagable" who will simply keep lowering the preset until it reaches the filesize they want, but those will excersize this regardless of whether -standard is transparent or not! However, since most people will go for -standard right away, it's much "safer" to make that setting of good quality to begin with.
Oog, I had difficulty expressing this, but I hope you'll understand what I'm trying to say.
I personally use dm -standard. I like what it does for me, and have a ton of disk space. However, I tend to agree that perhaps an "-r3mix like" or abr160-like setting would be best as a default setting, because it is faster, good enough, blahblahblah. I would also agree that there should be a clear switch for a dm -standard setting, for people who want the higher quality like me, but aren't into it enough to learn / figure out how to get it.
I am relatively new to mp3, LAME, and the use of the exe instead of the dll. I went from using Audiograbber and a lame.dll at first, to messing with the dll settings, to the external in about two months. Slow. I was interested, though. I tell people about all this, and they say "Wow, how did you learn about that?" But then they don't bother to take it any further.
The goal is to improve the quality of mp3s floating around, right? So let's do that, but leave the primo settings for people who care, and make it easier for them to get it with a nice big button. And perhaps even a line that says (Increases bitrate) for those that have no clue.
I commend Dibrom for catering to those of us that want superior quality first. I mean, there will always be cruddy 128s out there. I only trust what I have encoded myself. That is, what I have encoded since gaining some education on it. Sometimes I am surprised by other people's rips, but not too often.
My idea of utopia in three settings:
a) portable mp3 player setting - fast, low bitrate, as good as it can be for about 128
b) -r3mix type setting - most bang for buck theory, high speed and good quality
c) fine-tuned dm -standard setting - higher bitrate, slower encode, but worth it, dude!
Originally posted by YouriP
(personally, I think these presets shouldn't have names at all, but should be identified by numbers, preferrably with an even amount of choices, e.g. -preset 1-4).
Indeed that's more useful and in line with some other options in LAME. Why not have
-VBR [0-9] ? Scalability being the keyword. To eliminate long arguments which is better, let the ranking be size and nothing else (even that can cause problems with VBR ).
The rationale being that a good preset should be trying to get the best quality for its size.
As for the hard work people have put into presets, I wouldn't mind if Dibrom would provide the settings that target maybe -VBR 0 and 1 (if he wouldn't mind too).
Well I'm not so sure about what -VBR 9 should be, but maybe it could be used to compress telephone conversations
It would be nice to have scalable (VBR) presets in the range that LAME is capable of doing, not just the part we think is "good quality". Different people might have different needs.
On the other hand if VBR isn't doing anything good on average bit rates under 128 then -VBR 0-4 would be plenty of choice. (never even tried those myself).
that's my 2 eurocents.
BTW. no big problem to have the --dm-preset and --r3mix as well, (aliases ?) having a status like the experimental switches.
Ge Someone.
I suggested the usage of -standard -xtreme -etc. due to the fact that Psytel AAC and MPC use such names for their presets. They are a sort of a standard, make sense and using such presets makes it easier for a newbie to try these different encoders.
Originally posted by cd-rw.org
I suggested the usage of -standard -xtreme -etc. due to the fact that Psytel AAC and MPC use such names for their presets. They are a sort of a standard, make sense and using such presets makes it easier for a newbie to try these different encoders.
I agree. In my opinion -standard -xtreme etc. naming is better.
One thing that is bothering me with --r3mix setting being the -standard is that it doesn't have very good pre-echo control. It's often at the level of Lame192CBR, with some pre-echo test samples I actually prefer Lame192cbr over --r3mix, which is not very good.
Let's see what Dib has to offer. Maybe something can be done to combine vbr-mtrh, close to --r3mix bitrate and better pre-echo control. Part of the problem is that lack of nssafejoint has negative effect on pre-echo.
This should be done right at the first time and not rush too much. I believe (at least hope) that better than --r3mix quality can be achieved with similar bitrates. And yes, in my opinion the lack of speed of vbr-old would be somewhat a problem for -standard preset.
If things can be done better with similar --r3mix ~200kbps targetting bitrates with MTRH speed(I think this is important for the -standard), then by all means please do so.
Sure sure, cd-rw. But i don't think we should rush now. Robert is doing vbr-mtrh modification that makes other than average noise measurement work correctly. Dib is doing very nice tweakings.
In my opinion we shouldn't rush now.
Hi all,
I can understand the current dilemma that everyone is debating here. I understand Dibrom's stance that quality should come first because everyone involved on LAME lately has been trying very hard to improve quality and testing to help improve quality.
I also see the other side of the coin that LAME should be adapted to appeal to a greater range of listeners than just audiophiles.
There is a compromise here and one that I think we can clearly categorize for all people who want to use LAME from the mp3-portable user all the way up to archival-CD-burning-quality users. I agree that an attempt has to be made to convince the "mp3-council" to use VBR. Even if that attempt is fruitless, a hand must be extended in sincere wisdom nonetheless. I'm convinced if we do this, some of their brethren will breakaway from the pack and give LAME a legitimate shot. The 'AQ-test' was a fantastic first step towards convincing these people to use VBR over CBR, and that when properly implemented, joint-stereo can deliver just as high quality a sound as full stereo.
I would say we should allow a two or three tier quality spectrum separating user interest levels. A level for portable users in the 96 kb/sec - 128 kb/sec range. A level targeted at casual users who are limited in hard drive space and CPU speed, but want decent quality, acceptable speed, and simple user-friendly commands or a front-end for windows, their target is 128 kb/sec - 160 kb/sec. Finally, we can have a level catering to ourselves at the top of the ladder and label this level the popular "AQ".
PORTABLE USER - Recent developments in LAME settings have resulted in an array of good low-bitrate command lines which should interest portable users. Remember ff123's command line? -b128 --nspsytune -mj -h --athtype 2 --nsbass -8 --lowpass 16 I'm sure the brilliant minds here can come up with some nice command lines for the low-bitrate crowd.
CASUAL USER - I agree with Dibrom that we aren't likely to convince many casual users to give up the medium bitrates and it will be very hard for them to understand the advantages of VBR when they see wild differences in bitrate from song to song. We can likely get them to use ABR in this range. This would greatly improve their results and may allow them to make a step towards understanding and accepting VBR. Try to introduce --r3mix to this crowd or re-tool r3mix to keep bitrates under 192 kb/sec. This will require us to convince Roel to maybe lower --r3mix quality just a tad for the casual user.
AQ LEVEL - No explanation needed. All the high quality presets can fall into this category. --dm standard can be the hallmark setting for most users and we can try to encourage casual users to adopt this setting as it gets lower in bitrate.
If we make it clear what "level" of user we are talking about, then we can easily make presets that they can enjoy. That's my compromise. What do you guys think?
mp3
I totally support the idea of people's names not being attached to preset names for two reasons.
1.It seems to affect the ego very negatively in some, seeing there nick in that command line box. We have witnessed some very innappropriate behaviour over the last few months which was at least partly related to the naming issue IMO.
2.It seems to cause extreme conservative behaviour for the switches in the given preset. Getting a change implemented without a bruised ego should not be the principle concern.
Hmm,
I really don't care if someone uses their nickname in a preset or anything else. If someone put their hard work into a good commandline and even contributed some code, then why not? Most people will eventually be using a windows frontend or .dll for their LAME mp3s anyway when a stable release comes out. The only people who really know who "r3mix" or "dm" are, are us here on the bulletin boards. I personally don't even know Dibrom or Roel. So what if they work hard on something and put a nickname on it? I think it's only natural to feel some pride and a deep sense of accomplishment when something you work hard on is being used by many people.
On the other hand, you make a point about over-blown ego's and hurt feelings when presets don't test as well as the creator intended. Roel saw the test results of "AQ" and was in denial about the results. If the second AQ test proves again that r3mix isn't quite AQ, then it might hurt him a lot. I know how hard he has worked on this stuff. I see myself as not having an ego to bruise, but then again, I haven't put my sweat and work into a preset. It's easy to tell these guys not to have an ego about it, until it's you who creates one that doesn't come out well on a test.
mp3
I agree totally that hard work should be acknowledged and appreciated. But the negatives have outweighed the positives very much in the last month or two, at least for me.
There is also a big difference between CREATING switches and changes in an encoder and using the ones created by others. The lame changelog is a very exclusive club to find one's name, and I think this is a more appropriate place to acknowledge such efforts.
Everyone in this community knows who is actually trying to improve the product and who is trying to cling to an idea proven false anyway.
Getting rid of the names wont solve the ego thing but it might take the edge off and ease/speed changes to the presets when improvements are made, IMHO FWIW.
Originally posted by kennedyb4
I totally support the idea of people's names not being attached to preset names for two reasons.
1.It seems to affect the ego very negatively in some, seeing there nick in that command line box. We have witnessed some very innappropriate behaviour over the last few months which was at least partly related to the naming issue IMO.
Sigh... I'm tired of seeing this. I see a few people complaining about the fact that I have my initials on some presets (which I
never asked for btw) and so I think I'll change them... then everyone else tells me they want them left the way they are and that those complaining are in the minority. So I think.. "ok fine". Then I continue to see this kind of thing. My conclusion? That it is basically a complete waste of time to bother worrying about what people think of the name of a stupid preset. I don't care if the name does get changed at this point, but I'm not going to bother spending time worrying about who this will affect of why, etc. If a name change comes it will be when it is appropriate and it will have little to do with any of this.
Oh, and if you actually think that what has happened recently has anything to do with me thinking my presets are superior because they have my initials on them, you are totally wrong. I
know they are superior because they have been proven so. What all this has to do with (recent events that is) is not related to that, it is related to the fact that certain people cannot handle the truth, and they are willing to totally disrespect and mistreat others in the community simply to further their flawed agenda.
2.It seems to cause extreme conservative behaviour for the switches in the given preset. Getting a change implemented without a bruised ego should not be the principle concern.
Care to be a little less vague? I'll take a guess here and assume you are referring to nsmsfix. If not, then completely disregard the rest..
I've already explained multiple times in the past why nsmsfix has been inappropriate to use to decrease bitrate without affecting quality. You seemed to have not understood this. Recognize that there are those out there who have a different opinion about quality and where compromises should be made to acheive a lower bitrate.
Common sense would have had that I should have used athtype 3 (old version) in the past to lower bitrates, right? Well look at what happened when I created dm-preset standard.. I found a much better and much more appropriate solution. The same thing is happening now. I've found a much more appropriate solution to decreasing bitrates and in fact I'm working on more fundamentally solving the issues that safejoint has helped to fix in the past, so now nsmsfix isn't such a problem. But, when it was originally brought up, it was not appropriate.
So instead of thinking about "conservatism" and "bruised egos" you should perhaps be glad that someone is willing to not add some switch to a preset just because it's the "new thing" and that popular demand says it should be there, even though that is not backed by a single objective test at all. In fact, I
did try to get some people to perform some testing with this switch since they were interested in it's use, but asking for this got me a bunch of flames instead. So I'm sorry, but when shooting for the highest quality level possible, it should be understandable that I will only make a change which I am
certain will not decrease quality, not
at least without offering higher quality elsewhere. In addition, I need to have
objective data (multiple abx test results) which shows this.
Again, if you were not referring to the nsmsfix issue again, then feel free to ignore all of that..
Dibrom,
I have to ask. Have tests been done that lead you to believe that nsmsfix is hurting quality when it's used to lower bitrate? And if so, at what setting is the quality being hurt? I'm interested in your findings.
mp3
Dibrom,
Clearly you have spent so much time defending yourself from J and --r3mix that you are on red alert for criticism.
Please re-read the posts I have made. The comments made are not directed at you whatsoever.
I would however still believe that the removal of any "personal" ID attached to a preset would be a good thing for the reasons I mention.
The conservative behaviour I mention also does not apply to you. Your presets appear to be under regular revision/ testing, yes?
As far as -msfix goes, I understand your explanations for not pursuing this for your presets. I still believe it is a worthwhile adjustment to look at in the future. It may have a place for multimike stuff around 160kbit, for instance. Or 192 cbr or abr.
i also think that it's much wiser to rename presets
i told this already many times....
Originally posted by mp3fan
I have to ask. Have tests been done that lead you to believe that nsmsfix is hurting quality when it's used to lower bitrate? And if so, at what setting is the quality being hurt? I'm interested in your findings.
Yes, I have found that in some cases using a higher nsmsfix value actually has an audible impact (for the worse) on quality. I've mainly come across this on samples heavy on impulses such as fatboy and some of the others. It appears that these particular clips even cause problems for joint stereo interestingly enough.. I'm working on other ways to improve the quality in these situations though, so once those are in place nsmsfix will be used if appropriate.
Sorry, I don't have any hard numbers for you at the moment because I've been constantly testing and tweaking various settings, but especially on these particular types of samples, the joint stereo thresholds are so critical that I've actually been working on ways to make switching criterion even
more strict in various situations to improve quality.
Originally posted by kennedyb4
Clearly you have spent so much time defending yourself from J and --r3mix that you are on red alert for criticism.
Please re-read the posts I have made. The comments made are not directed at you whatsoever.
Yeah, I re-read them. I'm sorry if I offended you, but I honestly thought those comments could have been (and actually were) directed at me since I've seen people attempt to criticize me on those very issues lately. At any rate, I should have probably taken a bit more time to think about the statements before responding. Again, sorry about that..
I would however still believe that the removal of any "personal" ID attached to a preset would be a good thing for the reasons I mention.
Possibly. I don't actually put my full nick on the presets and they are only even there to differentiate the work that I'm doing from the rest of the stuff. The dm signifies that they are presets that are designed separately from the standard LAME presets.. and also that they are subject to much more in depth testing and tuning to achieve optimal quality. In this case it isn't so much that they are
mine because they have my initials on them, it's more just a reference to what I'm working on or towards. Changing the name might be prudent, but I'm not sure what it should be changed to. I'm also not really sure that it is worth worrying about at this moment because I may actually change the entire preset structure when I finish these latest modifications.
The conservative behaviour I mention also does not apply to you. Your presets appear to be under regular revision/ testing, yes?
Well, it appears so
As far as -msfix goes, I understand your explanations for not pursuing this for your presets. I still believe it is a worthwhile adjustment to look at in the future. It may have a place for multimike stuff around 160kbit, for instance. Or 192 cbr or abr.
I have already been looking at this a lot lately. If I can find a way to use something which lowers bitrate without decreasing quality, rest assured that I will take advantage of that.
Originally posted by kennedyb4
Everyone in this community knows who is actually trying to improve the product and who is trying to cling to an idea proven false anyway.
Hi folks!
I would NOT vote dm-standard as the "standard" preset. Standard would probably be what the average user would try first, and I don't think confronting Joe Average with slow encoding speeds and huge files would give a good impression of LAME ("huge" files in comparison to CBR 160 or 128, which Joe Average probably would have been using until he bumps into the new LAME presets).
If all these presets were to be VBR, I would definitely vote r3mix as the standard preset (even if Roel wouldn't like it much ). Quality is very good (and SURELY good enough for Joe Average, if not too good), encoding speed is also damn good, and the file size - for a tolerant Joe Average - is acceptable on "normal" music. But as soon as Joe Average encodes sophisticated music (or if Joe Average is intolerant in the first place), he will get upset about the big files.
So, if not all presets have to be VBR, I would suggest some ABR160-like setting as the standard preset. A well tuned 160ABR mode provides good enough quality for just casual listening through PC speakers anyway, and for Joe Average, it provides good enough quality in any case.
Only... if the standard preset was to be ABR160, where would --r3mix go? It's not good enough for "extreme" IMO (that should be dm-standard), it should be something inbetween standard and xtreme, maybe a preset labelled "better" or something...
The setting below standard (for portable MP3 players for example, as has been suggested many times, or just for those ingorant low bitrate peasants) should be ff123's / Hans' ABR134 command line (I don't understand why, but it really is SO MUCH better than the equivalent CBR128 line, which still is quite good in most cases).
Dibrom's presets should be easy to accomodate - dm-standard would be "extreme", dm-xtreme would be... ummm... don't know, and dm-insane would be "insane".
CBR presets should not be included, surely. That would completely destroy the sense of our mission to stop everybody from using it
Remember, all this is just my opinion. (I don't understand AT ALL why a "standard" setting would have to be transparent, BTW)
CU
Dominic
Word Volcano.
I just think that -standard should target the 192kbs range since it is some sort of a standard bitrate. Also the MTRH speed is important here.
Good to see more opinions on this. After all, WE ARE NOT affected by these decicions. We are very able to make our independent decicions on presets/settings we wish to use. This decicion mainly effects the 1st impression that the John Doe gets when he tries LAME.
I thought maybe some bitrate settings might help. Joe average understands this concept.
A 128, and 160 setting, and THEN jump into dm standard or --r3mix around 192?.
You seem to see alot more higher bitrate files for trade but still the majority is 128 or 160.
Originally posted by Volcano
I would NOT vote dm-standard as the "standard" preset. Standard would probably be what the average user would try first, and I don't think confronting Joe Average with slow encoding speeds and huge files would give a good impression of LAME ("huge" files in comparison to CBR 160 or 128, which Joe Average probably would have been using until he bumps into the new LAME presets).
First of all, this is exactly why I don't think it is the time to be making decisions about all of this. The new dm-standard actually uses vbr-mtrh now (yes I've moved it over to that) AND file sizes are going to be smaller, in addition to providing improved quality. I'm just not finished with all of this yet. Think "smaller, faster, better"
If all these presets were to be VBR, I would definitely vote r3mix as the standard preset (even if Roel wouldn't like it much ). Quality is very good (and SURELY good enough for Joe Average, if not too good), encoding speed is also damn good, and the file size - for a tolerant Joe Average - is acceptable on "normal" music. But as soon as Joe Average encodes sophisticated music (or if Joe Average is intolerant in the first place), he will get upset about the big files.
There are many reasons why I think --r3mix is not appropriate for a standard setting.
1. It has not been shown to be clearly better than 192kbps cbr.
2. It is not transparent to a large majority of people (let alone the audiophiles).
3. The maintainer of this switch is unwilling to listen to other people's thoughts and concerns.
4. Many of the compromises in quality that --r3mix makes are unacceptable in my opinion. Instead of actually trying to *fix* the problems you just see things like weakening hf accuracy, raising the ath curve, and using weak noise measuring to get lower bitrates.
So, if not all presets have to be VBR, I would suggest some ABR160-like setting as the standard preset. A well tuned 160ABR mode provides good enough quality for just casual listening through PC speakers anyway, and for Joe Average, it provides good enough quality in any case.
I don't really think this would fly personally. There are 2 camps of people that comprise the majority of mp3 listeners. The 128kbps camp, and the 192kbps camp. 160kbps abr appeals to neither of them.
Only... if the standard preset was to be ABR160, where would --r3mix go? It's not good enough for "extreme" IMO (that should be dm-standard), it should be something inbetween standard and xtreme, maybe a preset labelled "better" or something...
Well as I was stating above.. the new dm-standard will hopefully eliminate many of the remaining weaknesses (slow speed, larger file sizes). That would basically make --r3mix unnecessary in this situation I think, since the new xtreme or insane would replace probably what you currently think standard would be best suited for. Besides all of that, --r3mix apparently doesn't want a part of this anyway.
Dibrom's presets should be easy to accomodate - dm-standard would be "extreme", dm-xtreme would be... ummm... don't know, and dm-insane would be "insane".
It'd be best to just not really guess where they would work at since it is all about to change.
CBR presets should not be included, surely. That would completely destroy the sense of our mission to stop everybody from using it
I'm not so sure about this. I'm not advocating CBR, but the idea is to provide quality.. not just some technique which is more often used. As an example, --r3mix has not been proven to be superior to 192kbps even at a higher bitrate, yet on many occasions it will dip significantly lower in bitrate. Sometimes nearing 112kbps. I think in that situation it'd be pretty apparent which file would sound better, especially considering the weak ath curve and noise meaasuring.
Remember, all this is just my opinion. (I don't understand AT ALL why a "standard" setting would have to be transparent, BTW)
It should be transparent to the "majority", not necessarily to the audiophiles. The reason is because most of the common users are not going to want to spend the time to find the setting which really provides high quality results (which IMO --r3mix does not) so the standard setting should do this within reason.
First of all, this is exactly why I don't think it is the time to be making decisions about all of this. The new dm-standard actually uses vbr-mtrh now (yes I've moved it over to that) AND file sizes are going to be smaller, in addition to providing improved quality. I'm just not finished with all of this yet. Think "smaller, faster, better"
Well, if you are able to achieve this, then this is a problem solved. I was only concerned about the bitrate, based on the current --dm standard. If you are implementing MTRH and squeezing the size and it shows good quality, then it should definitely be used.
And there seems to be concensus after all that the -standard should target the 192 range and utilize MTRH speed. I never proposed anything else than just this.
Could you BTW release some pre-alpha compiles of your modifications? I am sure people would like to experiment with them and provide you with feedback on their performance?
Originally posted by cd-rw.org
And there seems to be concensus after all that the -standard should target the 192 range and utilize MTRH speed. I never proposed anything else than just this.
I'm not "targeting" any specific range. I'm just trying to get vbr to provide higher quality and basically be more "flexible" in its scalability depending on the difficulty of what it is encoding.
Could you BTW release some pre-alpha compiles of your modifications? I am sure people would like to experiment with them and provide you with feedback on their performance?
Sorry, but no. I've only just now switched over to mtrh, and the code I'm working on changes daily, and usually even hourly. It would be pointless for me to put something out now which would be obsolete in a few minutes. I'm still very much in the major tuning stages and I won't be releasing something until I know that it works the way I am intending it to in at least the majority of situations. I do still think that I'm relatively close to being able to release something, but I can't give any firm date.
Hi all,
My idea for 3 sub-groups would be something like this:
--preset-portable-LQ (96 abr?)
--preset-portable-standard (105 abr?)
--preset-portable-HQ (120 abr?)
--preset-casual-LQ (134 abr?)
--preset-casual-standard (164 abr?)
--preset-casual-HQ (176 abr?)
--preset-hifi-LQ (r3mix?)
--preset-hifi-standard (dm-standard?)
--preset-hifi-HQ (variation on dm-standard?)
--preset-hifi-extreme (dm-extreme?)
--preset-hifi-insane (dm-insane?)
-----------------------------------------
This would satisfy the different users who would opt for LAME and everyone can clearly identify thier user level. The recommendation in LAME instructions should be for users to attempt to encode with --preset-hifi-standard first and decide if they are comfortable with the bitrate. If the file is too large, then select a user preset which fits your level of interest. This is a wonderful preset solution I think.
I also think the instructions should stress that all presets have very high quality within the user level indicated compared to other mp3 encoders. IMO, the level of quality that approaches "CD-Quality" is dm-standard. At least from what the AQ-test indicates. The second round of AQ-tests may show otherwise due to Dibrom's alternate compile. May improve quality, may hurt it.
I'd encourage Roel to attempt to adjust his --r3mix preset in the hope to improve quality. Perhaps try --nsmsfix & Dibrom's upcoming short-block improvement? Couldn't hurt.
mp3
What the hell, maybe I'll take a whack at it...
I think mp3fan may be on to something - perhaps presets should be categorized by
what you want to do with them. i.e., if you want to put MP3 on your portable device, share it with friends, or archive it for your stereo / headphones. Something resembling this perhaps:
voice (40 CBR -mm)
stream (56 CBR)
portable (128 CBR)
portable-HQ (134 ABR)
share (164 ABR)
share-HQ (--r3mix)
archive (-dm-preset standard)
archive-HQ (-dm-preset extreme)
archive-madness (-dm-preset insane)
Greetings all.
The discussions about optimum settings and presets have made me think, and I've posted some of my thoughts at the r3mix forum. However, with Dibrom's latest developments, my comments seem even more pertinent, so I'd like to suggest them here.
I have a strong desire for the default lame behaviour at any bitrate to give the best possible quality. All the long recommended command lines are very useful, but when a user requests that lame encodes a file at 128kbps CBR, surely it should use the appropriate "best" settings by default? This must happen in a way which doesn't prevent more experienced users from tweaking and testing, and doesn't change the meaning of too many existing switches - but I'll come to that in a moment.
Also, Dibrom has proposed a way to interpolate between recommended command lines that seems very sensible. The suggested help.txt file seems to suggest that the dm-preset series will represent almost the best quality possible at any given time. This is in addition to Dibrom's tuned VBR presets.
So, if we agree that Dibrom's ideas for various presets give the best possible quality (with the acknowledgement that much of work upon the CBR and ABR presets/settings has been done by others), I think it is unhelpful to give these presets the nomenculature --dm-preset <whatever>, which is only described using lame --longhelp or lame --dm-preset help. Rather, I think that the presets offering the best quality which lame can acheive should take the command line form...
lame -cbr 128
lame -abr 192
etc etc
...where the user specifies the mode and the desired bitrate, and lame picks the most appropriate (highest quality) settings.
I'm not suggesting this to deny Dibrom his moment of fame, but to ensure that the best settings are used by the widest possible group of people. It's also the accepted path of development within lame - while settings or modules are experimental, the command line switches hint at the name of the author, to differentiate between the new and the existing. When a setting or module is accepted as best practice, it is anonymously incorporated into lame as default behaviour. I think it's time the recommended command lines (which are a long way away from current default behaviour!) are made the default via these new simple presets.
lame -mode <bitrate>
where mode= cbr, abr, or vbr.
cbr = bitrate specified exactly, quality varies
abr = bitrate specified approximately, quality varies slightly
vbr = equivalent quality specified exactly, bitrate varies
So that lame -vbr 192 gives you a VBR file with a quality similar to a 192kbps CBR file. OR a VBR setting which averages (overall!) approx 192kbps. This last point (the choice of meaning for the VBR presets) is debatable. See my post here:
http://66.96.216.160/cgi-bin/YaBB.pl?board...&num=1003648843 (http://66.96.216.160/cgi-bin/YaBB.pl?board=c&action=display&num=1003648843)
for more discussion.
Finally, I've talked repeatedly about "changing default behaviour" without "changing existing commands". This is possible because I think lame -h should say "use lame -mode <bitrate>" or whatever by default, so people use this by default. The existing commands remain unchanged, except that plain "lame" = "lame -cbr 128" not "lame -h -b128".
There are some disadvantages to this idea, but it has the following advantages:
1. You don't need to remember the name of a preset when encoding something out of the ordinary. On this form, I guess most people stick to dm-preset standard or xtreme or variants thereof, so don't worry or even think about the other settings. So why have to scratch your head to rember an obscure preset name when you need a 128kbps mp3 for mp3.com? Just pick the quality and/or bitrate you require, and specify as (in this case) -cbr 128 - and know that lame will do the best it can.
2. It doesn't break current lame behaviour. You can still use all existing command lines, but beginners will be encouraged to start from these presets. Best of all, these presets don't "look" like presets, so if lame -h says "use this setting" people will - you don't need a website to tell people!
3. It offers an easy bridge from CBR to ABR to VBR. By making the command lines look similar, people will be more tempted to use VBR. It also allows us to specify VBR quality is a semi meaningful way, without all the arguments about what is standard, xtreme etc, though I'd suggest named equivalents for some VBR values (see my other post).
Thoughts? comments? flames? Rather than just posting "it's a crap idea" please say why.
Cheers,
David.
P.S. of course people are free to develop and tune their own presets - but I'd suggest that any new better presets should replace default behaviour of the type lame -mode <bitrate> as soon as it's demonstrated to be superior. That's the point in a nutshell - these presets should be the default command line, and they should offer the best possible quality at any stage in development. It's little good tuning VBR new and nspsytune if everyone still uses VBR old and gpsycho!
Hi David,
I actually agree with you on almost all of this. There has been some discussion on the dev list about this too... here is my stance on the matter.
I very much think that LAME should be pushed in the direction of providing the highest quality possible at given bitrates. I think this should be made easy. I totally agree that long draw out command lines can be somewhat unproductive, especially when people don't really bother to test what they pick often times.
LAME should just "work" when you want to encode at a given bitrate. It should provide you with nearly the best quality possible and you shouldn't even have to think about it. The entire interface should be consistent.. etc.
However... currently there is still a lot in LAME that needs to be changed before this happens. On the dev list I have been proposing that the --dm-presets could totally replace the default presets sometime. At this point things could be renamed, the "dm" dropped, etc. I really don't care about all of that.
The problem is that this just isn't going to happen like that. We all (mostly the developers actually) need to decide upon the best route and then go in that direction. It needs to be an organized and continued effort.. not a fragmented and loosely organized one like much of the development in LAME (no offense to anyone).
I'm absolutely willing to work with people to arrive at that goal, but the one thing I don't think would be a good idea is just to shove the --dm-presets into the current --presets and then just have all these unorganized and inconsistent presets to where nobody would know which would be the appropriate one to use? Would you use "studio", "cd", "dm-preset standard"?? Which one? Etc..
So I agree with you on pretty much all of this, but it is going to take more time. I think that even now there can be more added to the --dm-presets (though not just thoughtlessly). Very low bitrate presets (<80kbps) could be added for example. Once all of that is in place though, I think it would be good to just replace the default set of presets entirely..
I definitely agree, those existing --preset switches should be kicked out. Most people would never use them, and they don't provide sufficient quality anyway (I guess?).
While we're at it, my suggestion to clean up LAME: Make sure all the changes also go into the DLL. Just about all newbies will use the LAME DLL, and the implementation of the DLL into most CD rippers is simply a mess.
<ot>
Hey I just had an idea, not even one of my usual silly ones . To make sure LAME is properly implemented in all those CD rippers, why not create something like a "LAME approved" or "LAME compatible" certificate or something? That would mean that
And no more. That would make any "LAME compatibility certified" ripper absolutely idiot-proof. There should also be a notice that if you want more advanced options, you should use the external encoder (with a link to the online LAME documentation that will exist in a "proper" form one of these days).
External encoder, another good point. For the external encoder, there should just be a blank field in which you enter the options - if you have the bitrate slider in addition to that, it's confusing.
I think that would mean great progress in our mission to make LAME more popular and user-friendly. What do you guys think of it?
</ot>
CU
Dominic
PS: I know the CD ripper programmers won't like the idea of re-coding the entire LAME config menu, but oh well, once it's done, they can be proud of a "LAME approved" CD ripper
Yes,
I think it's time for an overhaul in LAME in regards to "usage". Simplification is a must. My idea for user levels makes the most sense as far as I'm concerned. I haven't read many ideas in this thread that make useful sense to all levels of users except my idea. Presets aimed specifically at quality levels and user levels. That's as basic as it gets.
Sure, you can include something for CBR presets like: "--preset-CBR 128" and that preset should by default give the user the best commandline tested for each future compile. For now "--preset-CBR 128" can default to ff123's commandline.
I simply cannot see the point in calling anything "standard" unless you specify what level of user you're talking about. "standrard" to some people means "basic" or "average", certainly not words synonomous with "high quality" or "AQ". Labeling Dibrom's "stardard" VBR preset as "standard" without specifying a user level is irresponsible and confusing.
If anyone has an idea better than clearly identifying "user level" and then "quality level" afterwards, then post it. So far, I'm only reading posts that argue what "standard" should mean and that is clearly going to confuse people, not symplify the issue. A "user level" will clearly identify what quality level you're targeting before clarifying anything as "standard".
Understand guys? If there are going to be universal "LAME-certified" presets, then please keep it simple, but clear enough for all users to understand your intent. My idea addresses any confusion about quality settings in a direct, easy, and common sense way using generic terms for each preset so that even a dummy can get it right. Put that in your compile for furture "LAME-certified" programs and you can always change the command line to the newest "winner" with each compile without confusing any users. Each version will be static on it's presets, but can always be upgradable yet still compatible with "LAME-certified" programs.
mp3
I think 2Bedecided hit the spot - never thought about it that way really. That's a whole lot better idea than a big bunch of lo-fis, portables, casuals, hi-fis...
On the other hand: If we have this Joe Average, the Xing 128 user from Nashville, then if he would use LAME for some reason, he would just go for some of the LAME 128kbps modes. So this approach doesn't really push people to the "right" direction.
I didn't include the word "preset" in the syntax I suggested because I don't want newbies to know they're using presets! Let them just think that the Lame default behaviour is great, and they don't need to tweak it.
This prevents the next obvious question "what command line is this preset using" which is always followed by "Hmm, I'll just add --noshort --nores because it'll make it sound better". ;-)
"If we have this Joe Average, the Xing 128 user from Nashville" then I don't care what he does, because if he's from Nashville then he won't be encoding anything I want to listen to! ;-)
(any more gross over generalisations?)
Cheers,
David.
http://www.David.Robinson.org/ (http://www.David.Robinson.org/)
Originally posted by 2Bdecided
I didn't include the word "preset" in the syntax I suggested because I don't want newbies to know they're using presets! Let them just think that the Lame default behaviour is great, and they don't need to tweak it.
I totally agree with this. In encoders like MPC you have presets, but you don't actually really think of them as "presets" because they are just presented as default behavior. In LAME they are not.
I've actually just been spending a lot of time thinking about this lately, and I think I'm going to try to totally rewrite the frontend to LAME to work in this manner. I'm not sure whether or not anything like this will be accepted by default into the official LAME project (because it would break compatibility with frontends like razorlame), but if not I can always distribute my own version with much more simplified and highly tuned default settings. I'd also redo the help and remove access to the experimental options.. instead they would just be used when appropriate.
I'm basically talking about doing things like the way newer --dm-presets behave, but without separating them into presets. Instead you would just type like -vbr normal, -vbr high, -cbr 192, -abr 180, etc.. and it would just "do the right thing". There would still be certain options but they would be much more simplified, again sort of how the --dm-preset behave. For example you could specify -vbr normal -fast, or -cbr 192 -hq, etc. Of course LAME
does do some of this already, but much of the use of these switches is deprecated IMO. So by taking this approach, there would be no more having to think about all of these long and confusing command lines and no more having to worry about people using options which will degrade quality.
Wouldn't it be beneficial to commit most of these changes to lame directly? Disabling switches is clearly a no-no for the main version of lame, but improving the manual would help everyone, and the "presets that don't look like presets" don't clash with what's there already, will they?
I realise you can't just do what you like to lame (i.e. disabling experiment siwtches wouldn't help everyone!), so it would still be useful for you to distribute your own compile. However, I think it would be good to improve the general distribution of lame as much as possible - especially for the up-comming stable version.
Cheers,
David.
Originally posted by 2Bdecided
Wouldn't it be beneficial to commit most of these changes to lame directly? Disabling switches is clearly a no-no for the main version of lame, but improving the manual would help everyone, and the "presets that don't look like presets" don't clash with what's there already, will they?
Changes that radical to the frontend have probably 0% chance of making it into LAME. There's been discussion of this and similar issues lately on the dev list and I don't think it's going to happen. Rather than argue and waste time, I'll just do it myself. If someone wants to use it then, that's OK.
I realise you can't just do what you like to lame (i.e. disabling experiment siwtches wouldn't help everyone!), so it would still be useful for you to distribute your own compile. However, I think it would be good to improve the general distribution of lame as much as possible - especially for the up-comming stable version.
To be honest I don't feel like arguing many of these issues with the developers. Theres been too much arguing about all of these kinds of things lately and not much ever results from it. There is some opposition from some of the more core developers about how presets should be handled and how LAME should function in general in regards to what I think is trying to be achieved here. It makes more sense to me to just "get it done" in my own way at least so there is
something and then if people want to use it later, that's fine. I've been trying to point out many of the issues that I think need to be addressed in LAME in general and especially before the coming stable but there doesn't appear to be much support for some of these ideas really.. on the dev list that is. That's just my interpretation of the situation though..
Originally posted by Dibrom
Changes that radical to the frontend have probably 0% chance of making it into LAME. There's been discussion of this and similar issues lately on the dev list and I don't think it's going to happen. Rather than argue and waste time, I'll just do it myself. If someone wants to use it then, that's OK.
@#$%! dibrom, do you want to split lame? if all think that it's better to make something in such way why you can't agree with others? many people make lame, not only you.
our dispute is not time wasting, it's the only way how many people could do one business. nobody of us i think have all skills and have time to do this alone, so we must do this together and in piece
it is possibly to make some changes in lame after some discussion, just make such discussion and explain your point of view. this is the only way to make lame better.
you start to look like roel %( he also didn't want to see another people
what is bad 8(
But at times I have sympathy with Roel and/or Dibrom's way of doing things. Whilst it can be seen as being "pig headed" to just do your own thing, sometimes the discussion just goes no where. In that case, there is nothing wrong with saying "I created this for myself - I will release it so that others can use it if they want to. If you don't want to use it, then don't - but please don't hassle me to change it or destroy it because it's how I want it, and I don't have the time (and I never intended) to please everyone"
Sometimes it gets very tiresome to argue your point with everyone. However, sometimes it is necesary and useful. I guess it depends how much time you have, how easy it is to get others to accept your ideas, and how keen you are to see your ideas put into practice.
FWIW I haven't seen any discussion of presets and default behaviour on the mp3 encoder mailing list - is the dev list elsewhere?
Cheers,
David.
Originally posted by mitiok
@#$%! dibrom, do you want to split lame?
If that's what it takes, then yes.
if all think that it's better to make something in such way why you can't agree with others? many people make lame, not only you.
The problem is not
all people agree. Much of the online community in these forums are wanting something, they want simplicity, they want quality... and the default LAME behavior is not providing this satisfactorily. I was attempting to help out with this but much of what I think is necessary most of the developers are not interested in. For that manner, many of the developers who are making decisions about where LAME should be going in the future do not even participate here and even worse many of them don't really even
know what happens here. A perfect example is some of the comments Alexander recently made. And now he is working on a non-linear psymodel and he has not done listening tests (at least when he originally posted about it)... I've worked with it a bit and reported my results here on this board but I have not heard anything. Will this be yet another case where experimental work is added to LAME and then just kind of abandoned? I'm sorry but it seems to me that when the developers are not working with the users to get this stuff tuned correctly, then it is time to do something.
Now, this is not to say that some people aren't doing great work on this project... they are, and the ones that are improving things are also the ones that are participating this most in these communities. But the problem now is that the lack of organization and direction in the LAME project is having a negative impact on the community. Stable releases take too long, options which should be defaulted aren't. Many of the developers don't even understand the behavior of some of the code they work in regards to what it does to the sound quality in the end result! I think this is becoming a problem.
When you no longer really work on tuning your project yourself and you ignore those who
are doing this and are desperately trying to get you to pay attention... then what's the point anymore?
our dispute is not time wasting, it's the only way how many people could do one business. nobody of us i think have all skills and have time to do this alone, so we must do this together and in piece
I think you are missing the point. I've offered to do much of this (overhaul the frontend, make things "just work the right way" in regards to quality, etc).. but there is enough opposition to where I'm losing interest in attempting to "cooperate".
it is possibly to make some changes in lame after some discussion, just make such discussion and explain your point of view. this is the only way to make lame better.
In the recent discussion I explained my point of view on the presets and related matters about 5 or 6 different ways in long messages. Then after all of that I see short responses like "well I still think we need to do it this way".. after I've said what I can say and people respond in that manner, how else am I supposed to convince them? Sorry, but I can't wait forever.. I have other interests that I'd like to get to sooner or later, and if it looks like LAME is becoming a dead end as far as progress (at least in functionality and usability, technically LAME is still improving somewhat, but that isn't the issue here) then I might as well move on.
you start to look like roel %( he also didn't want to see another people
This is bullshit. Sorry, but I'm not Roel and I don't like being compared to him either. I'm trying to work on something here which would only have a positive impact. How is increased quality and ease of use going to make things worse? I'm not talking about forcing everyone to use a particular thing or changing the behavior of how their files are written.. I'm talking about consolidation, simplification, and enhancement (as far as quality goes). These things may not interest you, but according to the people in this thread and what many people apparently want judging by how many use my seperate presets... this is what they want as well.
If there is one thing that bothers me more than anything else, it is when people hold back progress for what I see as little reason. I think that is the case here, and I feel that was the case on the r3mix.net forum as well (discussions about increasing quality led to flamewars because people thought things were "good enough" and didn't need to be changed, etc.).
Anyway, what I decide to work on is my own business. If I want to extend LAME I can do just that. After all, its GPL and it's open source. I'm sorry but this response, especially the comparison to Roel, really pisses me off.
You'll probably dislike me immensly after reading all of this.. but I'm in this because I'm interested in pushing quality audio encoding further.. I'm interested in progress and the future. LAME has a lot of issues that need to be worked on.. but if people in control of the project refuse to show interest or are going to oppose that process, I might as well go elsewhere and do it on my own.
In closing, I'd like to ask you something Mitiok. Since nspsytune and many of these experimental settings were largely ignored by the developers until recent times and none of them were defaulted at all... would you have preferred that it stayed that way and that you would never have gotten the increased quality you likely are now? Or would you like to see the same progress there adopted more internally into the LAME project?
I know what I'd prefer.. and I think I know what many of the people on this board and even r3mix.net would prefer..
Note: Again I'd like to emphasize that the statements here do
NOT apply to all of the developers.. there has been some very good work from some people, but that does not change the fact that there are still some issues here which are becoming problems, and I think need to be changed. I'm talking in a more general sense about the way things should be progressing but they aren't.. and if someone is willing to do the lion's share of this, but people are opposing that...
Also, I understand that many people do not have the time it takes to improve LAME to the degree that is sometimes being discussed.. but other people are offering to do this instead.. so its not really a matter of that.
Originally posted by Dibrom
The problem is not all people agree. Much of the online community in these forums are wanting something, they want simplicity, they want quality... and the default LAME behavior is not providing this satisfactorily. I was attempting to help out with this but much of what I think is necessary most of the developers are not interested in. For that manner, many of the developers who are making decisions about where LAME should be going in the future do not even participate here and even worse many of them don't really even know what happens here.
lame is open source project. the main power of open projects is feedback from the users.
there is a chain developers-->users-->developers
as i understand the main goal of such forums are:
1) help for newbies
2) accomulation of users meanings and sending it back to developers
as i already told you, that would be nice if everyone could do some (may be very small) work for lame, it wold make lame better.
not developers must participate here, but you must send feedback to developers.
some of developers already told you that they don't have time and ask you to send links to them
developers can't quick make lame better if your make instead right chain such chain: developers-->users-->dibrom
you kill feedback
I think you are missing the point. I've offered to do much of this (overhaul the frontend, make things "just work the right way" in regards to quality, etc).. but there is enough opposition to where I'm losing interest in attempting to "cooperate".
lame already has a structure of presets, i f you want to make it better - great! thanks! but at this time as i see you make a bit another thing...
Sorry, but I can't wait forever.. I have other interests that I'd like to get to sooner or later, and if it looks like LAME is becoming a dead end as far as progress (at least in functionality and usability, technically LAME is still improving somewhat, but that isn't the issue here) then I might as well move on.
open projects can't live without feedback. that's funny that you think that lame is improving somewhat, as i see you don't want to improve lame at all: you make some sets of keys (thanks!) and now say us goodbye.....
well...... goodbye....... it's a pitty......will you merged you version in the future? may i ask you to do this? please.....
This is bullshit.
ah..... you say that my words are bullshit..... very nice 8(
Anyway, what I decide to work on is my own business. If I want to extend LAME I can do just that. After all, its GPL and it's open source.
yes, you can do it. but if you don't want to work inside lame project, your work will not help lame. so please if you stiill want to cut your work out of lame, could your merge interesting things back in the future?
btw don't forget that you must open your sourcecode.
I'm sorry but this response, especially the comparison to Roel, really pisses me off.
i may repeat this
You'll probably dislike me immensly after reading all of this.. but I'm in this because I'm interested in pushing quality audio encoding further.. I'm interested in progress and the future. LAME has a lot of issues that need to be worked on.. but if people in control of the project refuse to show interest or are going to oppose that process, I might as well go elsewhere and do it on my own.
give me url of your sourcecode and binaries, i'll make a link this may be will help developers of lame project in their work......
In closing, I'd like to ask you something Mitiok. Since nspsytune and many of these experimental settings were largely ignored by the developers until recent times and none of them were defaulted at all... would you have preferred that it stayed that way and that you would never have gotten the increased quality you likely are now? Or would you like to see the same progress there adopted more internally into the LAME project?
nspsytune is buggy. it produces great quality, but it's buggy. it would really great you you fix it and set it as default.
but people are opposing that...
you start to talk for the people..... nice..... roel made community that like --r3mix, you made community that like --dm-preset........
well..... it's a pitty.... lame didn't become faster after gogo's release, lame will not imrove his quality if you will not put your ego into @$$ and will not go on compromise and split your work
Originally posted by mitiok
not developers must participate here, but you must send feedback to developers.
some of developers already told you that they don't have time and ask you to send links to them
I've sent feedback to developers before. Sometimes stuff gets addressed, many times it does not. Simply posting on the dev list every time I have some sort of thought about LAME isn't going to change things. If they developers are interested in improving LAME they need to participate where the discussions about improvement are taking place. That is if they
really want to do this. When you develop a program it is your responsibility to make sure that you are "doing the right thing" for your users. Otherwise you shouldn't attempt to promote the idea that you are working for the good of others.
developers can't quick make lame better if your make instead right chain such chain: developers-->users-->dibrom
you kill feedback
Mitiok... what the hell are you talking about? Care to enlighten me on how I "kill feedback"? Lol.. I've probably reported more bugs to the developers in relation to quality than anyone else around here in the past few months. I'd sure as hell like to know how that equates to me "killing feedback"..
lame already has a structure of presets, i f you want to make it better - great! thanks! but at this time as i see you make a bit another thing...
I offered to make it better. I am making the --dm-presets to replace the --presets which will "make them better". This is how I'm doing it. Others are not interested.
For that matter.. what kind of response do you think I'd get if I just started radically changing the behavior of all of the default presets? I'll tell you.. there'd be even more of an uproar then there is now. I'd have to consult everyone about every little tiny change I'd like to make. No thanks.
open projects can't live without feedback. that's funny that you think that lame is improving somewhat, as i see you don't want to improve lame at all: you make some sets of keys (thanks!) and now say us goodbye.....
Heh that's a good one. Why am I having this conversation here? Because I am interested in improving LAME. Can you think of any other reason why I might spend so much time working on all of this stuff?
well...... goodbye....... it's a pitty......will you merged you version in the future? may i ask you to do this? please.....
Sure. All you have to do is get the developers to agree to these changes that people are wanting. But that isn't going to happen, not at the fundamental level that is being discussed here.
ah..... you say that my words are bullshit..... very nice 8(
You left out the part where you compared me to Roel -- "
>>you start to look like roel %( he also didn't want to see another people". Of course I said that was bullshit.
yes, you can do it. but if you don't want to work inside lame project, your work will not help lame. so please if you stiill want to cut your work out of lame, could your merge interesting things back in the future?
That's right. It won't help LAME, but it will sure as hell help the community. Which do you think I care more about? An implementation of a program, or the people who use that program?
btw don't forget that you must open your sourcecode.
I'm a little saddened that you would actually think there was a possibility that I wouldn't do that. Heh..
i may repeat this
k.. but note that if you continue to compare me to Roel, I'll continue to say that's bullshit. All you'll end up doing is pissing me off and causing me to dislike you. That's your choice.
give me url of your sourcecode and binaries, i'll make a link this may be will help developers of lame project in their work......
I'm not done yet, but rest assured any changes I make will be open to the public.
nspsytune is buggy. it produces great quality, but it's buggy. it would really great you you fix it and set it as default.
If nspsytune is buggy, then GPSYCHO is completely unstable. Nspsytune routinely offers higher quality than GPSYCHO when used correctly (which is all that needs to be handled internally). I'm not really sure what you mean by "fixing" nspsytune. You can't really "fix" it, you just improve it. It should be defaulted and improved upon. It's already better than GPSYCHO in almost all situations.
you start to talk for the people..... nice..... roel made community that like --r3mix, you made community that like --dm-preset........
You are quoting my words out of context. The "people" in question who are opposing these things are not the people in the community. They are the developers. I've worked for the benefit of the community when creating the --dm-presets, and once again this current effort is for the community. These are the "people" who I'm helping. Look around Mitiok.. look around this board and r3mix.net. Look at what people are asking for.. simplified presets, higher quality, improved default behavior. All you are looking at it from is the developers point of view. I'm looking at it from the communities side, but trying to implement that on the developmental side. Project Mayhem has nothing implicitly to do with --dm-preset, it has to do with striving for high quality audio in whatever form. It is not centered around a preset or my name.
well..... it's a pitty.... lame didn't become faster after gogo's release, lame will not imrove his quality if you will not put your ego into @$$ and will not go on compromise and split your work
Mitiok.. you don't get it. This isn't an issue of ego.. this is an issue of progress and trying to improve things.
I think I'll add a little example here. Though admittedly I don't know the whole story.. I have become aware of some interesting happenings in the LAME project not all that long ago. The Frank Klemm which is now working on MPC and doing such an excellent job was also once a part of the LAME project. He too wanted to improve many things, and in fact he actually did just that. As in that case there was opposition to much of what he was doing apparently, and eventually he was no longer a part of the project. Now when I look at what he is doing with mppenc and mppdec I can hardly believe how he could have been doing something "bad" to LAME. I don't understand how the project could let someone like this go.
I'm beginning to maybe understand though because I see a similar thing here. There is a push for higher quality and there are people willing to work with the developers to tune the codec in that direction, but there is much opposition.
Please don't give me shit about my decision to try and improve LAME in the areas I think needs to be improved Mitiok. At least I'd be working on something and there would be people getting some use out of it. I
have offered to do all of this within the context of the current LAME project but if people are not interested, what else should I do? Just shut up and do nothing? Or should I give up altogether and just forget about LAME..
Anyway, what I am
mostly talking about here is a change in the frontend of LAME.. a change in the default behavior. I don't know enough about LAME to make radical changes to the psymodel or anything like that, and I'm not actually sure I'd want to spend the amount of time it would take to learn all of that. The things I'm looking at maybe modifying here are unlikely to make it back into LAME because these are things the developers do not want to change.
@Dibrom: Maybe I haven't read the last bit of this thread thoroughly enough, but... when are you going to release your own compiles?
@mitiok: You emphasized several times yourself that LAME is an open source project - so why shouldn't Dibrom make these modifications and offer his own thing? I don't see the problem!
CU
Dominic
My 2 cents about all this discussion: (mainly addressed to Dibrom)
First, don't take all this on the personal level.
Lame is composed of two parts: a library and a front-ent (some in fact).
It seems to me that you're not happy with the most common frontend (lame.exe). You're right into the fact that this frontend is full of options that could be useless or quality damaging. You're also right when you say that some default options ar not the best. You want to change this.
Well, I think a lot of people would also like to change this. But the main problem is that we can't change everything. There are a huge number of users using previous versions, and it would cause a lot of troubles to remove some options.
But lame.exe is just a frontend to the lame library (like lame.dll is).
You want to change the front-end, but it doesn't seems that you want to change the library.
So why not creating a NEW front-end?
A more user-friendly one, a more easier one, a one with better default settings.
You could use the current lame front-end (lame.exe) and change it to create "easylame.exe" (or whatever you want).
This way you wouldn't have the annoyance of keeping compatibility of this interface with the current one.
I think it wouldn't be that hard. 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 really think it could be a nice thing, and I'm quite sure a lot of people would approve. This way it would also be easier to introduce all your drastic changes into the lame frontend. It could also be put into the Lame cvs, we just have to create a new directory into front-ends.
Originally posted by Gabriel
First, don't take all this on the personal level.
I agree. This discussion was not meant to be personal, and I hope that nobody takes my statements about the project personally. I just don't like being compared to other people in a negative manner simply because someone is dissatisified with what I am interested in doing.
Well, I think a lot of people would also like to change this. But the main problem is that we can't change everything. There are a huge number of users using previous versions, and it would cause a lot of troubles to remove some options.
Yes, I do actually understand this to a degree. 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..
I hope that in the future, extreme care is used when adding new options, especially experimental ones for this very scenario..
But lame.exe is just a frontend to the lame library (like lame.dll is).
You want to change the front-end, but it doesn't seems that you want to change the library.
Yes, mostly the frontend. I do think that certain things should be cleaned up in the library itself too though, but thats another matter...
So why not creating a NEW front-end?
A more user-friendly one, a more easier one, a one with better default settings.
This is what I'm looking at working on.
You could use the current lame front-end (lame.exe) and change it to create "easylame.exe" (or whatever you want).
This way you wouldn't have the annoyance of keeping compatibility of this interface with the current one.
I think it wouldn't be that hard. 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 really think it could be a nice thing, and I'm quite sure a lot of people would approve. This way it would also be easier to introduce all your drastic changes into the lame frontend. It could also be put into the Lame cvs, we just have to create a new directory into front-ends.
I guess the question is how much to associate such a new frontend with the existing LAME project. It's all an interesting thought.. guess we'll just have to see what happens.
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)
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.
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.
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.
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.
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.
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
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".
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?