Those are the only settings that give me a quality index of 100 in EncSpot Pro. No preset setting gives me that.

Those are the only settings that give me a quality index of 100 in EncSpot Pro. No preset setting gives me that.

For a few years I've been encoding my files using CDEx v1.51 as a frontend for LAME 3.92. I know that most of you advocate using the presets, but I stick to the following settings for LAME, no matter if they are overkill or take longer to encode (and will continue to do so):

The settings you chose are equivalent to --preset fast extreme -q0, so you ARE using the presets. There are no non-preset settings from Lame 3.95.1 onwards, everything is internally mapped to them.

Ignorance is a bliss.

Now if everything is internally mapped now, passing parameters such as -b for VBR lower bitrate limit is ignored by the codec?

AFAIK, it depends which parameter (some are ignored entirely) and sometimes in which order it is sent to the encoder. So,
-b 32 -V0
may be different than
-V0 -b32
I think in the first case the -b32 is ignored, but not in the second. Since you use a frontend and not command line, you never know how CDex sends the settings to the Lame.dll

Just tried that one via the command line, -b32 was taken into consideration by the codec in both cases.

Very helpful comment indeed .

Then help yourself by taking the excellent advice and knowledge given to you by HA.org and it's members; such as those "crazy" LAME preset things (or better still the -V settings: see here).

For a few years I've been encoding my files using CDEx v1.51 as a frontend for LAME 3.92. I know that most of you advocate using the presets, but I stick to the following settings for LAME, no matter if they are overkill or take longer to encode (and will continue to do so):



Those are the only settings that give me a quality index of 100 in EncSpot Pro. No preset setting gives me that.

My question is: I've just replaced the 3.92 DLL in CDEx by the 3.96.1 DLL, and when reencoding some files I was surprised to notice that the average bitrate increased by about 50 Kbps in most of them compared to the 3.92 encoded version with the exact same settings. Is this because of the new Huffmann technique used for q=0? I'm leaving audio quality perception issues aside here, I just want to know the technical reasons why the average bitrate increased.

The other changes reported by EncSpot Pro were:

LAME 3.92: average reservoir=71, lowpass filter=20600, psycho-acoustic model=gpsycho, safe joint stereo=no

LAME 3.96.1: average reservoir=76, lowpass filter=19500,  psycho-acoustic model=nspsytune, safe joint stereo=yes

I didn't see a LAME switch (in the docs) for changing the joint stereo mode to safe. Is this a post-3.92 default feature, and maybe the responsible for the higher average bitrate?

They increased because 3.96.1 has different tunings compared to 3.92. Did you notice any quality compromise between 3.96.1 and 3.92? Don't pay much attention to what Encspot throws back at you, instead pay attention to what your ears tell you.

Your attitude is not helping either. The problem is that your comments show that you really don't have a clue about LAME internals, otherwise you would not use the settings you are using with LAME 3.92. You think that your custom settings are *the best* but in fact you are probably just hurting the quality of your MP3 files. Apparently you are not willing to change your mind, even when more experienced people reply to you.
(...)
If you don't want to believe, just use your super-ultra custom setting and stop wasting people's time.

For a few years I've been encoding my files using CDEx v1.51 as a frontend for LAME 3.92. I know that most of you advocate using the presets, but I stick to the following settings for LAME, no matter if they are overkill or take longer to encode (and will continue to do so):

(59 kB image)

So basically you have to use -q0 and -V0 to get 100, but you could do something retarded like -q0 -V0 -B32 --disable-ath or whatever and it would still register 100

Another thing about that quality index... q3 in 3.95+ is the same as q2 in lower versions (because they added a new q0 above the old one).

I guess that must be main reason for the higher bitrate with q0 in 3.96.1. Great info, thanks.

No, you can try with q=3, the size will be about the same.

Do you know if that "safe joint stereo" indicator in EncSpot is valid? It shows "no" for 3.92 and 3.93.1 files, and "yes" for 3.96.1 files.

I've noticed that most albums encoded in --preset standard at least are smaller with 3.96.1 over 3.90.3, but a few (anything by The Cure, for some reason) get WAY bigger.

Calm down dears 

In cdex (if I can remember correct, which is seldom the case) there is a setting to do with external encoders. Use lame as an external encoder and cdex will stop messing with the settings.

(Going out on a lim) I think Lame 3.93.x and onwards save the settings in the lame tag differantly it some differantly in encspot.

I've been unable to get CDex to work with Lame 3.96.1 or 3.97 Alpha as an external encoder.  They both work as INTERNAL encoders when their respective lame_enc.dll file is placed in the CDex folder.