Just for the record, Robert is looking at this issue and will be back with something for testing in the not too distant future. In the meantime, the higher bitrate is not hurting quality but it may be spending unnecessary bits.

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

Just for the record, Robert is looking at this issue and will be back with something for testing in the not too distant future. In the meantime, the higher bitrate is not hurting quality but it may be spending unnecessary bits.

It's somewhere in calc_xmin() (in quantize_pvt.c). Move this function to a new file and compile it with MSVC compiler, and the rest with ICC.

From the sidelines, I found this discussion of the FP rounding and/or compiler-related differences fascinating. Although this was the discussion started regarding LAME 3.99 release I was glad to have read-through it (just like a recent topic about layman's FFT explanation) and wanted to express my appreciation to those involved on the member and developers for sleuthing and posting their information. This is why HA has always rocked for me =)

Agreed Destroid. This has been an interesting read. I jumped back to find the start of the latest development.

And with that being said, maybe it's time to split the thread? Little of this thread has been dedicated to the actual quality improvements/unimprovements of Lame 3.99. It's been more about compiler optimizing and compiler output.

I'm surprised this thread wasn't split a long time ago. I can't imagine that 99% of users who might see this release announcement and consider updating to 3.99 have either the time or the energy to read through well over 300 posts. I would expect some discussion of new 3.99.x releases and updated Rarewares compiles as they come out, but the minutiae in this thread really belongs in a tech forum.

The "minutiae" in this thread are actually useful information: the difference in bitrate produced by different compiles might have an impact on quality, still to be determined exactly, and the LAME header issues do have an impact on usability, I'm glad both discussions have been consolidated here, just learn to skip the parts not relevant to you, this isn't a forum for Joe Average anyway.

P.S.Minutiae is plural, if you wanna show off your Latin at least do it properly.

Robert is currently working on a solution that would make LAME more, or less, "compiler proof", or at least the variations between compilers would become inconsequential. Obviously some testing will be required when he has a solution that is 'fit for purpose' and HA will be the first to know.

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

Robert is currently working on a solution that would make LAME more, or less, "compiler proof", or at least the variations between compilers would become inconsequential. Obviously some testing will be required when he has a solution that is 'fit for purpose' and HA will be the first to know.

This implies that the exact piece of code in question has been identified. Please confirm that it is in quantize_pvt.c and maybe point to a more precise location.

Here's that set of files again, encoded using the RareWares 32-bit LAME 3.95.5-test compile. The differences are very small now. lvqcl's compile still produces slightly smaller files, even at the lowest quality levels, but the differences in file size are generally only a fraction of a percent.

I checked Alex B's Liszt sample, and 3.99.5 behaves nearly exactly as lvql's MSV10 compile bitratewise (208 kbps for-V1, and 97 kbps for -V5).I also checked the bitrate distribution for -V5, and the Encspot result looks pretty much the same Alex B gave us.

So just to be clear, this is now resolved? Should I grab the 3.99.5-test from RareWares, or wait for 3.99.5 proper?

Another thing I'm wondering, I saw some encoding speed differences earlier in the original thread this was split from.Was there encoding speed differences with 3.99.5-test and 3.99.4 (lvqcl), how about 32bit vs 64bit builds?Or was that stuff just completely unrelated?

So just to be clear, this is now resolved? Should I grab the 3.99.5-test from RareWares, or wait for 3.99.5 proper?

Another thing I'm wondering, I saw some encoding speed differences earlier in the original thread this was split from.Was there encoding speed differences with 3.99.5-test and 3.99.4 (lvqcl), how about 32bit vs 64bit builds?Or was that stuff just completely unrelated?

I would be inclined to wait for the full release, if I were you. There could be further changes until then, but if you feel inclined to test, please go ahead.

The speed stuff was unrelated, IRRC.

--------------------

John----------------------------------------------------------------My compiles and utilities are at http://www.rarewares.org/

Kilu, in summary, the encoding speed differences were between 3.98 and 3.99. 3.99 encoded slower than 3.98. Through compiler optimizing 3.99's speed was brought up to par with 3.98.

Sure there is going to be encoding speed differences between 3.99.5-test (ICL), 3.99.4 (MSVS2010), 32 and 64-bit builds, but that's not what's on trial right now. What's on trial right now is the output between all.