Though I greatly appreciate the advantages of 3.97beta I feel quite uncomfortable that 3.90.3 is running out of focus. 3.90.3 has some merits on its own especially regarding archiving quality. Personally I do not care about encoding differences which are very subtle at least to my ears, but what I really care about is about horror encodings even if they come up in rare situations. I found the worst example I ever heard in one of tha HA threads (a trumpet sample, from Don Ellis "Just One Of Those Things" as the FLAC comment says). This sample is very badly encoded with 3.96.1 and 3.97beta at aps, and is not even transparent at --preset insane).
3.90.3 behaves better at aps, and --alt-preset insane is transparent to my ears.

Using mp3 focussing on horror samples is a major issue IMO because mp3 has the great advantage compared to other formats that you can build up a hiqh quality archive which is usable without any transcoding on nearly any hardware player. But doing so having a very high degree of security a priori concerning quality is vital. (This is in its own right an important argument for using a well-established encoder version.)

While considering the beforementioned sample and how to prevent such horrible results I ran upon the --athonly option as it entirely removes the problem of artifacts created by the psy model. This surely requires using very high bitrates, but for the purpose of a universally usable high quality archive this isn't a restriction, and mobile HD players usally process mp3 files very efficiently even with high bitrates, so power drain is not too much of a problem either.

I did some abx testing with
Lame3.90.3 --alt-preset insane --athonly, and to my ears and for my samples they were transparent. Even
Lame3.90.3 -b224 --athonly results were very close to that.
Using --athonly is kind of way wavPack is going but on a widespread format basis.

As you sure have much better hearing than I have just in case you're interested: could you give --athonly a chance and figure out its merits and problems on some of your test samples? Highly appreciated are differences against
Lame3.90.3 --alt-preset insane.

DivX 3.11 SBC was also very good. It's not a reason to prefer it anymore to better version


I found in the past even worse for 3.90.2 (partially but not fully solved with .3):
http://www.hydrogenaudio.org/forums/index.php?showtopic=4687
People didn't switched back to --r3mix, but maintain the recommendation and tried to solve the problem. Using a four year old encoder just because one sample performed badly is like using again Windows 98 because XP has some issue.


If you need security, avoid lossy in general and especially MP3. Did you heard about pre-echo


Right. The problem is that 3.90.3 is performing worse than 3.97 on more than one sample.

Surely 3.97beta is to be preferred over older Lame versions as far as low to moderately high bitrates are concerned. I've read many favorable experiences about that on HA and can confirm this for abr104 according to my own listening test.

However there exists near to nothing of experience towards very high bitrates like cbr320 (presumably because of the fact that at such a bitrate differences between various encoder versions are usually negleglible). Testing in this case is practically restricted to horror samples, and fortunately not many such samples are known. The point is: I'm out for getting a universally usable mp3 archive not needing any transcoding any more. Very high bitrates are essential for that purpose. I'm quite aware of the fact that my just one sample doesn't say very much, but it's the only thing I know concerning different 3.90.3, 3.96.1 and 3.97beta behavior when using very high bitrates. And that's why I'm very curious to learn more on using athonly with cbr320. Not having to fear artefacts like pre-echo is quite challenging in case overall quality doesn't degrade in relevant way as my own experience suggests. Strange enough btw that 3.97beta behaves pretty bad when using rather simple cbr320 even it's just one sample. Maybe the nspsytune model is worse than gpsycho on very critical samples. Anyway avoiding any psy model is preferable that's why --athonly is attractive.

BTW I couldn't locate your horror sample: the target page is gone. I you like to you can send it to h.alb@web.de. How can I send you my sample in case you are interested? I don't remember the thread I got it from and searching in HA is no help unfortunately.

--athonly doesn't help anything with regard to pre-echo. pre-echo occurs because "short blocks" are too long in the MP3 format, no commandline option can change this. If you're so paraniod concerning quality, by all means create a lossless archive of your music and transcode to whatever codec and setting you feel like.

???

I remember your reply in the thread with the 'horror' trumpet sample. You just said nspsytune is going wild. So if the psy model is going wild at least at rare occasion it is attractive to me to try not to use one (hopefully compensated by using high bitrates). And as any vbr mechanism might be erraneous as well in rare situations it is a consequent behaviour to use plain cbr. No big choice as aps --athonly also leads to bitrates beyond 300kbps. So I end up with cbr320 --athonly.

The idea behind this is: avoid problems with the sophisticated stuff and use brute force (very high bitrates) for compensation. This might be driven further (i.e. by using only short blocks).
My admittedly limited listening tests say the idea is working, however my old ears are bad witnesses. So experiences and opinions on that are very much welcome.

As I said my interest is in getting a music archive of high quality (propability for bad encodings being a priori very close to zero), which I can use universally on hardware players without any transcoding. I don't like going lossless in the long run and transcode for hardware players (I do it at the moment).
mp3 is the best candidate for that, and I accept having to use high bitrates, which isn't a real problem even for mobile HD players.

What I do not understand with using 3.96.1 and 3.97beta on that trumpet sample is:
while brute force (-V0 --vbr-new and --preset insane) brings a remarkable relief in the quality issue, 3.90.3 behaves a lot better being transparent to me with --alt-preset insane. So I blame it all on the psy model. What's wrong with it? Strangely I could use --athonly with 3.97beta though it is not in the longhelp and though other ath related options lead to an error processing. 3.97beta's --athonly results are bad either. So is it something else?

You are right as I know now having read some stuff about mp3 methodoloy.
It is the very high bitrate which hopefully takes care of good quantization resolution and especially making pre-echo inaudible.

--athonly might help from bad behaviour of the psy model or psy model usage.

I don't like to have a lossless archive in the long run and having to transcode. That's what it's all about.

No, thats not what its about. A lossy encoder without problem-samples doesnt exist and for sure mp3 will never be it. You either go lossless or have to live with it. MP3 is only for "being good enough" - its not for archival and will never be.

If you prefer to not use any psymodel, then I would suggest you to NOT use lossy compression, or to use at least 500kbps.
320kbps with mp3 is not enough to be able to disable the psychoacoustic model.

Well, wavPack lossy works fine with 320kbps, as does OptimFrog DS.
So why not go a bit the same way as far as reasonable? Unfortunately most members seem to think this is not worth while.

You have brought all the machinery mp3 offers to a pefection as far as the quality bit rate ratio is concerned. I like 3.97's abr 104 mode suiting perfectly my needs on my mobile phone. And I admire -V3 --vbr-new quality. Real great for such a moderate bitrate.

But for now I'm in a different race: archive quality. Most people here on HA say 'archive quality and mp3 don't go together, so go lossless'. But I don't ask for perfection in archieving, I just want a very good (not perfect) quality, but I want it with as little exceptions as possible. The idea is: as the sophisticated machinery itself seems to cause problems, use a simpler machinery and accept very high bitrates and even mild regression from overall quality otherwise achieved with those high bitrates.
Simpler machinery means: use a more defensive mix of the machine parts and allow even for the abandoning of assumed critical parts and/or use other brands of parts which hopefully work in a more defensive way.

Common reasoning goes already a bit this way: Though vbr usually yields best quality given a certain (average) bitrates, everybody advices to use cbr320 if
you're out for optimum quality. The obvious part is mp3's bitrate limitation, but as a positive side effect you don't have to bother about problems with the vbr routines.

One step further: You've brought usage of the nspsytune model to perfection when targeting mp3 efficiency. However when targeting optimum quality at very high bitrates gpsycho might behave more defensive. At least this is what my limited experience with 3.90.3 compared to 3.96+ suggests.

More stuff on the roadmap imo considerable, as far as user options are concerned [and you sure have a lot more and presumably better possibilities under the hood]:
- use a simple and non-aggressive psy model
- use only short blocks (avoiding block switching in case this is a critical issue for the machinery)
- use athonly on short blocks (avoiding psy model problems on short blocks)
- use athonly (avoiding psy model problems at all).

If all these things are really some kind of oversimplification this would make abxing cbr320 more fun as differences should be rather easily audible.

Finally I found some peace of mind regarding archive quality.

I did some tests with 3.90.3 and 3.97a10 because of the availabiltity of ath and other switches. I wanted to bring more insight into the problem of th weird trumpet sample.
First I used cbr224 thus avoiding possible vbr problems while being rather easily able to identify problematic encodings.
I started with 3.97.
-b224 is real bad. In order to find out why I tried out --allshort, --athshort, --athonly, --notemp and --athtype. Out of these only --athonly and --athshort were relevant both bringing a comparable improvement. So the psy model or usage of it seem to be the problem.
With 3.90.3 cbr224 yields quite a good though not perfect quality, and --athshort and --athonly doesn't really improve things (maybe because bitrate is too low).
Then I relaxed the cbr restriction.
3.90.3 works fine with abr224 instead of cbr224.
But when going vbr things became strange with 3.90.3 too.
alt-preset extreme performed badly. Using encspot I found nspsytune was used.
V1 and V0 use gpsycho, but bit rate selection was far too low thus offering bad quality either.
alt-preset insane also uses nspsytune, so -b320 is preferrable.

So to me 3.90.3 is the best choice for archive quality. Using high bitrates and avoiding VBR is essential for this goal. -b320 -h for best quality.
Strange options are not necessary.
Would be a pity if 3.90.3 disappeared.

You better back up your claims with some test, or your stay here will be short. Trolling and breaking the TOS is not something we tolerate here easily.

Other than that, welcome to the forums.

I would like to see your ABX results as that would ease decisions, for some people, of switching to Lame 3.97b1 knowing that Lame 3.90.3 performs better at CBR 224 kbps instead of 256VBR kbps for your sample.

Yes, that would certainly be a pity. But it isn't going to dissapear, is it? As long as you keep the lame.exe of 3.90.3 on your harddrive you'll be able to keep on using it for years on end. True, it is not going to be developed any further but if I'm correct development on the 3.90 branch stopped years ago anyway.

I happened to be doing one of my very infrequent updates to my old page and could not bring myself to delete the old 3.90.3 compile with APE and CUE sheet handling. Hence, it will be there until a new incarnation arrives with those extras, "if and when it does." That is not up to me.
/ot I vehemently deny being a pro-APE junkie

AFAIR, roberto said he would keep them on really rare wares

Not the special compiles.

But I suspect John33 will be able to compile these special versions for 3.97 as soon as he has some time.

I'll happily listen to requests once it goes final.

Version 3.97b1 hasn't caused any problems for me - pretty good!

A few things I think the team could consider for the future are the ability to add additional/freeform metadata, bugfixed decoding and a redraft of the command-line help text and HTML documentation.

However, I understand perfectly how these aren't just things we can snap our fingers and have! It's obvious the developers have other things to concentrate on - and LAME is pretty darn good, in my opinion.

I'm just wondering what version 4 will be like...


Edit: Off-topic content moved to here.

One way of seeing things is that development did NOT stop but led to an improved LAME; namely 3.97(beta). Once 3.90 was released, development started on higher versions. The 3.90.x versions were mainly bug fixes, with no extra "development" going on.

OK. I didn't record yesterday's results, so I did a retest.

First let me give you the sample as I can't remember the thread I took it from:
Edited (new url going to uploads section):
trumpet sample.

I used 224 kbps just because abxing is easier. It is sufficient to show what's wrong and what are promising directions to go.

I started with 3.97a10 -b224: 10/10. This was easy.

Out of the weird options I tried I only retested --athshort which yesterday showed up to be the best candidate for a non-mainstream way to go for use with high bitrates for archiving purposes.
3.97a10 -b224 --athshort: 10/10, but a lot harder to achieve. Remarkable because of the bitrate is sure too low for real usage of --athshort.
BTW I found with all my abx listening tests that when abxing a sample which is hard but not impossible to abx for me there are always some trials I can spontaneously abx with success and others I have a lot of trouble with thinking I can't hear the difference. Wonder whether that' s just my problem.

I went over to 3.90.3 -b224: 6/10. This was pain. I'm sure people with better hearing can abx this much better (and within the first 5 trials I wasn't that bad: 4/5).

3.90.3 -abr 224 yesterday yielded results identical to -b224, but I left it over (did'nt want to repeat the pain). So just believe me or try on your own.

3.90.3 --alt-preset extreme: 9/10, easy (blame on me for the one gross error).
I suspect the bad result being due to nspsytune being used as encspot says.

3.90.3 -V0: 10/10, easyily achieved. Foobar says average bitrate is only 189 kbps, so I suspect it is the vbr mechanism which is inappropiate here.

I also tested 3.97b1 one more time because there are some differences to a10.

3.97b1 -b224: 9/10, easy. I really should take sufficient time for listening even in obvious situations.

3.97b1 -V0 --vbr-new: 10/10, easy.

As a result:

a) For this sample GPSYCHO is to be preferred over NSPSYTUNE.
The question is: does this mean it generally behaves in a more defensive way? In case it does it might be preferable for archiving purposes (whereas nspsytune might be preferable for low to moderately high bitrates). As the psy model controls quantisation quality as far as I know a defensively working psy model should be advantageous for archiving purposes.
So as for existing Lame encoders IMO 3.90.3 has a bias for archiving purposes (just don't use --alt-preset extreme or insane, as they use nspsytune).

b) The vbr machinery can have a negative effect on quality. While I believe 3.97 behaves much better in this respect the possibility of problems remains. For moderate bitrates vbr is very much of an advantage making high bitrates possible in situations when they're needed. But when it comes to archiving purposes high bitrates are necessary anyway and vbr brings the danger of choosing bitrate too low in some situations. So for archiving purposes it seems better not to use vbr.

c) abr might be an option for archival purposes because -b320 presumably is overkill in most suituations. Something like -abr 256 might be a more appropriate choice. Would like to know more about bitrate choice with abr in order to have a good feeling that bitrates too low are avoided to a very high degree.

d) Relaxing the psy model on short blocks is a promising way to go. I would be happy hearing of other peoples' listening tests using -b320 --athonly (with 3.90.3 or 3.97alpha as 3.97beta doesn't support that).
Using such an option is for testing purposes only. A better way to go is to do that under the hood. And it's not necessary to abandon the psy model at all. Using a defensive psy model in a defensive way might be the best solution.

e) All this (and other items often mentioned on HA) brings me to my ultimate wish:
Gabriel, wouldn't it be a challenge to have just one Lame option which is a pure quality option (the Vorbis way)?. Abandon all the --vbr-new/-old questions, cbr/abr/vbr modes (leaving them for evaluation purposes only in alpha versions). Within your mainly targeted moderate bitrate range presumed optimal options are settled.
For lower bitrates this might be work in progress (though imo below 100kbps mp3 is not of much use). The highest quality option should be reserved for archival purpose with a very high degree of constant good quality as the main goal and coding efficiency as the least important one. May be my findings can help going this way.

Sorry, should be -b320 --athshort, not -b320 --athonly.

This is called -Vx

What you are doing here is a generalization based on results regarding one (1) single sample. This is wrong. What if tomorrow you encode another sample that gives different results?

Exactly, make that at least 5 samples that show a trend. Otherwise 1 sample can be an exception rather than the rule.

I accept this as being a problem.
But where are the listening tests saying that 3.97b1 is preferable over 3.90.3 when targeting archive quality?
In case there exist some, please show them to me.

Or give me just one some sample showing 3.97b1 used in whatever way you like to be preferred over 3.90.3 -b320 -h?
In case you can't you're in a worse situation having not even one sample which I have.

Your results are so great targeting the moderately high bitrate range, but it seems that you are over-generalizing these results. Moreover I feel you and some members believe using the newest Lame version with its valuable improvements make it useless to think about a 4 year old version for being at the moment possibly superior for archival purposes.

So please give me a sample showing 3.97b1 used in whatever way you like being superior to 3.90.3 -b320 -h ! Seems like violating TOS by just claiming 3.97b1 is better for archival purposes than 3.90.3.

Of course they don't exist. No lossy encoders were ever tuned for such bitrate. 3.90 is not an exception. If you don't believe me, try to find listening tests showing that 3.90 is better than previous version.
But I could give at least one example of 3.90 --preset -insane being worse than Fraunhofer Fhg. I posted long time ago test and sample proving this (it was about harpsichord). Logically, Fhg would be better for archiving, wouldn' it




LAME 3.90.3 was not tuned for archiving purpose. Not true archiving at least. Try to archive castanets with MP3 if you have some doubts about this. There's lossless for archiving.


People don't have to prove the obvious. LAME 3.90 is 4 year old, and if you really think that this encoder is better than the most advanced LAME version YOU have to prove it. Not us. Currently, you're focusing on one sample. And making conclusions just on this sample. With one sample, I could easily conclude on WMA superiority over any LAME version! Conclusions would of course be premature. What matters is the overall quality. If you believe that 3.90.3 is superior to 3.97b1, and if you want to prove it: just make a listening test with ~15 samples, and if 3.90.3 appear to be better than 3.97b1 (it's a possibility we can't exclude), then it will be time to check 3.97 code and tunings.
But until this stage, stop annoy people. Thanks.

Lame is not suitable for archive quality, previous versions included.


Erhu.wav with "--freeformat -b 500"
(yes, this is a dumb, but still valid, answer)


I do not remember claiming anything similar, sorry.

Btw, if you want archival quality, I'd really suggest you to use something else than mp3.

I don't want to annoy people, so I give up (though I can't see a good argument in your writing - especially no such things are obvious).
I hoped it was clear what I mean according to my posts when I'm talking about archive quality. Tried to define it.

Hoped Gabriel would have taken the ball and adress this kind of archive quality in a future version. I too prefer using an actual version if it matches may needs. As I said I admire his work targeting the low to moderately high bitrate range. No argue about that. I use it on my mobile phone.

But for now I want to have an archive on my PC which I can use on my mobile HD player. I don't care much about bitrate being in the 300kbps range, I don't even ask for the best in overall quality, but I do want to have a high degree of security against real bad encodings.

And according to the admittedly limited information available and in case Lame development will not adress my needs (it strongly looks like that), I will use Lame3.90.3 -b320 -h or Lame3.90.3 -abr 256 or maybe Lame 3.90.3 -b320 -h --athshort according to further listening test.

Anyway I'd love to see you nice people out there keeping Lame for download on their homepage keeping version 3.90.3 as well. So glad about first replies in this direction. It's an alternative anyway.

When archiving you should have one goal in mind: transparent quality. This is a yes/no thing. The new Lame offers various quality levels via the -V switch. It is a tuning goal that a certain level will give you the same percieved quality on all samples. Unfortunately, as is true with every lossy encoder, it does not achieve this 100%. There will allways be exceptions. "trumpets" is such an exception. Now you have found a way to compensate for this very special sample, but what you are doing will break countless other samples. Raising the bitrate will not be able to fully compensate the immense bitrate savings that the psymodel provides. You are stuck at max 320kbps.

There is no zero-artifact-guarantee, no matter what bitrate or how simple your lossy encoder is. What you've been saying is that you would accept the quality level provided for example by preset standard but invest a higher bitrate to have less artifacts. This is what preset extreme or insane give you, but the extra bits are spent in a way as to maximize the number of samples that will become transparent (to the best of our knowledge).


I am certain that 3.90.3 -b320 -h will give you lower quality than 3.97 -V 2 on a number of samples. You suggested command line does not profit from the tuning that was done for the old alt-presets and which are default in 3.97.

Do you have such samples? I'd like to share impression.

BTW for the moment it's 3.90.3 -abr 256 -h -Y which is most promising to me.
As nobody takes up the --athshort idea I will not continue it either trying to stay on rather safe ground.

I am sure that you have been using 3.90.3 because, in some way, or another, HydrogenAudio told you to (or told someone else, then they told you, like some "scene groups"). Now HA, with the blessing from the very same people that created and tuned 3.90.3, has moved on to a newer, faster, better version. Don't you trust them no more?

I think you are wasting your time. You said that you use lower-bitrate encodes for your mobile phone... that means that you either transcode or encode the same files twice... Why don't you use something else for archiving and MP3 for your portabe uses? That way you could get what you want, and maybe you could stop trying to outsmart the developers of LAME.

Really... 3.90.3 was released in early 2003, but that was only the addition of the z switch. 3.90.2 had been around since much earlier. A lot has changed since then. Somehow I think the "beta" part is what scares you.

3.90.x has been around since late 2001...

anyways, for people who have been using 3.90.x --aps or --ape there is less of a reason to adopt 3.97 as tests may be insufficient for them to switch. i don't think "scared" is even the issue, more like "unconvinced" - that is an entirely different problem to address.

everyone accepts the adoption of lame at low bitrates (<160), that shouldn't be an issue.


later

so this type of people trusted the devs that created 3.90.x, but they think after that, the devs got dumber (i bet the devs got smarter in those 4 years)

My first encodings were with 3.96.1 for a flash player of mediocre quality I got as a n Xmas present. At that time I just knew 'Lame is good' and downloaded the latest version I could find.
When this player was broken, and when I bought a new mobile phone I decided to buy one with an integreated music player. I came up with a Nokia 6230 which brought me to the choice of using either AAC or MP3 and made me dig a bit deeper. So I came to the www.audiohq.de page from there to HA. At that time Lame 3.97alpha was out and according to the experiences I read of and because of the mature alpha state (it was a10 then) I was keen about using it prefering it over iTunes' respectable aac encoder because of mp3's universal format. I figured out what was the lowest bitrate setting while maintaining good-enough quality for me ans my phone and came up with abr 104. This perfectly suits my needs in this context. I ripped and encoded my favorite songs and don't plan ever to reencode no matter 3.97beta, 3.97final, 3.98 or whatsoever. So this is static.
For better listening quality I now own an iRiver H140 which gives me a lot of choices for the codecs. But as before mp3 is most attractive to me. And it's just a few weeks ago that I ran upon the ugly trumpet sample, and playing around with it I came upon 3.90.3. Never considered it seriously before though it was the offiicially recommended version when I came to HA. But now I see it in a different light. I am totally satisfied with mp3's overall quality even with moderate high bitrates no matter 3.90.3, 3.96.1, 3.97 or whatsoever. I don't have the golden ears. But I do want to bring the danger of gusty encodings which I can hear to a minimum.
I'd like very much if this goal would be accepted in current Lame development, but if it is not Lame 3.90.3 -abr 256 -h -Y is the most attractive choice to me.

So much for my background.

Pity that most of the replies on my findings don't bring a lot of substance to the issue.

Just do a listening to test that pits 3.97b1 against 3.90.3 with a good range of samples from your favourite music.

Archiving with MP3 is really not possible I'm afraid. I think you are a perfect candidate for lossless.

Seems rather harsh... We are speaking of "perceptual encoders" here. It's all opinion. If the opinion of the masses differs from mine, I will respect the masses. Then trust my own ears.

I did that using samples from my own archive and some of the problematic samples from ff123' page.
I did it a while ago (using 3.90.3 and 3.97a10) with preset extreme and insane. However this didn't give the answer. In none of the cases I could securely abx differences against the original. That's why I don't worry about overall quality. And that's why I don't care much about mildly problematic cases (to me) and focus on seriously problematic cases.
May be I should retest as I am more experienced now, but I don't really expect things have changed. My hearing just isn't good enough.

It's not about 3.90.3 against 3.97 as all these replies suggest (making replies so emotional).
I've proved that 3.90.3 --alt-preset extreme, --alt-preset insane, -V1 and -V0 aren't good either for the trumpet sample.

It's about using abr or cbr for security (not version-related), and it's about using gpsycho (unfortunately not available in 3.96+) (or better) instead of npsytune.
At the farer edge it's about handling short blocks in a most consistently safe way by using very high bitrates and possibly sacrifying overall quality to a certain extent.

he is asking you to backup your ears claim with an double blind test ...

see post #136.

don't shoot the messenger (i haven't used lame for 2+ years)


later

I'm a bit bewildered by people talking about archiving and lossy compression... what's the point? I mean, you could get more or less transparent sound from modern MP3, AAC or Vorbis, but you cannot do much with it... any kind of transcoding will make is less transparent.

In my mind, only lossless codecs can be used to archive music. Then you would have an archive that you can depend on for the future. You would have the source available. And with todays priced for disk storage, it's really quite cheap too. Relatively speaking.

That's why I don't want to transcode but want a universally usable archive and that's why mp3 is most attractive. I don't ask for real archive quality but for a high degree of security against bad encodings while maintaining high (not necessarily 'best') overall quality and accept very high bitrates.

The problem is that there is not a lot of substance to your findings either. You have found exactly one sample where your tweakings do better than defaults (a problem which you have already recognized). This doesn't guarantee you the safety which you are trying to find here:

Extrapolating results from just one sample is completely invalid and I doubt there would be any developer that would tweak a codec on just one sample.

It is your job to find more samples that exhibit the same behaviour, but instead of doing this you keep repeating your findings (or finding, I guess) and at the same time ask the LAME developers to do accommodate for that one sample and try to turn their codec into something they don't think it can possibly do. Do you really not see that this is not how things work?

Also keep in mind that your definition of archiving is a bit different from the general accepted one here. You seem to have a very unique use for a lossy encoder.

@halb27

try with this command line, it was developped to get maximum transparency. The sound will be lush and developped.

what the hell? is that the command line that produces the worst possible sound?

Nah, that should be

This would minimize the size, while keeping all frequencies in "true stereo"! Short blocks keep the clarity and detail, while with CBR, you can predict the file size easily!

Edit: Surprisingly, stuff encoded with it were still listenable. Testament to the true ability of lame.

I think/hope that post was in jest.

I think, rather, it was in frustrated sarcasm.

Regards,
Madrigal

I think you may be right.