I gave the updated link in reply #36.I'll try to have the mods let me update my original post.

It's a pity that different development environtments lead to different encoders. I was troubled by this when I started doing Lame development. The then active Lame developer, robert (haven't heard of him for years unfortunately), helped me a lot doing my first compilations (I wasn't used to C programming environments). He used VC++, and so did I. First thing I noticed was that using the original Lame source the VC++ compiled encoder produced other results than the Rarewares encoder which used the same source. I computed the difference signal, and the difference wasn't even very small. robert convinced me that I don't have to care.

As long as you don't have any evidence for audible differences I think you don't have to worry. And if you do want to use exactly the encoder I tested just use my exe.

With lame3995o and each -Q level there is an underlying basic -V level. The encoding parameters of my machinery have a value at least that of this basic -V level. This goes also for the lowpass value (though not really a quality parameter).The basic -V level for -Q0 is -V0, so -Q0 uses the lowpass value of original Lame's -V0. I have no reason not to trust in original Lame's lowpass value (though it's true I was more conservative with former versions of my variant).

What do you think? Is it still okay to use lame3100m? Because I'm quite satisfied with quality it produces.

Also I think having lowpass at 18.2 kHz will result in more data in bit reservoir, thus making overall better sound quality than 3995o with no lowpass at all (-Q0). Correct me if I wrong.

Quote

The MP3 format has difficulty storing content above 16 KHz without sacrificing quality and increasing the bitrate requirements of the lower frequency bands.

So, the lowpass at 22.1 kHz (3995o -Q0) is an overkill. We cannot hear such high frequencies, anyway.

Quote

The MP3 format has a technical limitation that forces a trade-off: the more accurately the highest frequency band (16 KHz and up, normally) is encoded, the greater the space required to encode the lower frequency bands with similar quality. In other words, if the highest frequencies are preserved well, the quality of the much-more audible lower frequencies is sacrificed, and the bitrate has to be increased significantly to compensate, and it might not always be possible to fully compensate because of the 320 kbps limit on bitrate.

I think the main issue is that after the 3.99.5 release the main SVNbranch (trunk) has been (mis-)used a a feature branch for someimprovements to the psycho-acoustic model. However, these improvementsnever really took off, the changes were rather considered asregressions and after the main developer lost time (and/ot interest?),nobody really dared to touch that code.

Then came the first patches and fixes addressed at the 3.99.5 releaseand were applied on top of the current development state, but nobodydared to do the overdue point release because of all the other changesto the code [1]. As such, the code wasn't touched at all anymore,because it couldn't get released as is and no preparations were evermade to do a point release with minimal changes to the previous one.

This is at least how I perceived what has happened. However, thisdoesn't mean that it really was like this.

Said that, that talk has spuried some changes (security related mostly) that are being done over 3.100.

IMO lame3995n was a major step forward compared to former versions (and lame3995o is different only for -Q values of 1 or similar).However as you use the highest VBR bitrate setting this probably doesn't mean any audible difference.

But if it is only the lowpass you care about maybe I can bring some relief to you by mentioning that Lame3.99.5 (original as well as my variants) demands only for a very limited precision in the 16+ kHz range compared to the more audible ranges. I guess that's why the lowpass value is that high when using -V0. So it can't happen that a lot of bits are 'wasted' eventually.But there's also no reason not to simply use the --lowpass 18.2 switch in case you prefer this.

If you care a lot about the bit reservoir it may be wiser to use a somewhat lower -Q value like -Q1 or similar. I use -Q1, but after having tried opus I would even go lower. With opus as well as lame3995o it is only harpsichord music which requires an (otherwise inadequate) very high bitrate setting. Everything else is perfectly encoded when using lame3995o -Q1.7, and there is even a certain safety margin with this. I do not struggle any more for a general encoder setting which gives perfect results for any kind of music. I can easily do so as harpsichord music isn't exactly my favorite genre. Moreover even the worst harpsichord sample I know is well acceptable when using -Q1.7, and I guess -Q1.7 is perfect for many a harpsichord music. And I can always use -Q0 for the few tracks with dominating harpsichord music I have. I don't have a reason to reencode my collection, but if I had to I'd use -Q1.7 (200 kbps on average for pop music).

I'm sorry you have this problem.I have no idea why Norton behaves like this. I just had virustotal check lame3995o online using 64 antivirus tools and none of these had a complaint. Norton unfortunately is not among these 64 tools.