After procrastinating and dragging my feet for a couple of years now, I have finally decided to re-rip/encode/tag all my music. The primary force behind this decision was that I did such a poor job of tagging the first time around that getting it all right just wasn't practical. So, it was a good excuse to try this EAC/Lame business everybody talks about.

It was (for me, at least -- an old dog who doesn't learn new tricks all that readily) a pretty steep learning curve. I spent about six hours just studying and working my way through all the parameterization options and trying to decipher the tantalizingly vague information that came with the program itself before I even tried ripping a CD. In the process of my experimentation I learned something that most people, even Windows gurus (which I assuredly am not!) don't know.

Everybody knows that 32-bit windows allows filenames up to 255 characters. But what a lot of folks don't know is that the 255 character limit includes the complete directory path from root.

This means that if the directory path to your file is, for example, "C:\Documents and Settings\Tanstaafl1\DeskTop\_MP3 Remasters\Classical\Tchaikovsky, Peter Ilyich\" you only have 159 characters left for the actual filename. Believe it or not, I actually ran into this limitation, because classical music filenames can be quite complex. (I use the filenames with MP3TS to generate my tags). When you have filenames like "Tchaikovsky-Symphony #6 in B Minor, Opus 29, 'Pathetique', Second Movement (Andante Cantabile)" combined with a convoluted directory path... well, you get the idea.

All in all, I am loving EAC. I have been telling people that EAC is to AudioGrabber as Microsoft Word is to Notepad.

Now, after you've waded through all this prologue drivel... here is my question.

Is there a way within EAC to delay the Lame encoding? That is, can I rip a bunch of CDs, and when I am done ripping, have EAC tell Lame to start the encoding, and just let it run overnight?

The reason I want to do this is that the ripper is considerably faster than the encoder, and on my system at least there is an annoying glitch that causes EAC to lock up temporarily, usually about once during every rip, until Lame finishes one of its encodes. (I run four encode threads simulataneously).

I think I am getting pretty good speed out of EAC -- I am averaging about 12x speed. This is on a 2.5GHz Athlon with a gigabyte of striped RAM on a 400 MHz bus, a pair of 7200 RPM 120 GB hard drives, a 128 MB video card, Lite-On 80x CD-RW drive, with sound and ethernet on the motherboard. But, all that EAC speed drops to zero whenever Lame locks it up. The lockups last anywhere from one to three minutes, and always end when whichever Lame encode session that is causing the problem finishes. Then EAC just picks right up where it left off.

I don't hesitate to recommend EAC/Lame to anybody who has been putting it off. Just be sure to spend the time to really learn all it can do to take full advantage of its capabilities.

tanstaafl.

Congrats on the conversion!

First, I want to make sure you know about EAC's queue feature... You can pop in a CD, rip that CD, then pop in CD #2 and start ripping it before CD #1 has finished compressing. I used to do this on my notebook and pop in CD after CD after CD. My system also compressed slower than it ripped. I ended up having 100's of wav's, waiting to be compressed in my queue. Here's the coolest part, if you close EAC while there is a queue, it will resume that queue the next time you start EAC! I used to rip at work on my notebook, shut it down, go home and resume my queue over night! The only limit was my hard drive space for all of those wav's.

If this doesn't help you, I have one other suggestion...

You can tell EAC to name the file in a way that will have all of the information in the filename. If you were to rip to WAV (and not mp3), you could later tell EAC to convert those WAV's to mp3 in one batch process. I recommend looking for a seperate program to do this because EAC adds "filename.compressed.mp3" for some odd reason. The last step would be to use a program like Tag&Rename to put the tags back in (because EAC doesn't store the tag info. if you only rip to WAV.

You brought up the 255 limit, so I'd rip them all to the same folder like this:
D:\mp3s\artist - year - album - genre - track number - song title.wav

If you need help setting this up, let me know.

DO a Search on Google for "LameB Package". I think I might have found the link on the Hydrogen Audio Forums, so you could also try searching there. This is a DOS batch encoder using Lame. It is a pain in the a$$ to setup, but once you get it working you will wonder how you lived without it. I usually rip until I done messing around on the computer or the hard drive is pretty full. I then just run the .bat routine and when I wake up in the morning my music is all encoded, tagged, and put into directories ARTIST\ALBUM. The script is customizable so what can be done is really amazing. I could tell you alot more but you are better going out and learning about it on your own and then if you decide you want to use it, I will try to answer any specific questions. Otherwise if I start telling you about it now, you probably will shy away from using it.......DON'T. I am by no means a computer whiz and I figured it out.....Who knows maybe you will think it is easy.

When you are searching be aware that there is two versions. One is just plain old LameB and the other is LameB Package. LameB requires getting Perl running and is what I originally used. But someone on Hydrogen Audio Put together a bundle that does not require you download and install any extra elements hence it is easier to get working.

http://www.lameb.fsnet.co.uk/

http://www.hydrogenaudio.org/index.php?showtopic=3452&hl=lameb+package
That is the link to the thread that talks about the package.

First, I want to make sure you know about EAC's queue feature...

Is that a recent development? I need this!

AFAIK, it's not. I remember sitting down one afternoon and ripping quite a few CDs in a row, while watching TV or playing video games, or something. EAC behaves exactly as Brad describes, keeping track of all the ripped but unencoded tracks and sending them out to the encoder in order.

So, like he and I have done, you can sit down and rip several CDs in a row, and then just walk away from the computer without a worry. Yet another awesome ability tacked onto the list that makes EAC the best ripper ever.

It's been there for at least the last 4 versions.... well over a year and a half. I'm not sure when they slipped it in, but it's been there since I've been using the program. I used to freak out thinking that I had to wait for it to finish compressing! Oh the time I wasted!

See Attached screenshot. The queue feature might be disabled on your settings for EAC the one you want is called:
On extraction, start external compressor: in the background.

I run four encode threads simulataneously.

Unless your encoding is disk-bound, which it isn't, then you're not gaining anything by having more threads than your PC has CPUs -- indeed, you're losing out fractionally due to extra swapping and context-switching. Plus, if you have four threads each slowly dribbling data into different MP3 files, your MP3 partition will end up terribly fragmented.

Peter

First, I want to make sure you know about EAC's queue feature... You can pop in a CD, rip that CD, then pop in CD #2 and start ripping it before CD #1 has finished compressing.

Right. That's what I'm doing. However, I'm finding that is taking me so long to get my filenames set up exactly right (remember, I'm generating my tags from the filenames using MP3TS) that by the time I have everything just right, the previous CD has usually finished encoding by the time I'm starting the next. Oh, filenames are *easy* with CDs like "Moving Pictures" by Rush. All I have to do is prepend the word "Rush" to each track title, and I'm done, because the FreeDB database for a common CD like that is usually dead-on accurate. But when I go to "A Treasury of Classical Music, Volume 03", the third disk of a 10 disk set, and that disk contains 21 different tracks by 21 different composers, and track titles from the database say something like "Symphony #7" and I'm wanting something like "Beethoven-Symphony #7 in A Major Opus 92, 1st Movement 'Poco Sostenuto' (Allegro Vivace)" it takes a long time to get that CD ready to rip! For that reason, it becomes doubly frustrating when Lame causes EAC to temporarily lock up, preventing me from working on the next disk.

That is why I would like a way to separate the ripping from the encoding -- rip with EAC and have it set up the batch files or whatever it does to run Lame but not actually start the Lame process(es) until I tell it to do so.

You say I can later tell EAC to convert those WAV's to mp3 in one batch process. and that's what I want to do. But I don't see how to do it. Not even sure how to just rip the CDs to WAV files without automatically calling up the external encoder. What am I missing?

tanstaafl.

(Edited to add final paragraph)

you're not gaining anything by having more threads than your PC has CPUs

Are you sure about that?

Casual observation seems to indicate that the encoding rate in fames per second on any of the threads stays the same, whether there is one, two, three, or four threads running simultaneously.

So it stands to reason that if I can run four equal-speed threads simultaneously, that should encode things about four times faster than running single threads sequentially.

Or am I missing something obvious here?

tanstaafl.

Casual observation seems to indicate that the encoding rate in fames per second on any of the threads stays the same, whether there is one, two, three, or four threads running simultaneously

OK, so I'm an idiot.

The four windows (one for each simultaneous thread) were on the screen cascaded, and when I brought any one of the four up to the top, it would be running full speed, so I just assumed the three underneath were also running. After all, I checked each one individually, so they must all be working.

Then, I got the bright idea of spreading the cascaded windows out across the screen so I could watch all four of them simultaneously, and guess what? Only the "active window was encoding; the other three were just sitting there, occasionally getting the odd update.

I'll bet that when I cut back my simultaneous threads to just one (instead of the four I was running when I thought I was getting 4x encoding speed) will solve the problem of Lame locking up my EAC sessions as well.

tanstaafl.

Not even sure how to just rip the CDs to WAV files without automatically calling up the external encoder.

Just hit the WAV button instead of the MP3 button. Later, to compress to mp3, go "Tools > Compress Waves" to add them to the queue. I do recommend something like RazorLame if you want more features in this 2 step method..

Only the "active window was encoding; the other three were just sitting there, occasionally getting the odd update.

Yep. Windows has this concept of "foreground application priority boost". Go to Control Panel, System, Advanced, and under Performance, hit the "Settings" button. It allows you to tweak this value. On desktop Windows (2000 Pro, XP Home, XP Pro) it's set to boost the foreground application. On server Windows (2000 Server, 2003 Server) it's set to not boost it.

Personally, I'd leave it alone. All it does in the "server" setting is make the scheduler fairer. It still won't benefit you to run more encoders than you have CPUs.

Just hit the WAV button instead of the MP3 button. Later, to compress to mp3, go "Tools > Compress Waves" to add them to the queue. I do recommend something like RazorLame if you want more features in this 2 step method..


Well, no wonder I couldn't figure it out. Such an incredibly complex procedure is well beyond the grasp of mere mortals.

Actually, I had looked at those options, but the "Compress Waves" didn't immediately jump out at me as a way to create MP3 files. Does this procedure pass on to Lame the compression parameters defined in EAC at the time the .WAV files were created? It must do so, or it wouldn't be particularly useful...

I don't think I need any more features than are offered by EAC and Lame. I am just now starting to explore the Lame parameterizations... and have reached an impasse with trying to encode my audio books at a reasonable bitrate. Is it even possible to pass parameters to Lame through EAC that will persuade Lame to encode at bitrates lower than 96 KB/sec? I would prefer to encode audio books at something averaging about 64 KB/sec VBR, and cannot figure out how to do it.

If someone were to offer me a nice EAC command like --alt-preset VBR 64 %a %s %d but one that actually worked that would be nice. Maybe there's an "--alt-preset audiobook" command out there?

tanstaafl.

I'll bet that when I cut back my simultaneous threads to just one (instead of the four I was running when I thought I was getting 4x encoding speed) will solve the problem of Lame locking up my EAC sessions as well.

If you have one of the newer hyperthreading CPUs or a dual CPU box, then you might want to try running two encoding tasks at the same time. Otherwise, one thread is definitely the way to go. Of course, none of this should effect the stability of the ripping process...

Another option for batch encoding that you might ponder is using Apple's iTunes. You can tell iTunes to rip everything to WAV. Then, you can select all the WAVs at once and ask iTunes to encode them. Plus, you're not stressed out about the filename length limitations because everything is stored in iTunes internal database.

Maybe there's an "--alt-preset audiobook" command out there?

Give "--alt-preset voice" a try. Should give you 56kbps/mono ABR according to the docs.

-Mike

Give "--alt-preset voice" a try. Should give you 56kbps/mono ABR according to the docs.


That didn't work... but I think you really meant "--preset voice" (without the "alt"). That did work, but I was not happy with the sound quality. I realize that 56 kbps isn't going to sound like the original CD... but it was just a bit too much of a trade-off of file size vs sound quality.

I finally ended up using "--vbr-new -b 0 -B 96 %s %d" as my EAC parameter line to pass onto Lame.

It gives me sound quality that is different from the original CD, but not objectionably different. If I had to put my finger on it, I would say that my Lame-encoded MP3 with that setting is a bit brighter and clearer in the upper registers, but lacks a bit of richness in the mid-range. I can hear the difference, but would be hard-pressed to pick one over the other as being "better. (Remember--these are audio books; perfect replication of the original "sound" is much less important than with music!)

Amazingly enough, my average bitrate and filesizes are coming out slightly smaller (about 5%) than with the "--preset voice" setting.

I blush to admit it, but since my audiobook CDs are in perfect condition, having only ever been out of their cases one time before, I have turned off the error checking (for the audiobooks only) and am getting some screaming-fast rips, and the low bitrate encoding seems to run very quickly as well.

tanstaafl.

Later, to compress to mp3, go "Tools > Compress Waves" to add them to the queue.

I tried that, and it worked just the way you said it would.

However... doing it that way doesn't write the tag information into the MP3 file. Since I create my MP3 tags from my filenames, this isn't too severe a problem... EXCEPT that my filenames do *not* contain the "year" nor the "genre" information, and since I am already pushing the limits of my maximum filename size, I can't readily add those to the filename construction in EAC.

I do recommend something like RazorLame

You are not the only one to recommend this. I will give it a look. However, since I only have 13 more audiobook CDs to rip/encode (LOTR, BBC version), and a boxed-set of 10 classical music CDs that just arrived from Amazon left to do, it's probably too late to help me very much now.

Finally, rather than start a new thread with a new question... in MP3TS, some of the operations offer a "Include Subdirectories" check box. The operation "File tools (repair, trim...) --> VBR header repair/add" does NOT offer this option. Does anybody know a way to do this operation on an entire directory tree, or do I have to select each goup of files separately? (I don't know if it is EAC or Lame that is the culprit, but 100% of my MP3 files is shown by MP3TS to have invalid VBR headers.)

tanstaafl.