Just use FLAC. What's the problem with transcoding from FLAC to MP3? It's not too difficult to convert your CDs to FLAC. Just do as much as you can per day, and eventually your collection would be converted to FLAC. I mean, that's what I'm doing right now to my own music collection, and I have college courses to study for too, so I don't see what your problem is.

Also, I use dbpowerAMP to convert my FLAC files to MP3s (using LAME 3.97b2, of course ), and it doesn't take me too long to do it (maybe a good hour or two). After you rip all of your music to FLAC, just run dbpowerAMP or foobar2000 to convert FLAC to MP3. Sure, it may take a long while, but that's what going out is for (unless your job involves WORKING on that actual computer), which means that you should break up the job over several days and over several album folders.

To sum it all up, I'm trying to point out that it IS realistically possible to transcode from FLAC to MP3 with little trouble.

Not out yet.

You are right. I'm sorry I was talking about archive quality when thinking about the way I want to use my archive. This confused people (though I explained it).

I'm also sorry for having started kind of a 3.90.3 against 3.97 war as shown by the replies. This was not intended.

As for the just one sample problem however imo this is not just one sample among many others, but one with two outstanding properties:

a) it is easily audible even for the unexperienced like me and even with very high bitrates when using
- Lame 3.90.3's whatever --alt-preset strategy
- Lame 3.90.3's whatsever vbr mode
- Lame 3.96.1's whatever usage (let's not talk about freeformat please)
- Lame 3.97's whatever usage (let's not talk about freeformat please)
The essentials of this was shown in post #136, I figured out a lot more usage modes before which are not shown in #136, and everybody can easily confirm (or disagree with) this statement using the sample being provided in #136.

b) Bad encodings from a) are at least in the first place not because of the sample being problematic but because the encoders' machinery is going wild (Gabriel's words). As for the best knowledge up to now this is because of nspystune usage (and as far as at lest 3.90.3 is concerned bad vbr behavior).
If machinery is going wild (one case is sufficient to prove that) this is to me much of a concern. I must fear it will go wild in other cases too - and wild can mean 'very wild' according to experience.

So it's not primarily about usage of Lame 3.90.3 --abr 256 -h -Y or similar (this just matches my needs most at the moment). I'm perfectly happy with Lame 3.97b1's -V3 --vbr-new overall quality encluding common artefact behavior (I don't need a perfect archive quality as obtained going lossless), but I want it with no fear for wild machinery with real bad results. I'd like to have this quality with a safe machine. I'm willing to pay the price (high bitrates). The race here on HA is for optimum quality and optimum efficiency. In this my needs are really different as I don't care about efficiency at all. (I'm just running a test on my new iRiver H140 with a repeatedly played abr 256 track. Actually it has played for 22.5 hours - quite a miracle to me as the manual says battery life is approx. 16h mith mp3). Disk space is no problem anyway.

So let's stop the discussion. Shouldn't go on forever.

Thanks to all of the repliers who tried to help me on. (Going lossless for instance is sure and still an interesting option - as is vorbis or wavPack lossy. But as my demands are not that high and as I love mp3's universal usability I just would prefer a safe and good while not perfect mp3 archive).

@ halb27

I think you're full of s**t. Rambling on about stuff you don't seen to have a clue about and guessing to the left and to the right about possible solutions to problems that really don't exist. AFAIK you never posted any ABX results, you were just talking about them.

see post #136.

Exactly my point, you never showed any ABX logs, you only mentioned your results. You never said anything about how you went about doing them.

I used foobar's v0.9beta10's abx util.
If you mean by abx log the result of every single trial I really didn't record that.
If this is the usual procedure here on HA, sorry I didn't record that. Wasn't aware of that (and am pretty sure having seen abx results on HA with just the final result as I did).

I will not repeat the test just for arguing. Obviously you don't like my opinion. And certainly my opinion is just one possible attitude towards the facts.
If you're really out for the result you can try out on your own. You don't beleive me anyway. ABXing is easy in this case at least for the bad behaving encoder (setting)s.

Gah, you got me there, Drenholm.

What facts?
You haven't stated any facts, just assumptions you make based on some misconceptions about how LAME (and psychoaccoustic audiocoding in general) works.

If you support your claims with hard facts (ABX results prooving that you can tell apart your settings from the original and a VBR encode), this discussion might go on, until then you are violating TOS#8.

Well, he has provided proper ABX results. Don't be that hard on him. ABX logs don't mean anything (can be falsified as easily), and are usually not required. The final result is OK.

I understand what he says. He wants a max. quality MP3 at max bitrate, and it seems he prefers old 3.90.3 for that. The thing is, does his results hold for other problematic samples?

ABXing that sample with 3.97b1 -b 320 is doable...

I couldn't abx it with 3.90.3 api, but the sample was highly annoying to me so I lost focus maybe.

I have to say though, I didn't find the difference i heard disturbing. But again, its not my kinda music...

Thank you so much.

Nobody needs to share what I'm targeting at, and nobody needs to share my opionion.
But I didn't think it's so hard to understand what I'm out for.

And what you say is exactly what I'm interested in. Primarily I would like to have no problem with current Lame version, but if that's not what I can get I would like to share experience on the second best solution for my purpose: Lame 3.90.3 -b320 -h or abr usage with slightly released bitrate requirement.

Thanks for your support. Highly appreciated. I found 3.90.3 api very hard to abx, much worse than 3.97b1 api, but it was possible. 3.90.3 -b320 -h however was absolutely transparent to me.

Please don't nobody kill me for not providing abx results right now. I did abx, and if someone is interested I can do a retest. Sceptical people however might better do the test on their own.

I did similar experiments with the trumpets.wav test sample (the one at the PCABX page). I experienced similar things with 3.90.x:

- VBR modes were easily ABXable (--aps, --ape)
- I couldn't ABX --api.
- High bitrate ABR modes (--alt-preset 224, IIRC) sounded better than mentioned VBR modes in this sample, but worse in other samples, in regards to pre-echo.

So at last I kept using --aps.

I haven't tried 3.97.

Can you give me your pre-echo examples please?

abr 224 in post #136 was for evaluation purpose only (easy abxing), for production I plan to use a higher bitrate (at least --abr 256 -h, but maybe -b 320 -h).
BTW is --alt-preset 224 identical to --abr 224 with 3.90.3? After all I'm pretty sceptical about --alt-preset?

You are right, 3.90.3 does perform better on this sample than 3.97. But as others have said, with a lossy compression you can never be 100% safe, you'd have to use lossless. And using cbr 320 kbps with mp3 doesn't make much sense. When you use a lossy compression, you obviously do that to save space. And 320kbps CBR is for most of the time just an inefficient way of using mp3.

What I'm trying to say is that with lossy compression you have to make a compromise somewhere. And instead of using an obsolete version because of ONE sample, we should rather try to find out why that one sample performs so badly. And now that we have that sample, hopefully the developers can look at it and try to fix it.

That's what I mostly hope for.

halb27: Now that you have found nice setting for you, why don't you try to encode some more test samples with it.

I did and still do. But nothing I can talk about. Everything is fine so far, also with some of ff123' and other problematic samples I know.

Unfortunately this doesn't mean a lot. I'm afraid it says more about my listening abilities than about codecs' behavior. And I'm only interested in using high bitrates cause I don't care at all about coding efficiency. This doesn't make things easier.
That's why I ask for support.
I'm afraid (or shall I say glad?) I can only hear very problematic samples.

Like posted before i tried an old sample "Birds" and today "Sophia" Both have noise added. In Sophia in the beginning and in Birds mostly during she sings become.
They weren´t perfect in 3.90.3 but better in 3.96. Out of curiosity i tried Spahm cause i tried it on the 3.90.3 <-> 3.96 comparison tests performed over here. This sample also degraded from 3.96.
I don´t have any time to test more, maybe sunday evening.

Which way did you use 3.90.3 and 3.96?

Ups! aps versus V2! Have to go now...

Thanks a lot.
But this is not what I'm targeting at. With aps I would not consider to use 3.90.3. I have no doubt Gabriel has done a very good job improving Lame behavior at this bitrate range and below.
Please no 3.90.3 vs. 3.97 comparison in it's own right (at least not for me). For me it's plain gpsycho vs. nspsytune and cbr (or abr) vs. vbr.
De facto this means 3.90.3 abr or cbr (no --alt-preset !) vs. 3.97 whatsoever.
And that's useful only with very high bitrate.
So for a precise statement: I'd welcome most 3.90.3 -b320 -h -Y against 3.97 api or whatever you like.
--abr 256 (or more) -h -Y against 3.97 -V0 --vbr-new or whatever you like is welcome too.
And for the most couragous: 3.90.3 -b320 -h -Y --athshort vs. 3.97 whatever you like is imo a very interesting question.

If you have the time your tests are very much welcome.

This morning in bed I found a good description for what my target is about. Obviously I was not able to state it quite clearly before. It's about

optimizing worst case behavior of encoders

And that's why the trumpet sample is an important sample.
Any other sample adequate for this purpose is highly welcome of course, as is any result concerning this issue.
(And that's why it might be interesting to use --athshort with 3.90.3 for evaluation purposes. Among the switches available to the user it is the most promising one that might improve worst case behavior. It is not meant for production purposes, but maybe it yields results that show promising ways to go).

As for the Lame devs:
I am afraid the problem in 3.97 is more one of a conceptual issue than one of technical details (glad if I'm wrong). In the quality-and-efficieny-race they have done such a good job in improvement nspsytune usage so they won't give it up just for this discussion (initiated by a new member moreover). If I were them I wouldn't consider that either. It would be unwise.
It can be only useful if considering worst case behavior leads to general improvement in nspsytune usage. I'm not very optimistic about that.
As long as they have more good ideas in the quality-and-efficiency race (I'm sure they have) they won't take efforts in this direction. This should be considered as good.

But what about this (maybe way too early right now):
Why not merry the best of the worlds which of course means going the 3.97 way for most of the usage modes?
This brings me back to my wish for quality options, call them Q0 to Q9 for the moment. Q2 to Q6 could be identical to 3.97's V2 to V6. I think this can be called 'best' according to settled experience. For Q0 it might be 3.90.3's -b320 -h -Y results (or something improved upon), for Q1 it might be 3.90.3's --abr 256 -h -Y results (or something considered better, maybe 3.97's -V0 --vbr-new). For quality Q7 and below AFAIK not much is settled yet. Of course it should be 3.97, but which way? May be Vx, but that's not for sure (just my opinion: I personally prefer --abr 104 over -V7 for instance).

This shows another advantage of Qx in it's own right (no matter the worst case considerations). It brings the freedom of adressing just quality and nothing else. The way to achieve this quality is an implementation issue to be solved under the hood. Vx doesn't do this alone for the fact that it implies vbr. Any a priori implication is not a good idea and affects the quality level idea. cbr320 as the best quality solution does not match the Vx scheme. And quality level achieved by V3 right now was achieved only with V2 not long ago (roughly speaking). Quality level should be quality level. Improvements in encoding implementation show up as lower bitrate usage (execept for the highest quality level Q0 [maybe Q1 too] where it solely means quality increase).

As for bringing in 3.90.3's -b320 -h -Y behavior I can imagine this does not require extremely high effort. I assume 3.90.3 source code is still available. Of course there are better ways to go but for the moment this seems to be a rather cheap solution which matches the issues adressed here.

I'm sure 3.90.3 had problems which would occur more frequently than 3.97 beta or else Hydrogenaudio would not have made the decision to change the recommended version. Surely, whether degradation has occured in some cases, much work for the better has been done in the years since 3.90.3?

As far as the recommendation is concerned I'm convinced nobody thought of worst case behavior. This was not in the focus. The focus here has always been on quality and efficiency. As far as this is concerned there is no doubt 3.97 is best.
My hypothesis is: for highest quality (320 kbps or slightly less) you shouldn't use 3.97 in it's current state, you're better off using 3.90.3 -b320 -h -Y (or --abr 256 [or more] -h -Y for slightly released quality requirements). But the best would be to have this behavior (or a better one) in the current version.

only a little sidenote: can you abx any difference in your ABR commandline using -Y and without -Y?

Your claims for highest-quality MP3s will be hard to validate given that, from what I have read, few people will be able to discern any 256-320kbps encode from another. And if you can on special-case samples, bear in mind that they do not represent general source material.

I just tried. I couldn't (4/10).

Don't care too much about these switches. I just use them on a regular basis because according to lame version and usage they're sometime defaulted and sometimes not. I think -h is nothing to be warried about, and -Y is a more or less efficient way to handle the sfb21 issue (positive especially when optimizing worst case behavior). On the downside -Y shouldn't be able to harm too much especially with 3.90.3 as it is said to be used there in a rather defensive way.

I think -Y does not do anything when used with CBR/ABR, so the files with and without -Y should be bit-identical - thus impossible to ABX

This is exactly the point. There is a reason why we don't see 320 kbps listening tests here and nobody came up so far and showed me a sample where 3.90.3 -b320 -h -Y behaves badly (badly meaning being easily abxable). For a good mp3 encoder when using 320kbps there shouldn't exist easily abxable samples.
Now that we have one for 3.97 (being incredible bad with V3 or so btw) this shows that something is wrong with the machinery. And everything points towards nspsytune usage (things are bad too with 3.90.3 when nspsytune is used).

Just my point about different default bahaviour which I don't like to learn by heart. If I had it would have saved me some pain with the test.

I am not sure if it's a good idea to test the newest recommended compile against the old ones. I think it's more important to check the compile, if it works with the music or not and if not, then compare between compiles and maybe found the problem. There is too many "recommended" compiles. Compiles should be tested more clearly. There should be a way, how to easily to use people's ears to test it.

Yes but I'm sure the sample in question does not reflect typical behaviour for this version of LAME:

Everybody is comparing the quality of 3.97b or any other version to 3.90.3, i was just wondering why can't you just use the --alt presets that are in 3.90.3 and just make the encoding speed faster.

If this has already been answered or is just plain stupid then please just disregard my post.

I don't think so. Due to the nature of the MP3 algorithm, there will always be abxable samples at 320 kbs. I'm more interested in how Lame performs in the "almost always transparent" range, i.e. -V2 or --aps. Most samples that are a problem in that range give problems at higher bitrates also.

In the -V2 range I'm very happy with the perfomance of the newest Lame versions.

So am I. But unfortunately different to you and obviously most (if not all) members here who are focusing on the -V2 range I focus on the 320 kbps range. It's just because with my new iRiver H140 with it's 40 GB HD I don't have to worry about disc space and battery drain (proved by test) when using best quality mp3. So why shan't I go for best quality mp3 and disregard effenciency? I'm limited to 320 kbps anyway.

I understand the reasoning of many replies here: 3.97 is proven best in the -V2 range, so if I use it in the 320 kbps I will get 3.97's benefits too. And there will always be problematic samples. This is typical reasoning totally adequate for the -V2 range extended to 320 kbps. That's why guru said 'you don't have to proof the obvious'. And as most of you are out for -V2 or so it seems difficult to see the point in my demands (or I am not able to explain it well).

While I respect this reasoning it's not the only way to consider things. Let's talk about real abx experience in the 320 kbps range. If I want to learn about other people's experience on that I'm in the desert. AFAIK nobody ever has done a listening test. The reason is obvious. Put two well (not necessarily equally well) respected encoders at that bitrate range abxing against each other is hard to do. Brute force does matter (of course not the whole story).

So for the time I didn't know the trumpet sample and for the choice between 3.90.3 and 3.97 there is no real experience basis for prefering one over the other. Common wisdom of course says I should use the latest version. (The argumentation is artificial, it's just to make things clear. At that time I never thought of using 3.90.3). According to my personal listening experience I was happy with 3.97 anyway.
But now that the trumpet sample is out the world has changed (at least to me). While in the world of typical -V2 reasoning this is not of much concern (just one sample, there are many others that bring problems), in the 320 kbps world it is. Though this world is not perfect this is the first real experience with a sample being easily abxable with 3.97. 3.90.3 -b320 -h however is OK.
And of course I have to fear: if it happens here it will happen in other cases too.
Sure I don't have security with 3.90.3. But deciding on real experience (everybody tries to do that) it means I have to use 3.90.3 -b320 -h.
Of course the best way were to fix 3.97. But my hope is getting smaller each day.

For improving experience on 320 kbps behavior any easily abxable sample is highly welcome, no matter if 3.90.3 or 3.97 is concerned.
If you have one please share it.

Fixing the problem sure is the best way to go. Unfortunately there haven't been any reactions from the Lame devs so far considering this.

One more question: 3.90.3 -b 320 defaults to stereo while 3.97 -b 320 defaults to joint stereo. Have you tested 3.97 -b 320 -m s ? Maybe it is not a nspsytune problem after all as you suspect but a (rare) joint stereo problem? I doubt it, but who knows... If -m s gives an improvement, you can at least safely use Lame 3.97 and benefit from the tuning that went into nspsytune instead of fooling around with the outdated gpsycho.

I just did the test with 3.97 -b320 -m s: 10/10. However I had the impression it was a bit harder to abx than it was with former 3.97 abxing. Maybe I'm just tired right now.
Anyway thanks for the information about 3.90.3 -b 320's default bahavior on stereo mode. Didn't know that. Don't like that. But don't want to change default behavior too much (-h -Y having always been the utmost to me except for the experimental --athshort).

-b320 of 3.90.3 was not tuned, that is a simple basic switch !
This is opposite to -b 320 of of 3.97b1, which should be optimized for 320k, ie. the former alt-preset insane.
The point about using 3.90.3 are only the alt-presets, in this case --alt-preset insane.
Fyi, alt-preset insane was the only setting, which applied --ns-safejoint, a joint stereo mode, but with a safe ms-fix value, that means higher percentage of stereo frames, less percentage of ms (mid/side) frames in comparison with lower (alt)preset modes

Thank you for the information.
Makes 3.90.3 api promising again though I was able to abx (becoming a bit unsecure about that right now also for the reason that stephanV in his test was not able to abx 3.90.3 api). I will redo the test tomorrow. Hope I didn't mix things up.
For the case my memory is allright: can I apply -m j --nssafejoint to basic -b usage achieving the same stereo mode usage as with api?

ConCave, the --alt-presets are the -V settings. Any changes that have occured are because of development on said settings. From I think it was 3.94, the optimisations in the --alt-presets were incorporated into all LAME encoding operations.

What about 3.90.3 --alt-preset insane?

--alt-preset insane is the only one of the --alt-preset switches that cannot be directly correlated with a -V switch, since it is a cbr setting, not vbr.

But you already knew that. Be careful. People who ask questions to which they already know the anwers are usually trolling, at least to some degree.

And before you rush to point out the "error" in my first statement, I am of course referring to the labeled vbr range of the --alt-presets, not the obvious abr and cbr ranges with their specified bitrates. Drenholm's post was clearly referring to the vbr presets as well.

Regards,
Madrigal

The essence of Drenholm's statement to me was '--alt-preset vbr modes are not tuned but are directly mapped to -Vx'. This doesn't cover api which among the alt-presets is of most interest to me. user gave valuable information already on api. But any more information is welcome. So my reply was just asking Drenholm (or whoever can contribute) for information on api.

This might be interesting for you: take a look at this thread, especially Dibrom's comments. It discusses gpsycho's vs. nspsytune's pre-echo control.

Thank you very much. Real interesting. As far as real experience was explicitly adressed, it was JohnV who did, and his experience goes towards gpsycho. dibrom's comments were mainly statements about nspsytune's overall advantages and the tweaks that were made on it and that neither gpsycho nor nspsytune were very good at pre-echo handling, and that nspsytune isn't that bad (considering pre-echo) as many people seem to have considered it that time.
[added later having read the thread again: not quite correct what I said: dibrom mentioned fatboy performing better with nspsytune. Will test on it again though I dislike it very much - and couldn't abx it in that previous test but don't remember the circumstances].
Similar to the discussion here (with the difference that today's common reasoning goes against gpsycho instead of nspsytune).
Backs up my preference for -b320 so far.
Or should I go for fastencc? (or latest Fraunhofer codec). Never considered that before. Don't really consider it right now.

Drenholm's statement was not even addressed to you, it was addressed specifically to ConCave.
Perhaps not, but it did cover what was of interest to ConCave. This thread is not about what interests you, but about a change in the recommended version of Lame, and a change from the --alt-preset and --preset systems to a recommendation of the -Vn system.
Because user's reply was directed to you and your particular interest.
By whom? Maybe you should start a separate thread to handle this personal quest for specific knowledge.
With all due respect, hogwash. It was either a challenge to what Drenholm had written to ConCave, or else an attempt to draw the thread's focus back to your personal preference for 3.90.3 api, which you appear to feel should be the focus of this whole thread.

Regards,
Madrigal

I just went to abx 3.90.3 api on the trumpet sample: 5/10.
So I did mix things up. Sorry for the wrong statement, especially towards stephanV.
And as 3.90.3 api uses nspsytune I will be quiet now about that. Whether there is an issue with nspsytune or not: I'll leave it to the devs.

So as for 3.90.3 -b320 -h or api for me there is no reason so far to prefer one over the other. Can throw dice. Think I will stay with -b320 -h (yes I'm conservative in these things, but it's also because of my attitude towards sTisTi's thread). The stereo mode doesn't worry me any more - was just upset when I read of it. Matches a bit my reasoning that simplifying things can help optimizing worst case behavior. Not a real argument I know, I just like thinking like that. BTW I've tried fastencc, and while I'm not about to really test it I found it uses stereo mode too with cbr 320. Contributes to my decision a tiny bit.