lame 3.96.1 @ Rarewares.org

I have one question:
Are these bugfix affect/improve quality or not (compared to original 3.96) when you use --preset standard?
Because I've encoded ~100 albums with 3.96 and I want to know if the original 3.96 is buggy when using --preset standard.
Thank you

Hi,

I'm surprised of the weak reaction to this anouncement. Is no one out there, everyone in vacation?

Well, I'm happy to see things going on. Thanks a lot!

One question: What was the reason for this bugfix-release? I think nobody really expected one. Everybody tought, 3.97 would be the next version.

we are all happy about it, and celebrating ...

AFAIK the new vbr mode is not used in --aps, but in --apfs.
I guess the wrong block size selection for mid and side channels is not that hard, we probably won't recognize it, so.. what on earth is that important to reencode ~100 albums again ? Maybe it's time to rethink over time- and current-usage.
sorry, it's some kind of vice always to become intimate *lol*

Yeah that's what I was thinking but I would like to have an official answer about this problem with -aps (Gabriel maybe?)

Don't worry sPeziFisH about your "vice" there is no need to apologize!
If It can reassure you, I'm not planning to reencode everything because the only artefacts I can hear are thoose from 128kbp wma or blade encoded mp3 everything else is transparent for me!

The problem was JUST with the fast presets, as far as I know --preset standard is unchanged... not sure what the joint stereo changes were though...

The LAME signature inside the created files still reads 3.96 in the VBR header and 3.96.1 at the last frames.

Wee! I was waiting for LAME 3.96.1. Now I guess I can go re-rip & re-encode all 120 CDs of mine.

Some fixes? I would be interested in exactly what "some fixes" were / meant .

I don't think lame can have more than 3 numbers stored in the lame tag, maybe it could read 3961.

As I do not feel the need to explain every line of code changed in the history file, feel free to have a look at the source code.


Because vbr new was sometimes crashing.

I feel the need to say your effort is acknowledged & appreciated by many people here Gabriel, thanks for your work with lame.

I found the mp2 decoding is broken in this release.
3.96 worked fine.

time to update LAME 3.96 dll modified to use INI FIle Setup john?

Not that I don't appreciate the work done on the codec, as I do, but i think good documentation is important to the future of open source. Especially change logs. I thought they were to serve as a one stop refrence for changes, so you didn't have to scroll through the entire source code.

It's just that I do not think that things like:
replaced call to xxxW by a call to xxxA win32 function
are that interesting/necessary in a changelog.

Thanks to all the LAME developers for their continued efforts.

I've uploaded an OS X compile of 3.96.1 to Roberto to replace the older version on Rarewares. If anybody needs a copy in the interim, send me a PM and I'd be happy to forward one.

agree ... changelogs should include info on what has been changed that fixes/modifies something that the user can "see" ... programmers change code all the time , just to make things crlearer, for example, and we don't usually document that

BTW 3.96.1 displays 3.96r in the lame header.

Try something like diff to see the difference between two files.

I don't think there is any change to the decoding code. I run WinDiff on the source files of 3.96.1 and 3.96 and there are only changes in these files:



Are you sure that it is not a problem with your compile of LAME?

While I was running WinDiff to compare the differences between the source code of 3.96.1 and 3.96, I noticed that ChangeLog and config.h.in of 3.96.1 are actually older than those of 3.96:



Running WinDiff on the individual files shows that entries since January 10 are missing in ChangeLog of 3.96.1. Also, this little bit of code is missing in config.h.in of 3.96.1:



Is it possible that the latest version of these files were accidentally overwritten by the ones from 3.96?

As it seems that some people want to see the code differences between versions, I'd like to point that you can already do that on sourceforge.

Regarding mp2 decoding, it is possible that it has been disabled at configure/compile time, but you can enable it when compiling.

I just downloaded from Rareware, didn't compile it myself.
Here is the error when trying to decode MP2 file.

skipping initial 241 samples (encoder+decoder delay)
Blocktype == 0 and window-switching == 1 not allowed.
Can't step back 426!

And it stop for a long time until I close the window.
Also found the the sample frequencies is detected wrongly.
I have some files with 44kHz, but it detected as 48 kHz, 32 kHz,
and sometimes even detected as freeformat!
Any idea?

Just download the new binary from http://mitiok.free.fr/
And it works fine now.
Does it mean some compile option was disabled at Rarawares' binary?

Is this a "safe" compile (you know, important stuff like -aps support and gapless --LAME tag-based-- encoding)?

Sorry if this is silly, I just haven't downloaded ANYTHING from mitiok since the r3mix days. I have come to associate it with "evil" compiles...

I'm in the midst of transferring hundreds of CDs to VBR mp3 via EAC with a handoff to LAME 3.90.3 (the current recommended LAME compile) as the external compressor, using --alt preset standard.

Is there any reason to switch to 3.96.1?

-Better speed.
-Lower bit-rate.
-ABX tests so far show quality no worse than 3.90.3 some samples better some worse.

3.90.3 is still good to test the quality of the newest lame release because it was so well tunned & it can still perform better than current lame on some samples but I wouldn't use it for archiving any more.

3.96.1 is averaging 160-180kbps 3.90.3 was about 180-220kbps on my music that alone is a good reason to switch.

Mitiok and Rarewares Compile (3.96.1) produce bitidentical results.

i second that - the hardwired ini-settings version was a great way to use lame with apps which arent preset-compatible.

- Lyx