Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: List of recommended LAME compiles (Read 423340 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

List of recommended LAME compiles

Reply #50
Quick question: Is Lame 3.90.2-ICL still recommended over the official Lame 3.91?


List of recommended LAME compiles

Reply #52
Sorry for letting the compiles slide everyone.. I've been without a usable connection since I recently moved about 2 weeks ago.  I'm planning to update the compile here soon, implementing the modifications I mentioned above which bring the ICL binary's bitrate closer to the MSVC binary's bitrate.  Sphoid and I are also working on another nifty LAME related project which pertains to the compiles HydrogenAudio will distribute.  Maybe I can post a screenshot of it soon

List of recommended LAME compiles

Reply #53
Dibrom,

In your opinion, from a pure quality standpoint, is it worth it to wait for your next compile to update all my MP3's to your --alt-preset insane?

I've been waiting for you to release a 3.91 compile, but I've learned that 3.91 is just a bugfix for your --alt-preset-standard, so I could just use 3.90.2... or do you have some other extra goodies planned to increase sound quality in your next compile?

Thank you infinitely for your efforts to improve MP3 encoding quality, it has been greatly useful to me.

--jeff

List of recommended LAME compiles

Reply #54
feckn_eejit:

No increases for sound quality will be in my 3.91 compile at this time, so 3.90.2 would work fine in that regard.  At some point I will try to improve quality some more, but even then it won't be in the "insane" mode, at least for awhile.  I still have to work on the ABR/CBR modes some more.

As for the other project I mentioned, it is only related to usability improvements and will provide no difference in the encoded mp3s at all.

List of recommended LAME compiles

Reply #55
Thanks for the speedy reply!

I will use 3.90.2.

--jeff

List of recommended LAME compiles

Reply #56
Hi Dibrom,

I had an interesting conversation with mitiok about different compiles recently, and he sent me an excerpt from ICL guide:

Quote
The Intel compiler uses the -Qrcd option to improve the performance of code that requires floating-point-to-integer conversions. The optimization is obtained by controlling the change of the rounding mode.

The system default floating point rounding mode is round-to-nearest. This means that values are rounded during floating point calculations. However, the C language requires floating point values to be truncated when a conversion to an integer is involved. To do this, the compiler must change the rounding mode to truncation before each floating point-to-integer conversion and change it back afterwards.

The -Qrcd option disables the change to truncation of the rounding mode for all floating point calculations, including floating point-to-integer conversions. Turning on this option can improve performance, but floating point conversions to integer will not conform to C semantics.
=========================


Therefore: ICL is MORE accurate than MSVC. Because rounding-to-nearest is more 'accurate' than truncating.
As far as I remember, some time ago someone suggested that MSVC is more accurate.
You probably know all this, but I thought it would be appropriate to state all this clearly on this forum.

Of course, you may consider this irrelevant, because you once argued that more-accurate-arithmetics!=better-quality

The reason why mitiok is not going to change his compile, sounds very reasonable to me: he is making "default" Lame compiles, and the /QIfist (= /Qrcd) option is included in Makefile.MSVC, indeed. This file is a part of original Lame sourcecode. (to avoid misunderstanding: yes, Makefile.MSVC contains sections for both MSVC and ICL compilers)
(EDIT: I think I didn't write it clear enough here: mitiok and smpman both use ICL 4.5 compiler with default settings. The default settings for ICL 4.5 are: 'round-to-nearest'. Dibrom recommends ICL as well, though he considers changing the settings to 'truncate'. All settings are set in Makefile.MSVC)

My suggestion is that You, Dibrom talked to _all_ the Lame developers to decide which version (with or without /QIfist) should be defaulted in Makefile.MSVC .
As mitiok told me, some of developers disagree with You, Dibrom, that more-accurate-arithmetics!=better-quality.
If you're sure, that disabling this switch is a wise thing to do - convince them.
Instead of making a non-default compile, try a compromise with them, and then use the default options (or maybe make 2 sections: recommended and unrecommended in Makefile.MSVC...?) and everyone will be happy.

I hope it makes sense to solve this problem this way:)

Oh, btw, smpman promised to add the modified ICL compile of Lame 3.91stable to his site, but not of the alpha versions.

Regards,
Olcios

List of recommended LAME compiles

Reply #57
quote:

The -Qrcd option disables the change to truncation of the rounding mode for all floating point calculations, including floating point-to-integer conversions. Turning on this option can improve performance, but floating point conversions to integer will not conform to C semantics.
=========================

Therefore: ICL is MORE accurate than MSVC. Because rounding-to-nearest is more 'accurate' than truncating.
As far as I remember, some time ago someone suggested that MSVC is more accurate.
----------------------

Olios,

if the code does not perform in the way it is intended by the programmer (and the ANSI C standard) you can't call this code "more accurate". It might work but there are risks that it has side effects.

List of recommended LAME compiles

Reply #58
Surely if the original author of the code was looking for rounding to nearest, they would have added 0.5 to floats(etc) and truncated - same difference?

john33

List of recommended LAME compiles

Reply #59
quote:

Surely if the original author of the code was looking for rounding to nearest, they would have added 0.5 to floats(etc) and truncated - same difference?
--------------------------------------

Hi john33,

C-like fp to int conversion ( var_int = (int) var_double ) uses rounding toward zero ( 1.6 -> 1; -1.3 -> -1 ); the addition of a constant positive offset creates new problems ( (1.6 +.5) -> 2; (-1.3 +.5) -> 0 ) but does not give the same results as rounding to nearest.

List of recommended LAME compiles

Reply #60
I wonder how much we are splitting hairs now....

I believe Dibrom when he says he heard a sample that was better with ICL than with mitioks compile... but  if it only helps 0.5% of ifles out ( 1 out of 200) is it really a big deal...

The problem I have is my ignorance about this stuff... am I underestimating the benefit of ICL compiles...?

Any further commentary by Dibrom or others would be appreciated....

List of recommended LAME compiles

Reply #61
Quote
I believe Dibrom when he says he heard a sample that was better with ICL than mitioks


No! He was saying that the default ('round-to-nearest') ICL compile sounds better than MSVC compile ('truncate') on file fatboy.wav. Mitiok and smpman and Dibrom's (current, 2002-01-24) compile are ALL default ICL 4.5 . So they are ALL BETTER than MSVC in terms of quality. And they all produce 3% larger file than MSVC.

Dibrom is considering changing a switch in ICL so that it will produce the same filesizes as MSVC. The quality would be affected than - would be a little worse on fatboy.wav .

BTW, Dibrom, please state it clearly, did you test the modified ICL on fatboy.wav, and does it work on it just like MSVC does or maybe somehow, miraculously, the quality is as high as with default ICL, while the filesizes are the same as with MSVC?

Quote
Surely if the original author of the code was looking for rounding to nearest

That is the question. What was the developer looking for? Mitiok suggested it might be a problem in nspsytune which causes so large differences between compiles. ....I don't know why he thinks that nspsytune and not something else....Naoki is the author of nspsytune.....

BTW, fatboy.wav is the only file on which anyone have ever reported any difference between compiles. Maybe conducting some hearing tests on various files would be a wise thing to do now?

Olcios

List of recommended LAME compiles

Reply #62
Quote
Originally posted by olcios
...Dibrom's (current, 2002-01-24) compile...
olcios (or anybody),
Could you please supply a link as to where this compile may be obtained?  Or are you simply referring to 3.90.2, and saying that it is still "current"?  Thanks.

Regards,
Madrigal

List of recommended LAME compiles

Reply #63
If I remember correctly, after some argument with the lame dev people, Dibrom's 3.90.2 became 3.91. In other words, they're the same thing.

john33

List of recommended LAME compiles

Reply #64
Quote
Originally posted by john33
...Dibrom's 3.90.2 became 3.91. In other words, they're the same thing.
Ok, thanks for the quick reply.  I was hoping Dibrom had gotten around to compiling 3.91, as he still plans to do (see earlier in this thread), with some non-qualitative improvements, especially since 3.92 alpha 1 is already being offered at Dmitry's site.  Guess I'll just have to be patient, and wait till it shows up at the start of this thread.

Regards,
Madrigal

List of recommended LAME compiles

Reply #65
Ok, to respond and try to clarify a few points:

1.  3.91 and 3.90.2 are indeed the same thing.

2.  I will be providing a 3.91 compile in the future, just not sure when yet.  I need to reinstall and setup my C development stuff for this.

3.  About the ICL vs MSVC thing, well it's hard to say which is more accurate.  I tend to say ICL is less accurate because the switch in question will not confirm to standardized C conventions, but its a matter of semantics perhaps.  At any rate, on one file I have heard a difference, and this was fatboy.wav as stated earlier.

4.  I don't believe I have tested the ICL compile in which I have come closer to the MSVC bitrates to see if it had the same problem.  I actually don't remember because I found this out right before I moved and a lot of things where going on.  I do know that the files are not always bit identical, but they are usually within a 1kbps or so of eachother.  So it is possible that the ICL compile even with this modification could still sound better,  I'm not really sure.  One thing is for certain though, the difference is pretty small and it's only on one file that I know of so far.

5.  About mitiok and the lame-dev and standardizing LAME compiles.  I'm not sure I want to take part in this, the reasons are stated in other areas for those who may not be aware.  I have little desire to try and convince anyone on the lame-dev, or especially mitiok, of anything because IMO (and experience) it is mostly an excercise in frustration and futility.  Instead of wasting valuable time with this approach, I'd rather be working on something (or releasing something) directly.

Now, this isn't to say I'm not willing to work with others, I certainly am... but I have tried this road with 3.90.2 and it was not particularly pleasant.  This coupled with my lack of time these days, even to deal with this site to my satisfaction, just makes this seem like an unwise idea.

What I suggest to Olcios is that if you have a very high interest in seeing this happen, that you instead ask others to come here and try to work with me for a change instead of the other way around.

6.  I don't think there is a "problem" with the nspsytune code .  I tend to doubt this because on non-icl compiles it produces bit identical results (MSVC and gcc).  I believe I've seen Mitiok state that he doesn't believe in nspsytune (for whatever reason) so that could be why he says this.

List of recommended LAME compiles

Reply #66
Quote
Originally posted by Dibrom
2.  I will be providing a 3.91 compile in the future, just not sure when yet.  I need to reinstall and setup my C development stuff for this.
Just to make sure, until you release your compiles is it okay to use Mitiok's 3.91 compile?  Is there anything problematic with his compiles, or is it just that they're a few percent slower than the ones you had been making?

List of recommended LAME compiles

Reply #67
Quote
Originally posted by Delirium
Just to make sure, until you release your compiles is it okay to use Mitiok's 3.91 compile?  Is there anything problematic with his compiles, or is it just that they're a few percent slower than the ones you had been making?


Yes, they should be fine for use, and the only real difference should be encoding speed.

List of recommended LAME compiles

Reply #68
Thanx for your reply, Dibrom.

Quote
[comparing MSVC and 'modified' ICL]I do know that the files are not always bit identical, but they are usually within a 1kbps or so of eachother.

Does anyone have any idea what causes this difference? In other words: there must be another switch in ICL which is default for this compiler and is not ANSI. What is it?

Quote
So it is possible that the ICL compile even with this modification could still sound better, I'm not really sure.

Yeah, I would really like to know it. Now if only someone who has ICL compiler could test it. (comparing to ppl on this board I'm deaf, so I won't even try. Not mentioning that my old comp is too slow to encode)

Quote
What I suggest to Olcios is that if you have a very high interest in seeing this happen, that you instead ask others to come here and try to work with me for a change instead of the other way around.

As for lame-dev, i'll be mailing them next week or later when my exam session ends. I'll present some questions to certain programmers and authors of the makefiles. It may clear up some issues which depend on the intentions of the programmers.

I wonder in which part of the code the float->int conversions occur...how to find them? Maybe it is possible to turn on warnings whenever they occur and localize them that way?

Olcios

List of recommended LAME compiles

Reply #69
Quote
Originally posted by olcios
Does anyone have any idea what causes this difference? In other words: there must be another switch in ICL which is default for this compiler and is not ANSI. What is it?


I'm not sure.  I haven't had the time to track it down.  However, whatever it is, its probably not an issue, especially if it will further reduce speed.  Often times the bitrate is the same, just on occassion it can very by .1 - 1.0 kbps. 

Quote
I wonder in which part of the code the float->int conversions occur...how to find them? Maybe it is possible to turn on warnings whenever they occur and localize them that way?


I don't think this will help.  Alexander said he was working with this approach awhile ago, but then at some point Mark cleaned up the code and used proper casting to where the majority of warnings disappeared.

List of recommended LAME compiles

Reply #70
Any progress in the past month on a newer compile, Dibrom?

I'm not pushing BTW, just curious... please take your time, the current 3.91 is working just fine here (and the improvements are appreciated).

List of recommended LAME compiles

Reply #71
Quote
Originally posted by fewtch
Any progress in the past month on a newer compile, Dibrom?


Well, I'm working on the ABR stuff again and making progress, but there's a few areas that need work and so I'm holding off on release until I can get things working better in all situations (the enhanced abr modes don't work so well at lower bitrates and need more tuning..).

I've started looking at --alt-preset standard again in an attempt to address the 3 or so samples were it could use a little work.  At least one of the clips is an actual fault in vbr-old I've determined and is completely unrelated to gpsycho or nspsytune or any of my tunings (the dogwhistle clip).. so this one might take a bit of work.  Wombat's samples are simply a matter of tuning I think, and I suspect JohnV's vangelis clip is probably similar.

Quote
I'm not pushing BTW, just curious... please take your time, the current 3.91 is working just fine here (and the improvements are appreciated).


Rest assured I'll let everyone know when I've made some release worthy improvements  I've just been rather busy lately, so I haven't had much time to work on LAME.

The current state of quality though is really pretty high for MP3, and the cases where it doesn't sound perfect usually don't sound that bad (meaning still better than most modes in most mp3 encoders), in addition to the fact that these cases are much lower in frequency apparently than with other encoders/modes.

 

List of recommended LAME compiles

Reply #72
If my memory serves me right there's a new nspsytune in the LAME alphas, will this be utilized in your new tunings? Or is the new nspsytune considered too experimental?

List of recommended LAME compiles

Reply #73
Quote
Originally posted by kjempen
If my memory serves me right there's a new nspsytune in the LAME alphas, will this be utilized in your new tunings? Or is the new nspsytune considered too experimental?


For starters, nspsytune2 isn't practical to use in a "recommended" build because it requires 2 passes and an external program to be used, not to mention that even according to Naoki it's still very early and needs more tuning.

I think it will be a ways off before nspsytune2 is ready for "production" use so I wouldn't expect to see it in the alt-presets in the very near future.

List of recommended LAME compiles

Reply #74
Any changes in recommendations now that 3.92 is out?  Technically at least, 3.90.x is two (minor) versions behind the current release.