Hydrogenaudio Forums

Lossy Audio Compression => MP3 => MP3 - Tech => Topic started by: halb27 on 01 June, 2016, 05:41:07 PM

Title: lame3995o
Post by: halb27 on 01 June, 2016, 05:41:07 PM
lame3995o is based on the fact that the lame3995n -Q1.7 quality is excellent to my ears and for all the music I tried except for the harp40_1 sample.
So it was a promising strategy for me to use the -Q1.7 quality parameters as a basis and optimize them for harp40_1 at -Q1.
I did that, created a new version lame3995o, and arrived at the following ABC/HR results:

Compared to lame3995n lame3995o's different bahavior concerns the -Q values above 1.7. The main effect is between -Q1 and -Q0.5, The differences stop at -Q0.

You can download lame3995o from here (http://www.horst-albrecht.de/misc/lame3995o.zip).
Title: Re: lame3995o
Post by: LedHed8 on 05 July, 2016, 12:17:49 AM
Hi halb27.  I've been using -Q1 on my standard playlist for the past month, and have not noticed any quality issues under normal listening conditions.  As I get more time later in the summer, I will try a few ABC/HR tests on a few select tracks from my collection.  As a bonus, -Q1 uses less bitrate than standard LAME -V 1 does for my playlist.  Thanks again for your continuing attention and refinement to your fork of LAME.
                                                                 Best Regards,
                                                                                       LedHed8
Title: Re: lame3995o
Post by: halb27 on 05 July, 2016, 09:56:15 AM
Thank you for testing lame3995o. I'm looking forward to your ABC/HR results.
Horst
Title: Re: lame3995o
Post by: soundping on 05 July, 2016, 05:53:58 PM
I've noticed an audio distortion with lame3995o.
I ripped Billy Joel's song "Piano Man" and in the line "Sing us a song you're the piano man" the 'S' in sing distorts.

I'm using -Q0 setting in foobar. The CD is Billy Joel - The Essential Billy Joel 3.0
Title: Re: lame3995o
Post by: includemeout on 05 July, 2016, 10:58:37 PM
[...] in the line "Sing us a song you're the piano man" the 'S' in sing distorts.
A little reminder:
Publishing your ABX tests's results (and if anyone would be interested, uploading a small sample of that passage) would be, as you'll probably recall, more in agreement with some of this community's TOS's - more specifically, TOS 8 (https://hydrogenaud.io/index.php/topic,3974.html#post_tos8).
Title: Re: lame3995o
Post by: halb27 on 06 July, 2016, 04:28:41 AM
@soundping:
I also welcome if you could send a sound snippet of the critical spot so that I can have a look what's going wrong.
Title: Re: lame3995o
Post by: david-lisb on 08 July, 2016, 12:41:21 PM
How to use lame3995o in foobar2000 ?
Title: Re: lame3995o
Post by: halb27 on 08 July, 2016, 01:40:57 PM
You create a commandline encoder setting like this:

(https://hydrogenaud.io/imgcache.php?id=d07002423a288c3cdc23849d7e22c6a2" rel="cached" data-warn="External image, click to view at original size" data-url="http://dl.getdropbox.com/u/2681777/Lame3995o/foobar_lame3995o.jpg)
Title: Re: lame3995o
Post by: david-lisb on 09 July, 2016, 02:58:58 AM
thanks :)
Title: Re: lame3995o
Post by: david-lisb on 09 July, 2016, 07:46:16 AM
i will convert my files today with Q0.
With this bitrate (317-318 kps), it's better than cbr320 ?
Title: Re: lame3995o
Post by: halb27 on 09 July, 2016, 05:20:48 PM
I guess for 99.99 percent of the music everything will be perfect no matter your choice.
I haven't tried recently but I guess the critical spot at sec.  ~3 of problem sample eig is in favor of lame3995o - Qx (it doesn't take - Q0).
Maybe there's a difference also for problem samples lead_voice or harp40_1. You can find out yourself. After all it's your ears that count.
Title: Re: lame3995o
Post by: LedHed8 on 24 July, 2016, 12:53:20 PM
I've noticed an audio distortion with lame3995o.
I ripped Billy Joel's song "Piano Man" and in the line "Sing us a song you're the piano man" the 'S' in sing distorts.

I'm using -Q0 setting in foobar. The CD is Billy Joel - The Essential Billy Joel 3.0

@soundping. Is the distortion you are hearing on the 1st chorus at about the 1:26.7 mark?  If so, I'm not able to hear a difference.  I have the same version from the 3.0 edition.  I've tried to abx on lower quality settings of 3995o, 3.99.5, and 3.98.4 versions down to V5 with no success.  In the past, I've been pretty sensitive to sibilant S distortions, so perhaps my hearing has worsened.  Then again, I hear an identical slight distortion in the 'S' in the FLAC and MP3 encodes.

Best regards, LedHed8
Title: Re: lame3995o
Post by: includemeout on 27 July, 2016, 07:17:47 AM
I've noticed an audio distortion with lame3995o.
I ripped Billy Joel's song "Piano Man" and in the line "Sing us a song you're the piano man" the 'S' in sing distorts.

I'm using -Q0 setting in foobar. The CD is Billy Joel - The Essential Billy Joel 3.0

@soundping:
I also welcome if you could send a sound snippet of the critical spot so that I can have a look what's going wrong.

After all these days, will you kindly finally pass the baton of burden of proof, @soundping  , please?

EDIT:
To the admins/mods: I've just realized that neither halb27 nor me couldn't actually refer to soundping (member=96900) in our posts, since whenever we both typed "@soundping" in our replies, the editor has interpreted it as 'sound' (member=57038) - who is a totally different member - even when I at least, confirmed it by clicking on the right name in the drop-down list that pops out.

PS: Though it may be us doing something wrong, as @LedHed8  managed to do it properly. :-\


Title: Re: lame3995o
Post by: kode54 on 27 July, 2016, 03:02:27 PM
EDIT:
To the admins/mods: I've just realized that neither halb27 nor me couldn't actually refer to soundping (member=96900) in our posts, since whenever we both typed "@soundping" in our replies, the editor has interpreted it as 'sound' (member=57038) - who is a totally different member - even when I at least, confirmed it by clicking on the right name in the drop-down list that pops out.

PS: Though it may be us doing something wrong, as @LedHed8  managed to do it properly. :-\

You may mention members manually using the member=id# BBCode tag. For an example, quote the posts. It's a pain, but it works. I'll report this to ElkArte forum as a bug, or misfeature.
Title: Re: lame3995o
Post by: soundping on 28 July, 2016, 11:50:22 AM
I'm back online.

Tonight I'll make samples and post them.
Title: Re: lame3995o
Post by: soundping on 29 July, 2016, 12:08:41 AM
The original file is gone now. I re-ripped the track and the "S" distortion sound isn't there now.

Title: Re: lame3995o
Post by: includemeout on 29 July, 2016, 08:38:04 AM
The original file is gone now. I re-ripped the track and the "S" distortion sound isn't there now.
Well, I'll be damned...
Title: Re: lame3995o
Post by: soundping on 31 July, 2016, 06:27:27 PM
I made some test audio samples from 3995o.
The 30s source file is from a burn-in track sample.

Code: [Select]
https://mega.nz/#F!aEE3GQaa!kdDsaq5Pn4ycccPsZLBUwA
The source file is there and copies from settings -Q0, -Q0.5 and -Q1.
Title: Re: lame3995o
Post by: halb27 on 01 August, 2016, 05:05:12 AM
I compared the flac with the -Q1 file and didn't notice a difference.
Is there an issue with one of the encoded files?
Title: Re: lame3995o
Post by: soundping on 01 August, 2016, 05:42:37 AM
I didn't notice any problems. I was hoping someone else would test them out.
Title: Re: lame3995o
Post by: includemeout on 01 August, 2016, 06:52:34 AM
I didn't notice any problems. I was hoping someone else would test them out.
Why bother if, as you were plain honest to admit, you couldn't detect anything wrong with said sample the second time around?

In my view, that was a simple case of claiming you'd found a problematic sample and then disproving it with (I hope) blind testing, afterwards.

Anyway, thanks for clarifying that.
Title: Re: lame3995o
Post by: david-lisb on 02 October, 2016, 07:29:00 AM
The cutoff frequencies are not the same with Vx and Qx ?
Title: Re: lame3995o
Post by: halb27 on 03 October, 2016, 01:41:32 PM
No they aren't. cutoff of -Qx is somewhat lower than that of -Vx.

The background for this is as follows:

-Vx internally uses a number of parameters controlling the accuracy of lossy encoding.
Lame has no real idea what a setting of these parameters has to be chosen in a specific situation for the music to be transparent.  That's why these parameters are static.
Sure these static parameters are carefully chosen so that usually music is fine even with -V5.
A higher quality -Vx setting means these parameters are chosen more restrictive so hat the deviation from the original is lower.  This way the probability of getting a transparent result increases. This is kind of a brute force quality management.

My -Qx quality setting works a bit different.
-Q1 for instance internally uses the accuracy parameters of -V3 as a quality basis. This gives the headroom for a dynamic quality management. For the known issues of very tonal problem samples as well as harpsichord music I derived criteria where audio quality is increased in a musical situation when lame3995o thinks this is necessary. This is a more selective approach than that of -Vx. (But don't think it is a very intelligent mechanism.  In order to have a strong effect on various problem samples I still had to do things in a pretty much brute force way).

I don't touch the lowpass anymore which is a function of -Vx, in case of -Q1 that of the underlying basic -V3.
If you prefer another lowpass, use the --lowpass setting.
Title: Re: lame3995o
Post by: david-lisb on 12 October, 2016, 02:44:25 PM
average kps of Q0 is 317 ...
So, better is -Q0 or CBR 320 ?
Title: Re: lame3995o
Post by: halb27 on 12 October, 2016, 06:02:40 PM
Probability is close to zero that you would notice any difference.
Problem sample lead-voice is a promising candidate for finding a difference, maybe also harp40_1.
Title: Re: lame3995o
Post by: john33 on 16 October, 2016, 09:07:25 AM
Better late than never!! ;)

64bit Intel compile: www.rarewares.org/files/mp3/lame3995o-x64.rar (http://www.rarewares.org/files/mp3/lame3995o-x64.rar)
Title: Re: lame3995o
Post by: halb27 on 17 October, 2016, 04:27:39 PM
Thanks a lot, John.
Title: Re: lame3995o
Post by: KinG-KanG on 23 October, 2016, 07:06:52 AM
Long time no see.
Great news from @john33.

@halb27, where i can get your source?
I want to try build it with vs-2015 or gcc 6.2.
I think there is some math in your source.
Maybe I can build it with sse 4 caps.
Title: Re: lame3995o
Post by: halb27 on 23 October, 2016, 07:49:24 AM
The changes towards original Lame are in my download file (http://dl.getdropbox.com/u/2681777/Lame3995o/lame3995o.zip).
I got the original Lame source from here (http://lame.cvs.sourceforge.net/viewvc/lame/lame/?view=tar).
Title: Re: lame3995o
Post by: KinG-KanG on 23 October, 2016, 08:28:25 AM
I forgot to check your zip.
I though it only contain binaries.

Thanks.
Title: Re: lame3995o
Post by: doom-drone on 02 February, 2017, 05:26:43 AM
Love this Lame mod fixes few artifacts i that say at 320k. I can walk with my stuff at V2 or Q2. 


Title: Re: lame3995o
Post by: SPV82 on 12 February, 2017, 01:45:23 AM
Can anyone help how to build this mod on Linux? With which IDE or build-system?
Title: Re: lame3995o
Post by: nastea on 12 February, 2017, 01:22:01 PM
Bug?

(https://hydrogenaud.io/imgcache.php?id=ba900ebfbcd5be0c689f7314a68da0e9" rel="cached" data-warn="External image, click to view at original size" data-url="http://i.imgur.com/UVOVmof.png)
Title: Re: lame3995o
Post by: halb27 on 12 February, 2017, 03:12:46 PM
Impossible to say without knowing about test.wav. Can you provide it?
How does original Lame3.99.5 behave? Using -V6 (not the target quality of lame3995o) lame3995o should behave more or less like original Lame.
Do you have mp3packer.exe in the folder of lame3995o.exe?
Title: Re: lame3995o
Post by: nastea on 12 February, 2017, 10:22:46 PM
test.wav is just a normal audio wav file, ripped from a cd.
Lame 3.99.5 encodes test.wav to a vbr mp3 file, somewhere in the range of 112 kbps, as expected.
I don't have mp3packer.exe at all, do I need it?
Title: Re: lame3995o
Post by: halb27 on 13 February, 2017, 01:47:04 AM
One of the lame3995o features is to keep the bit reservoir at maximum in order to locally allow for the highest bitrates when necessary. This can result in a lot of 320 kbps frames which are not necessarily filled with audio data. mp3packer squeezes the 'air' out of the mp3 file. So I do recommend to use it. It is used from within lame3995o automatically if you put mp3packer.exe into the folder where lame3995o.exe is.
Title: Re: lame3995o
Post by: halb27 on 04 March, 2017, 03:17:14 PM
In a few days there won't be public folders any more in DropBox for easy distribution of files.
That's why I have moved lame3995o to my own webspace (which I had to put up last year because DropBox couldn't be used for web content any more).

So you can download lame3995o now from http://www.horst-albrecht.de/misc/lame3995o.zip (http://www.horst-albrecht.de/misc/lame3995o.zip)
Title: Re: lame3995o
Post by: halo001 on 17 April, 2017, 03:04:43 AM
(https://jfgvsw-sn3302.files.1drv.com/y4pDWUrms5ewK5MncXUUvdyPraURRthMLaJDzuk5AdnSrX_NyY5Mzc9J3o7LvyfhnYleh1xf1GbHUY9HRLQAdzfmbQr4zJDADH_htdsrGJJgi2ZCHdHbwF7i1wtyEsgAqR1beZiTpL6EsuOQiota_3m-P5SinzZOib5xQvrQPocCvV2jOYn0nQ3ucDsro_mXlgIur1ytvZ89iC0BZCHVTwXZA/Bug.png?psid=1)

Need help with this. I've encoded a flac file using lame3995o and find something strange. The file is somewhat larger than expected.
Title: Re: lame3995o
Post by: halb27 on 17 April, 2017, 03:59:59 AM
The reported codec profile is V1 which means you probably used either -V1 or -Q1.
With this 215 kbps is normal, for lame3995o as well as for standard Lame 3.99.5.

In case your filename means you encoded using - Q1.7 215 kbps is more than the average ~200 kbps bitrate of - Q1.7. But that's what VBR is meant to do. If you encode say 20 tracks of various pop music, you should get an average bitrate of ~200 kbps. But every single track will deviate from that more or less.
Title: Re: lame3995o
Post by: duda_dallana@hotmail.com on 10 May, 2017, 06:23:33 AM
You create a commandline encoder setting like this:

(https://hydrogenaud.io/imgcache.php?id=d07002423a288c3cdc23849d7e22c6a2" rel="cached" data-warn="External image, click to view at original size" data-url="http://dl.getdropbox.com/u/2681777/Lame3995o/foobar_lame3995o.jpg)

Hi ! How to create a commandline for lame 3995o into foobar2000?
Is necessary to add "-mj" joint stereo information for "-q0 ir -q1" settings?
Thanks and Regards !
Dallaed
Title: Re: lame3995o
Post by: halb27 on 10 May, 2017, 10:11:39 AM
You create a commandline encoder setting like this:

(https://hydrogenaud.io/imgcache.php?id=a09f5157ad8e2a1001e681decfed5196" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.horst-albrecht.de/misc/foobarCLI.jpg)

I have no experience with -q or -m and personally wouldn't touch the defaults.
Title: Re: lame3995o
Post by: duda_dallana@hotmail.com on 10 May, 2017, 10:21:20 AM
Hi !!! Halb27 thank you for your clarification !!!

Regards !!!
Title: Re: lame3995o
Post by: SPV82 on 01 June, 2017, 02:51:04 AM
Hi, halb27!
I'm trying to build with gcc on Linux and would like to find out what a difference if compile lame3995o with no changes to files:
Code: [Select]
frontend/lame_main.c
frontend/main.c
frontend/main.h
The question at issue is that the compilation finishes well if these files keeps unchanged, otherwise it fails apparently due to Windows related code.
Thanks! (sorry, my English not so well)
Title: Re: lame3995o
Post by: halb27 on 01 June, 2017, 03:44:27 PM
I'm not sure whether I understand you correctly.
Is this true?:
a) If you compile with all my modified files (21 files), your compilation fails.
b) If you use the original lame_main.c, main.c, main.h, but all of the other 18 files according to my modifications, your compilation is successful.

As for a) what does 'compilation fails' exactly mean?
Title: Re: lame3995o
Post by: SPV82 on 02 June, 2017, 10:49:15 AM
Hi, halb27

a) Yes, it is. Compilation fails because of use windows related header files
 Spoiler (click to show/hide)
When I add if condition:
Code: [Select]
#if defined(_WIN32)
#include "process.h"
#include "windows.h"
#include <ShellAPI.h>
#endif
compilation fails with error:
Spoiler (click to show/hide)

b) Yes, in this case compilation finishes well and resulting lame binary works. I would like to know is there a difference if use this binary (18 modified files only)?
Title: Re: lame3995o
Post by: [JAZ] on 02 June, 2017, 03:18:44 PM
I've checked the source code, and you will be missing two things:
One is the option to define the parameters on a shell variable ( xxx = a;  export xxx ). The other is the automatic execution of mp3packer at the end.

The effect of not executing mp3packer is that the files will be bigger than needed. One of the features of this fork of LAME is that it works in a way that tries to maximize at all times the amount of space that is available to the encoder, and if it wasn't needed, mp3packer just strips it off.

The code at the end of main.c is what would need to be implemented in a posix way in order to compile in linux, and also you would need mp3packer. Probably it's easier to build a shell script that executes mp3packer after LAME.
Title: Re: lame3995o
Post by: halb27 on 02 June, 2017, 05:13:32 PM
[JAZ] did it first, but I've also looked up the source files and can only confirm what [JAZ] said.
If you don't use my main.c, main.h, lame_main.c you don't call mp3packer at the end. And yes, this part is windows-specific and certainly not well-implemented from a developer's point of view.
I'm sorry but you have to do the mp3packer part on your own. If that's a problem you can use mp3packer on its own. Before I integrated it into my Lame variants I always used m3packer after encoding all my tracks (one step for all the files in a folder).

Depending on your lame3995o usage it may also be the case that mp3packer isn't much of an advantage. But I'd definitely compare with/without mp3packer usage,
Title: Re: lame3995o
Post by: SPV82 on 03 June, 2017, 01:21:44 AM
If I understand correctly, the changes in lame_main.c, main.c, main.h files are only for mp3packer usage. If I don't use mp3packer I can leave these files unchanged. Thanks for your answers.
Title: Re: lame3995o
Post by: SubV on 14 August, 2017, 02:58:35 PM
The original download link for lame3995o.zip is dead now.

Please re-upload. Thanks in advance.
Title: Re: lame3995o
Post by: SubV on 14 August, 2017, 04:14:52 PM
halb27, another question.

Are these 64-bit builds by john33 are identical to yours in terms of quality of sound?

Because the 64-bit code uses the SSE2 vector instruction set by default and may handle the floating point operations differently.
Title: Re: lame3995o
Post by: halb27 on 15 August, 2017, 03:25:36 AM
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.
Title: Re: lame3995o
Post by: SubV on 15 August, 2017, 11:09:50 AM
Thank you.

I've noticed that files encoded with your lame3995o have a higher lowpass. Or no lowpass at all?

Here's my encoding settings. And the same file that was encoded with your old lame3100m. Click on thumbnails to enlarge.

(https://hydrogenaud.io/imgcache.php?id=31c7d0118f66b5f8b5ed4e854c33b1e9" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.pictureshack.net/images/46348_0001.png) (https://hydrogenaud.io/imgcache.php?id=1cb9dedd66b44d2501f460b756ddf0b5" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.pictureshack.net/images/42530_0002.png)

(https://hydrogenaud.io/imgcache.php?id=502e5fc6372f357c54153360f1d847ed" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.pictureshack.net/images/2490_0004.png) (https://hydrogenaud.io/imgcache.php?id=9b2c24391a4dc219d7bcc55f757caa0b" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.pictureshack.net/images/86592_0003.png)

(https://hydrogenaud.io/imgcache.php?id=eeb75082f5e45dd8c132750318e9395e" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.pictureshack.net/images/70734_0006.png) (https://hydrogenaud.io/imgcache.php?id=324de047c40295294be12d64b3e66f0c" rel="cached" data-warn="External image, click to view at original size" data-url="http://www.pictureshack.net/images/11184_0005.png)

Is this normal? I think the lowpass value of 22.1 kHz (-Q0) is not good.
Title: Re: lame3995o
Post by: halb27 on 15 August, 2017, 03:28:23 PM
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).

If you prefer another lowpass just use the lowpass option.
Title: Re: lame3995o
Post by: SubV on 19 August, 2017, 06:09:15 AM
Thank you again.

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.
Title: Re: lame3995o
Post by: [JAZ] on 19 August, 2017, 06:26:03 AM
About lame 3.100...
From  URL (https://sourceforge.net/p/lame/mailman/message/35974173/)
Quote
I think the main issue is that after the 3.99.5 release the main SVN
branch (trunk) has been (mis-)used a a feature branch for some
improvements to the psycho-acoustic model. However, these improvements
never really took off, the changes were rather considered as
regressions 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 release
and were applied on top of the current development state, but nobody
dared to do the overdue point release because of all the other changes
to 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 ever
made to do a point release with minimal changes to the previous one.

This is at least how I perceived what has happened. However, this
doesn'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.
Title: Re: lame3995o
Post by: halb27 on 19 August, 2017, 10:52:59 AM
What do you think? Is it still okay to use lame3100m?
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).
Title: Re: lame3995o
Post by: halb27 on 03 September, 2017, 12:54:36 PM
I  was allowed to update the link to lame3995o in the OP.
Done.
Title: Re: lame3995o
Post by: peter312 on 06 September, 2017, 04:09:41 PM
I downloaded an installed lame3995o only for Norton to automatically delete it as it was apparently a risk. Has anyone else had such a problem?

Many thanks
Title: Re: lame3995o
Post by: halb27 on 06 September, 2017, 05:17:03 PM
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.
Title: Re: lame3995o
Post by: kode54 on 06 September, 2017, 08:19:26 PM
Strangely, on VirusTotal, Symantec says it's clean. Submit a false positive to them?
Title: Re: lame3995o
Post by: john33 on 07 September, 2017, 06:11:30 AM
I gave up using Norton many years ago because of frequent false positive issues.
Title: Re: lame3995o
Post by: GeSomeone on 05 December, 2017, 10:53:56 AM
Now a (stable) Lame 3.100 has been released (https://hydrogenaud.io/index.php/topic,114777.0.html), would it make sence to create a new lame3100x ? (just backport the fixes of LAME3.100 I guess).

BTW AFAIK there were no quality changes, but some security and buffer issues.
Title: Re: lame3995o
Post by: halb27 on 05 December, 2017, 04:51:22 PM
ATM I have very serious health problems.
So this may be a question to me later next year.
Title: Re: lame3995o
Post by: john33 on 05 December, 2017, 05:01:10 PM
Sorry to hear that. May I wish you a speedy and full recovery.
Title: Re: lame3995o
Post by: eahm on 05 December, 2017, 06:07:12 PM
Sorry to hear that. May I wish you a speedy and full recovery.
Same, hope you get better soon.
Title: Re: lame3995o
Post by: halb27 on 06 December, 2017, 03:30:36 AM
Thanks a lot.
Title: Re: lame3995o
Post by: Thundik81 on 06 December, 2017, 07:10:09 AM
Get well soon. Wishing you a speedy recovery!