@dannyb37
Were you waiting for some particular bug-fix?

Is this going to be the final beta, cause on the history page on lame.sf.net after beta 5 is "LAME 3.98 stable not yet released"...?

Don't point the developers to any bugs you find, then they'll release a "stable" version.

It was more curiosity than anything it was under the Change log as "not yet released" so yeah.

Well, there are known bugs we won't fix for a 3.98 stable release. (The 'mpg123 decoding library' needs a complete overhaul; we use it mainly because of the mp3x frame analizer)

There are some regressions for VBR NEW with some files at higher compression levels (V4, V5, .., V9),
we'll try to solve them with 3.99. The current solution for the 'sandpaper-noise issue' (ie: birds.wav) is a compromise with some side effect at those compression levels.

Does this mean it's not safe to use V4 and above when 3.98 stable is released?

It means:

- It's very likely that 3.98 stable will give you the same output as 3.98 beta 5 does now.

- 3.98 will be as safe to use as 3.97 is now. The few personal listening tests at V5 see no
clear winner or looser.

- There is room for improvements.

RareWares.org



Changelog

I am somewhat new to encoding, so maybe I am missing something.

- LAME can calculate ReplayGain values which it stores in the LAME header.
- Very few programs can use these header values and instead use id3v2 tag values.
- LAME writes a id3v2 tag.

If LAME is writing the tag anyway, why can't it also add the ReplayGain value at the same time saving me the extra work?

I noticed that -V2 now uses -q0 by default (as opposed to -q3 in Lame 3.97). What happened to the original -q2..q0 switches?

@bilbo
LAME can't update existing ID3v2 tags right now. LAME has to write the ID3 tag before encoding starts and does not know the track gain at that point. IMHO album gain would be more interesting anyway.

@Jojo
The 3.97's quality settings q3 to q0 were all the same for the new VBR code. It's the maximum quality this code has to offer, that's why it is flagged q0 now.

Ooops

My "fault".

I merged the beta 5 discussion from the beta 4 thread into this thread created by you, but unfortunately your initial post is no longer the first due to post date. I deleted DARcode's post for clarity, but left yours.

A little confusing, but if we gloss over it this thread can continue as it should.

Anyway, w00t for beta 5....

It doesn't matter. The information is more important than who has posted it...

Though there are no changes to be expected regarding listening quality (judging from the change log) I did a short listening test. I found out yesterday that part of my archive concerning oldies music is encoded losslessly as well as with very high bitrate wavPack lossy, and these tracks are really not of such a high quality that this is appropriate. Encoding to very high quality mp3 and keeping just that should do it. For me this means roughly the 200...250 kbps range. So a listening test with new 3.98beta is pretty interesting to me.

For my short listening test I choose -V1, --abr 224, and -b 224.
Form previous betas and tests at ~ 192 kbps I know that quality with the real bad samples I tested was not annoying. So using ~ 224 kbps the question is whether the differences to the original are negligible. Real transparency cannot be expected for most of the samples.

As samples I used

• eig as a terrible pre-echo sample
• Birds, herding_calls, and trumpet as samples where previous versions of Lame produced considerable distortions especially when using VBR
• harp40_1 as a sample for the harp precision problem
• Trumpet_My_Prince as a sample with a kind-of-tremolo problem

3.98b5 is relatively good at eig except for the range ~ 2.3 ... 4.3 sec.
The different settings don't produce a significantly different quality, though -V1 sounds best to me and cbr 224 worst.

As for the distortion problems Birds and herding_calls are abxable though absolutely not annoying. VBR, ABR, CBR don't produce a significantly different quality. ABXing herding_calls was rather easy. For me using CBR on herding_calls was a bit harder to abx then with the other settings. Birds sounded a bit more correct to me using -V1 though strangely -V1 was a bit easier to abx.
ABXing trumpet was a bit strange too. The distortions of former versions are definitely gone for me. I started with -V1 followed by abr 224 and couldn't abx a difference. Going cbr 224 however I rather easily got at 8/8 cause I could hear some problem in HF. But after my 8th guess I lost what I could hear so clearly and finished with 8/10. Retested -V1 and abr 224, thought with some guesses I could hear the problem again, but did not succeed in abxing. Retested cbr with the same negative result. Strange.

harp40_1 is very good, not annoying, but abxable, with all the settings. the cbr setting was the easiest for me to abx.

Trumpet_my_prince has still a tiny VBR problem though it's negligible to me. With my first listening I thought it's fine cause it can hardly be described as a tremolo effect as I did before. ABXing however wasn't very hard.

Putting it all together I call the differences to the original negligible for these bad samples (with the exception of parts of eig - but nobody can expect an mp3 eig encoding to have only a negligible issue).

As for the settings there's no big choice qualitywise. Differences are not worth while to differentiate - not at this bitrate and with these samples (and to my ears).

Mind if I ask why, besides the mpg123 thing?

The known bugs I was talking about, they are all mpg123 related. Those have always been there, so it doesn't really matter if we fix them now or later.

ahh, thanks.

Uhm, does LAME use mpg123 also for decoding? I thought this decoder isn't ISO compliant!

Is the decoder used by lame 3.98 already ISO-compliant? This page says 3.86b wasn't:

http://www.underbit.com/resources/mpeg/audio/compliance/

I have a couple of questions, I have a x2 4600 clocked at 2.6 and my encoding speed are about 30x for both cores. Now my friend has a core 2 4300 clocked at 2.4 and he gets like 45x. Is this because the Allendale's have sse4 and the x2s don't? I take it there aren't any AMD optimized builds of 3.98 or even 3.97? I might just spring for a 4300 and cheap mb and clock it to 3.0. Or wait for phenom

If I'm not mistaken this is because of several enhancements to the Core2Duo processors. The older AMD architecture can only process 3 instructions per clock cycle, whereas the newer Intel chips can process 4 instructions per clock cycle. I'm sure there is more to it than that, but it is impossible to compare clock speeds anymore in an apples to apples manner.

There are basic optimisation for 3DNow and SSE, so you will be getting benefit from them, but, Zoom is essentially correct in that the C2D processors are currently significantly faster than any of the AMD chips.

I think that Layer I/II decoding was not enabled in this version.