If I'm not mistaken, according to likeloo's brilliant ESSENTIAL Ripping Giude once the "Additional command line options" for LAME are configured in EAC (as "--alt-preset extreme" in my case), the "Bit rate" and "High/Low quality" ones aren't considered:

But having a look at the produced MP3's with Mr. QuestionMan 0.6 it reports the switches used as "[alt-] preset extreme -b 224 (modified)" instead of simply "[alt-]preset extreme (guessed)" (like for those compressed with RazorLame 1.1.5 with "Custom options: --alt-preset extreme" and "Only use custom options" selected).
Is it simply a matter of bogus LAME header tag or does EAC actually modify the "--alt-preset extreme" switch with "-b 224"?

Edit: typos.

The result you are seeing in MrQ surprises me, as I would only expect this to appear if LAME MP3 Encoder is selected as the Parameter Passing Scheme in EAC, but your screenshot shows that you have User Defined Encoder selected, which should exclude the EAC bitrate and quality settings.

Are you sure that you did not have LAME MP3 Encoder selected when you ripped the tracks that are showing the modified preset in MrQ?

Anyway, if you did have Lame MP3 Encoder selected it doesn't really matter because as you have guessed with currently available versions of LAME it simply causes an incorrect LAME tag, but the audio data will be identical to the standard preset. MrQ has to report the modified preset, because it only uses the LAME tag to determine the preset, and from that point of view there is no way to distinguish between these files and ones where the preset is genuinely modified with a different bitrate.

Well the screenshot comes from likeloo's guide, not my system, and I actually have "LAME MP3 Encoder" selected as "Paramter passing scheme", I did that to be able to omit "%s" and "%d", is that silly on my part?

Also, since you say that has only affected the LAME tag but hasn't modified the preset to any extent, is there a way/tool to modify it without corrupting the header/MP3 in any way or having to re-encode from WAV/CD?

Last but not least, thanks a lot for your help, you hit the nail on the head right away.

Edit: more typos.

hmm, this is odd. I checked my files with Mr. Question Man and it doesn't say anything about -b switches or anything modified...just the --presets.

I used LAME 3.96 as well LAME 3.96.1 setting EAC to use LAME as 'mp3encoder' as well as 'User Defined'...maybe you made some other mistake...

I'm using LAME 3.90.3, could that be it?

What does Mr. QuestionMan report for yours file? "[alt-]preset *chosen preset* (guessed)"?

Edit: still typing too fast...

hmm, when using "LAME MP3 Encoder" you don't have to use %s and %d. That's probably the mistake.

However, I'd select 'User Defined' and use %s and %d. I use LAME 3.96.1 and when you select "LAME MP3 Encoder" it uses -q2 instead of -q3, which is now the --preset standard setting. So the best is to set EAC to 'User Defined' and add %s and %d at the end of every command line. Try that and see if the problem still exists!

no, it just says "V2: preset standard" - in both EAC settings...try what I described in my previous post

I used "LAME MP3 Encoder" without "%s" and "%d" (omitted them).
I'm trying with the suggested config in a matter of minutes.

Okay, now with "User Defined Encoder" as the Parameter Passing Scheme and "--alt-preset extreme %s %d" as Additional command line options" (using LAME 3.90.3) I get "[alt-]preset extreme (guessed)" from Mr QuestionMan 0.6, so is there anything wrong with the "(guessed)" part? Anyone knows why it ends up in the LAME tag?

More recent versions of Lame including 3.96.1 write the preset into the Lame tag, so MrQ reports that. Older versions including the "stable bundle" 3.90.3 build from Rarewares do not write the preset into the LAME tag, so MrQ has to guess it based on other values in the LAME tag. This is why it says guessed. If you want the preset to be written but want to use 3.90.3 then you can acheive this by using the "modified bundle" 3.90.3 from Rarewares as this is one of the enhancements in it.

that (guessed) part doesn't end up in the LAME-Tag...Mr. Question Man adds that since it is not sure if that setting has been used...this might be a bug though. I have some files that show up as "guessed" using --alt preset standard and LAME 3.90.x and others don't ...looking at the LAME-Tag I couldn't find anything that would indicate such a behavior since the TAG was indentical...maybe you could ask the developer of Mr. Question Man and let us know

This problem doesn't occur with LAME 3.96.1 though...and that's what I'm using

Just tried the LAME 3.90.3 Modified bundle off RareWares, phwip is right on the money again , I think that explains the funny behaviour mentioned by Jojo, although it's pretty strange the LAME tags of files that show up as (guessed) are identical to the others.

Thank you very much to both for your help, that was quick and insightful !

Edit: grammar.

One last thing: is there a way/prog to modify the LAME tag harmlessly or at least to remove it?
I've already ripped + encoded several CD's with the wrong config and wouldn't like to have to do them all again.

As far as I know there aren't any tools to modify the LAME tag. The LAME tag contains two CRCs, one of the audio data and one of the LAME tag itself. So to do the job properly any application that modified it would need to not only change the bitrate field in the LAME tag but also the CRC of the LAME tag to reflect the new data. I don't think there are any tools to do this.

And if you remove the LAME tag then you lose information which might be valuable - for example, if you use foobar2000 it reads the Encoder Delay values from the LAME tag in order to play gaplessly. If it was me I would just stick with it like it is: you know why the wrong preset is being reported and the actual audio data is just fine.

Just can't live with it... tried to bring me to but can't... alerady re-ripping+encoding...

Many thanks for the info and help anyway.