Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Using insane settings with mp3 (Read 79434 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Using insane settings with mp3

Quote
Quote
A "beta" is  the new recommended version? How will you tell in future anyone not to use beta versions until they are final?
[a href="index.php?act=findpost&pid=331456"][{POST_SNAPBACK}][/a]

3.90 alpha was originally recommended, and nobody complained about it. The DON'T USE ALPHA/BETA attitude is very specific in recommendations (it didn't apply to 3.90, it still doesn't apply to mppenc, and nobody is worrying about using EAC which is/was/will be in alpha, pre-beta, sub-alpha or beta stage  ;) )
[a href="index.php?act=findpost&pid=331461"][{POST_SNAPBACK}][/a]


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.
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #1
Quote
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.
[{POST_SNAPBACK}][/a]

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

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

I found in the past even worse for 3.90.2 (partially but not fully solved with .3):
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=4687]http://www.hydrogenaudio.org/forums/index.php?showtopic=4687[/url]
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.

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

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

Quote
(This is in its own right an important argument for using a well-established encoder version.)

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

Using insane settings with mp3

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

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

Quote
(This is in its own right an important argument for using a well-established encoder version.)

Right. The problem is that 3.90.3 is performing worse than 3.97 on more than one sample.
[a href="index.php?act=findpost&pid=333512"][{POST_SNAPBACK}][/a]


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.
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #3
Quote
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.
[a href="index.php?act=findpost&pid=333587"][{POST_SNAPBACK}][/a]

--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.
Proverb for Paranoids: "If they can get you asking the wrong questions, they don't have to worry about answers."
-T. Pynchon (Gravity's Rainbow)

Using insane settings with mp3

Reply #4
Quote
Anyway avoiding any psy model is preferable that's why --athonly is attractive.

???

Using insane settings with mp3

Reply #5
Quote
Quote
Anyway avoiding any psy model is preferable that's why --athonly is attractive.

???
[a href="index.php?act=findpost&pid=333625"][{POST_SNAPBACK}][/a]

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?
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #6
Quote
Quote
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.
[a href="index.php?act=findpost&pid=333587"][{POST_SNAPBACK}][/a]

--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.
[a href="index.php?act=findpost&pid=333598"][{POST_SNAPBACK}][/a]

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.
lame3995o -Q1.7 --lowpass 17

 

Using insane settings with mp3

Reply #7
Quote
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.
I am arrogant and I can afford it because I deliver.

Using insane settings with mp3

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

Using insane settings with mp3

Reply #9
Quote
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.
[a href="index.php?act=findpost&pid=333691"][{POST_SNAPBACK}][/a]

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.
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #10
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.
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #11
Quote
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.
[a href="index.php?act=findpost&pid=333874"][{POST_SNAPBACK}][/a]

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.

Using insane settings with mp3

Reply #12
Quote
Finally I found some peace of mind regarding archive quality.
[a href="index.php?act=findpost&pid=333874"][{POST_SNAPBACK}][/a]



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.

Using insane settings with mp3

Reply #13
Quote
Would be a pity if 3.90.3 disappeared.
[a href="index.php?act=findpost&pid=333874"][{POST_SNAPBACK}][/a]

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.
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Using insane settings with mp3

Reply #14
Quote
Quote

Would be a pity if 3.90.3 disappeared.
[a href="index.php?act=findpost&pid=333874"][{POST_SNAPBACK}][/a]

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.[a href="index.php?act=findpost&pid=333897"][{POST_SNAPBACK}][/a]

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.
Code: [Select]
www.geocities.com/feedthedead/

/ot I vehemently deny being a pro-APE junkie 
"Something bothering you, Mister Spock?"

Using insane settings with mp3

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

Using insane settings with mp3

Reply #16
Quote
AFAIR, roberto said he would keep them on really rare wares
[a href="index.php?act=findpost&pid=333912"][{POST_SNAPBACK}][/a]


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.

Using insane settings with mp3

Reply #17
Quote
But I suspect John33 will be able to compile these special versions for 3.97 as soon as he has some time.
[a href="index.php?act=findpost&pid=333913"][{POST_SNAPBACK}][/a]

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

Using insane settings with mp3

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

Using insane settings with mp3

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

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.

Using insane settings with mp3

Reply #20
Quote
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.
[{POST_SNAPBACK}][/a]


Quote
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.
[a href="index.php?act=findpost&pid=333890"][{POST_SNAPBACK}][/a]

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):
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=39334]trumpet sample[/url].

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.
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #21
Quote
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).
[a href="index.php?act=findpost&pid=334018"][{POST_SNAPBACK}][/a]

Sorry, should be -b320 --athshort, not -b320 --athonly.
lame3995o -Q1.7 --lowpass 17

Using insane settings with mp3

Reply #22
Quote
wouldn't it be a challenge to have just one Lame option which is a pure quality option

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?

Using insane settings with mp3

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

Using insane settings with mp3

Reply #24
Quote
Quote
wouldn't it be a challenge to have just one Lame option which is a pure quality option

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?
[a href="index.php?act=findpost&pid=334033"][{POST_SNAPBACK}][/a]


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.
lame3995o -Q1.7 --lowpass 17