I have understood that recommended 3.97 (beta2) has some problems with high bitrate vbr's like -V 0 and -V 1. Some kind of noise effect? I also saw a thread which said that 3.98 (alphas) is better in -V 0, it doesn't have same problems but it gives a little higher average bitrates.

I know that alphas can't be offically recommended. But would you say that it might be a better idea to use 3.98 alphas if the only interest is encoding with best possible vbr settings? I donät care if filesizes grow a little, as long as I can trust my encoding has no problems.

Then you should perhaps consider lossless encoders.

I use Flac to archive. But I need to use also mp3's as it's the only format that both my portable and dj software support. So best possible mp3 below 320 cbr is wanted and needed...

I don't think you will find any conclusive answer to this question, it's not well enough tested.

So just try for yourself and see. It is always possible that a lossy encoder has problems with some tracks (AKA problem samples).

A portable is not hi-fi equipment, and you would probably be listening on noisy situations. Unless you are DJing opera on a theater, i don't think that they would be paying too much attention to sound artifacts either.

I consider the 3.98 alphas to be pretty good. They deal with known issues 3.97 has. 3.97 got to be the HA recommendation before these issues were known. Of course it's a subjective thing whether or not these problems are considered to be severe.
Sure the 3.98 alphas are currently not at the end of the road. But the Lame devs are doing a good job with it.

Hi

Would you use 3.98a6 if you had all your cds backed up in flac on an external hard drive so if there was a major flaw with the encoder you could easily encode again or would you just stick to 3.97b2, because i usually encode to -V 0 to use on my main machine to save space but have optimal quailty without having flac sizes.

Thanks

ConCave

@Concave:

In case your question is addressed at me:
Your argument is the very reason why I prefer 3.90.3 very high bitrate abr. Most robust version and setting to me up to now taking the quality experience and knowledge I have alltogether.
But the question was: 3.97b2 or 3.98alpha VBR, and yes, with this choice I'd use 3.98 alpha. Though I admit I would defer my encoding as long as possible to use the best version (and take into account the latest experience) among the 3.98 alphas (or betas - if available).

Wat issues are there with 3.97 b2? It is the recommended version. I must have missed the issues thread. My -V2 vbr new encodes have sounded great.

There is a problem sample thread covering this. Wombat has found distortions in a series of samples (even at -V2) which he calls 'sandpaper-like noise'. They're not typical problem samples but are 3.97-specific, and the problems seem to show up not only in a very isolated way.

My personal horror sample started to be trumpet which is encoded very badly with 3.97 (but not much better with 3.96, or with 3.90 when using VBR). Trumpet shows up the same kind of sand-paper distortions to me (though the technical reason for this may be different as guruboolez pointed out). Trumpet's distortions are a lot more serious, but trumpet is rather one of the special problem samples any mp3 encoder has some kind of problem with requiring high bitrate. 3.97 however has these problems to an extended degree.

These issues are covered by 3.98a3+. Especially VBR has become more robust.

Sure it's a subjective thing how to rate these things, and especially to prefer a 3.98 alpha version at its current state.

This is more a genereal question, but why is 3.98 and 4.0 been developed when 3.97 is still a beta? Woudln't 3.97 be released as a final first or is that the highest version it will go?

This is an interesting question which I were pleased the Lame devs would answer.

I always wondered about the 4.0 branch in parallel to the 3.9x branch.

As for 3.9x it looks like all the development goes into 3.98. And to me that's the way to go.

I just always wondered why 3.97 was left as a beta (Which is still a very stable release)

I cannot seem to locate the thread. Does someone have the link?

It's threads like this that emphasize the importance of lossless archiving so you can update your lossy files (if needed) much easier than the arduous process of re-ripping your CD collection.

What's the timeline for LAME 4 ?

It's here:

• samples: problem sample thread
• discussion: discussion thread

These are questions that I would like answered as well:

1. Will there be a final 3.97 release?
2. Is the plan to supersede 3.97 with 3.98?
3. How will version 4 fit into the picture?

Bonus round question: are there release notes posted for each 3.98 build? If so, where can they be found? Periodically, Rarewares will post a newly dated version of 3.98a6, but there is nothing to indicate what changed. Having even a brief outline of the changes would be a great help in test / evaluation.

My (subjective) testing so far has been positive so far at -V2. Thanks to the developers for their continuing effort.

Its like MS developing Windows 2000, while at the same time developing Windows ME.

1. We don't know. Maybe eventually.
2. Obviously yes, otherwise it wouldn't be a greater version number, now would it?
3. Version 4 is a complete rewrite, and AFAIK not (as) actively developed as the 3.9x line. IIRC, It uses completely new psymodels, etc., so it's not really "in the picture"

Bonus : LAME 3.98 development

* Alexander Leidinger:
o Add TLEN (ID3v2) support (Submitted by: Linus Walleij)
o Add number of total tracks per album (ID3v2) support (Submitted by: Kyle VanderBeek)
o Some seatbelts for overflowing arrays in the ID3v2 support.
* Robert Hegemann:
o Fixed some console printing problems
o Fixed: in case of not enough bits the new vbr code incorrectly used old vbr routine
* John33:
o Fixed mp2 and mp3 decoding: For mp3 and mp2 decoding, this now yields the same output as foobar2000 but the error checking remains unchanged


http://cvs.sourceforge.net/cgi-bin/viewcvs...y.html?rev=HEAD (feb 8)
http://72.14.207.104/search?q=cache:-H0zZ3...t=clnk&cd=4 (cache)

Thanks for that info