Hi guys,

this is my first post here in these forums so I hope the phenomenon I'm going to talk about is no newbie stuff or overly-discussed already.

Here's the problem: for some completely incomprehensible reason (at least for me) EAC (0.95b4) combined with LAME (3.97b2) and the command line options "-V 0 --vbr-new" yields mp3 files that lack a first and last frame and are completely encoded in 192 kbps, except for 2 frames, but only for some certain audio tracks (directly from the cd), for most it works fine.

In the course of my efforts to solve that problem I have found out that for these particular tracks EAC seems to disregard the command line options and uses the bitrate option below them instead. It seems to disregard any other option as well, as my tag settings for example. If I change the bitrate option from vbr 192 to, say, vbr 160, it disregards all options none the less, but now there are no frames missing and the files seems to be proper vbr files (without the command line options of course).



Does this make any sense to anyone of you? I tried LAME 3.90.3 for these tracks, and it works fine.

I really hope somebody can give me some advice on that, as I will have to fall back on LAME 3.90.3 if there's no solution.

Check the option "Bit rate " in EAC and change it for 128 in this case it can change the routine of bitrate if for example you put it on 320 kbits you will 320 CBR files.

Hi Attila,

That's certainly a strange problem. If you haven't already done so, you may want to check out the HA wiki page on using EAC & Lame.

I've been using 3.97b2 for some time now without any problems - I simply copied one of the command lines from that page and pasted it vebatim in EAC. According to the wiki, the bitrate setting in the pulldown is ignored unless you use the %r placeholder in your command line.

Hi again,

good stuff this, thanks Diow for your instant reply, I tested it thoroughly and came to the conclusion that my problem was that simple.

It just didn't occur to me that these bitrate settings had any impact on the coding, still don't get it a 100% why they do at all but the main problem is solved and that's what counts.

GREAT! Bye!

You should select a custom encoder in EAC as you are still currently limiting the bitrate to 128kbps and, as far as I know, it should not be limited at all.

Strangely enough the quality is pure vbr now, I am not limiting it. That's what I don't get about it. I don't know which version of EAC you are using, but in my version, German EAC 0.95b4, there is command line options, and directly below them there is the option called "bitrate", which I cannot check or uncheck, they're just there, even though I put in my costum encoder (LAME 3.97b2) there.

That's why I say I don't understand it, because I thought the bitrate setting is ignored as soon as command line options are set. And it really seems to be that way, because my mp3 files now seem to be absolutely proper vbr files, and trust me, I really would notice a difference in quality.

It would be nice if someone could confirm that.

Thanks for your replies

I can't confirm anything right now because I just realised that I still use beta3,
and there seems to be a difference at this point. I'm going to try beta4 and see what it does.
Did you check those files with something like Audio Identifier? What does it report?

Edit: and here's a nice german guide to configure EAC: http://www.audiohq.de/index.php?showtopic=47
you could compare those settings with yours or try it from scratch following this guide

Edit2: Just tested b4 with LAME 3.97b2 and it works flawless (used user defined encoder and the commandline as described in the guide).

If you use "LAME MP3 Encoder" as the parameter passing scheme the bitrate dropdown comes in to play. Setting it to 128kbps "fixes" it, as 128kbps is the default and therefore no -b switch is added. If you use "LAME MP3 Encoder" and set the dropdown to anything else the switch "-b XXX" will be added, which sets the minimum bitrate used.

You should really use "User Defined Encoder" and use a command line format as per the wiki article. This will ensure that only the command line is used. Ensure you have the %s and %d tokens in the command line.

Very good, now I get it. Thanks Hollunder for that guide, it really made everything clear to me. As described by Synthetic Soul with the bitrate setting 128 the resulting mp3 files are perfectly in order, I verified it with Mr. Questionman.

None the less I am thankful for all these pieces of advice and will change my settings to "user defined encoder" and use the command line options "-V 1 --vbr-new --id3v2-only --pad-id3v2 --ignore-tag-errors --tt "%t" --ta "%a" --tl "%g" --ty "%y" --tn "%n" --tg "%m" %s %d".

Well just to complete this, could someone tell me what all these switches are for, or give me some reference where I could look it up?

--id3v2-only --pad-id3v2 --ignore-tag-errors

These tell lame.exe to tag the resulting mp3 files with id3v2 tags only and to pad the id3v2 tags (a good thing).

--tt "%t" --ta "%a" --tl "%g" --ty "%y" --tn "%n" --tg "%m"

These tell lame.exe to take the metadata EAC has for the CD (either looked up by freeDB, entered manually) and map it to the appropriate id3 tag fields. So what you see in EAC is what you get for id3 tags.

%s %d

http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame

-V 1 --vbr-new

As per the LAME wiki page this will get you VBR files around the 225kbps mark, using the newer VBR model which has quite recently been deemed better (and faster IIRC) than the old model (although the LAME devs are still reticent to make it the default).

--ignore-tag-errors

The major benefit with this is that LAME won't terminate immediately, if it comes across a genre it doesn't recognise. Insstead, it will simply set the genre to "Other".

THANKS!