Anyone ever have the problem where EAC isnt like pulling lame correctly? I put the disk in, ive done all the settings as per this Forum. Iive got the latest eac and lame. It reads the file to a wav. Then it doesnt compress it with lame. Ive done everything I can think of. If i go to the commandline it will compress it just fine. I just cant seem to get it to do crap. This is the error I get from EAC when i try



ive moved lame to other folders. ive removed all options, still same error. Ive change options same basic error. like i said went to the command line and typed lame and all those options then the file names and it encodes just fine. its like eac cant find lame despite the fact ive put it in the box for external encoder.

I think Lame is stopping because Folk-Rock is not accepted by it, the genre I see in the EAC genres list is Folk/Rock. Try changing that and run it again.

Or add --ignore-tag-errors to your Lame command line.

That did it....

You know at first i was thinking you were just going to be giving me a hard time for having a folk/rock cd . I was like, this ass is making a comment on my music . But yup that got it, thanks a lot.

And i highly recomend Robinella and the CC Stringband. Not really folky, more blues'y / jazzy than anything else on this album. first album is a bit more country/ folky thats for sure

Don't worry we don't do that here (at least I don't), and welcome to HA

as the saying goes, long time listener first time caller.

ive read here for a loooooong time. mostly in the foobar forum tho. and anytime i have to format and reinstall eac to rip stuff. always have to get refreshed on settings

I've actually just had a similar problem. I've got EAC v0.95b4 (which I believe is the latest) and LAME 3.90.3 (will probably upgrade soon). I tell it to compress track via external program and point it to LAME . . . and during Test & Copy it shows "Compressing Track by External Program" but doesn't do it. Weirdest part is, no errors, no nothing. EAC seems to think LAME is doing it's job.

Here's the settings I'm using for LAME, incase I screwed these up:

--alt-preset standard --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tl "%g" --ty "%y" --tn "%n" --tg "%m" %s %d

If you want to use --ignore-tag-errors you will have to upgrade now; it is unavailable in 3.90.3.

I just fought hours with the same issue. After perusing these forums search function I came up with a solution: --ignore-tag-errors

Now LAME doesn't just flicker and shut down whenever it sees a genre tag not on its list, but it just gives the genre tag of 'Other' and continues.

I don't remember seeing this issue mentioned in the wiki. It might be helpful if it was added there.

Here's my EAC-->LAME command line pass-through for what it's worth:



I got all my CL info from this forum.

Thanx guys

The weird part was that LAME didn't flicker and shut down. It didn't even start. I am still kind of confuzzled. I'll upgrade LAME sometime tonight and see if that makes a difference.

Same here - I ruled out the "tag error" possibility (via the "--ignore-tag-errors" switch) and I'm using lame 3.97b2... Most CDs rip and compress fine but on some there remains a track which just stays as *.wav. Apparently (according to eac) those tracks have errors at the end of them but listening to them... well they don't have any audible errors (Also, I'm not sure if errors were found in all of these cases, luckily it doesn't happen too often so I can't remember the older results).

The ignored wav's convert to mp3 just fine when using all2lame i.e. doing it manually. The CDs are always barely used to brand new so there really should not be any significant errors on them.

The last time this occured was with the german version of the audibook Harry Potter 1 (it's for my girlfriend, not for me - SERIOUSLY). It actually happend 3 or 4 times with this new 9CD-Set.

Also EAC does not seem able to create a CRC for those tracks as it does not display one even after "test & copy". I'm pretty sure my eac settings are correct as everything works fine 99.8% of the time but this leaves me puzzeled.

Help is appreciated. Thanx, Phil

I had the same issues with two CDs last night. Just for the heck of it, uncheck all tagging options in EAC and try cutting and pasting this command line in the EAC\Compression options\External compression tab\'Additional command line options:' box to see if it helps. It worked for me with latest HA recommended versions of EAC & LAME.



Note: You might want to create a new profile in EAC to try this out.

Is there any special reason why are you using lame cmd-line parameters for tagging?
Why not just let EAC to do the job? Are there any disadvantages that i'm not aware of?

No special reason except that some of the HA recommended CLs just let LAME do it and said it was better than letting EAC do it.

Edit: I'll add that I didn't know what exact cmd-lines are passed with the EAC check boxes so I eliminated them and any potential problems they might be causing by unchecking and only relying on the LAME cmd-line string for tagging. The bottom line for me is that it now works on my troubled dics. The beauty of the cmd-line is the ability to fine tune the process just the way you like it. I tried only the '-V 2 --vbr-new --ignore-tag-errors' flag string with the EAC check boxes but it didn't work for me on two of my systems. On another system maybe it would have. There are so many hardware and software issues involved that it's well beyond my skill levels to fully know why.

Thanks for the answer but unfortunately that IS the command line I'm using:



V6 is for audiobooks and the rest is all there just in a different order. That can't be it can it? ( just gave the CDs away last night - not sure when I get them back so I can't try right now)

All tagging otions in EAC are unchecked also...

Ideas?

I also have the --noreplaygain flag but I can't imagine why that would be a factor in this case.

Strange it is... WELL, I guess I can/have to live with it. If there's some more time I might find the answer... Why do you use this flag (--noreplaygain)? Lame doesn't do any replaygain on it's own does it? What's it for then?

Regards, Phil

I had similar problems and found by elimination that it was essential to have the %s parameter in the command line. I presume this passes the source filename to LAME and without it an error is returned.
The %d parameter (destination file ?) is not essential.

Solved it - if anyone's interested...

My drive LG GSA 4167B does not support overreading which can lead to a sync error on the last track.
Explanation and workaround can be found here

The ESSENTIAL Ripping Guide to EAC

Click "Ripping" on the left and then see under "Errors! What to Do?".

OK - could someone still answer my question regarding the function / use of the --noreplaygain flag of lame?

ThanX

http://www.hydrogenaudio.org/forums/index....ndpost&p=339238

Thanks a lot!

In conclusion as it is kind of mentionden in the thread posted by odious_m and maybe more to the point here (Replaygain in WiKi); there is currently no use for using lame's gain function due to lacking support. Hence, especially in large batch encoding, the --noreplaygain flag of lame might save a little time.

Plz correct me if I'm wrong!

Hey, I've been away from ripping lately (mostly due to having nothing to rip), but I bought some new CD's the other day, and I'm having this problem again. I've used the Wiki to set up EAC and LAME (I copy-pasted the appropriate command-line string into EAC just to make sure I had it right), and here's the strangest thing:

The first time I ripped a CD, it worked like a charm. After that first time, it refused to call LAME to encode. I don't think this is some kind of bug that hasn't anything to do with what is in the LAME command-line string if it'll work sometimes and not othertimes.

I'm going to try uninstalling everything to do with EAC and LAME, reinstall, and see how it goes. I have two more CD's to rip, so I can test to see if the same thing happens. I'll repost here later.

Edit: I'm using the latest recommended version of lame according to these forums, FYI: 3.97b2.

Do you use a command line in which <lame.exe> does the tagging? If yes, then you might have a problem with the Genre. Lame has a list of genres and if the specified genre is not in the list, it will fail to start encoding.

This problem can be solved by adding the parameter --ignore-tag-errors to the command line.

Hope this helps.

I had actually thought of that as I was reinstalling, and I the LAME command box stays open just long enough for me to see that's what the problem is. I added that to my command line string, but to no avail. Granted, I really don't know that much about LAME's command line options, so I could be missing something. Here's what I've got:



Anything jump out at you as being dead wrong? Other than the --ignore-tag-errors bit, I got everything in that line from here.

Try to make your command line like this:

Thanks! That seemed to do it. I hadn't realized that order of the commands was important.