If you've got one CPU, then running one instance of lame at a time will go faster than running two together. The reason for this is that lame is CPU-bound. It pegs the CPU meter. If you run two copies of lame together, each will take almost precisely twice as long to finish.

I've noticed this...
But there is almost always only 1 instance of LAME running, since my burner is much slower at ripping than my cpu is capable of encoding... eventhough I specify that 2 instances CAN run.


Ah Dave, I think you missed the compliment in my post

yep, saw that, thanks, sorry for no thanks earilier.


When taking into account the limiting factor of the 3x ripping of your Acer cdr it does begin to make a bit more sence, until I look at you time line.At no point do I see the second instance of LAME been used, and you your self said the the limiting factor is the ripping not the encoding.

Yeah, but since my burner is a slow (but very accurate) ripper, LAME has plenty of time to finish before the next track is finished ripping and ready to be encoded. It is only on CD's with many shorter length tracks that ripping can finish a track and move on to the next one before LAME has time to open, start encoding and close in time to start the next encode.


You seem to have confused "encoding in the background while ripping" with "running multiple instance of LAME in the background while ripping".

I get the difference here, sorry for the confusing message, I just rarely ever need to run multi MALE instances.


Also you seem to have brushed aside the two site I point you in the direction off. This was not in any way an attempt to disprove your setting choices, but rather to put you in touch with others who have gone through these settings or have created these settings and therefore are responsible for the direction that LAME is taking.

I realize that, I offered my settings as an eye opener to those who might not realize the full potential of LAME. and since you provided the links, I (foolishly) did not reinclude them in my message, but I, too recommend those sites... A great resource...


Finally do your self a favour and head over to http://www.cdspeed2000.com and check out the DAE speed of various CD drives, and also visit the above mentioned forum. And then fork out the $100 for a new CD drive so the you can remove that limiting Acer burner of yours.

Now THAT's a nice link... did everyone check that? It's : http://www.cdspeed2000.com


One more question dcosta - how often do you change the oil in your car?

I change my oil every 3000 miles on the nose, it's easy to keep track of that way.
3,000 - 6,000 - 9,000 - 12,000 you get the idea... Why do you ask ?

Sorry, you're wrong on this. If you've got one CPU, then running one instance of lame at a time will go faster than running two together. The reason for this is that lame is CPU-bound. It pegs the CPU meter. If you run two copies of lame together, each will take almost precisely twice as long to finish.

I was not aware of that technical reason, thanks for the tip, that explains a lot.

The best way to speed things up is to use EAC on Windows or grip on Linux, which run lame in the background and create a work queue of tasks for lame to process.

How do I do that on winME with EAC and LAME?
I'd really like to "rip the whole CD, (take out the disc), THEN encode it all." ?

This way, my blazing Plextor drive can rip audio accurately at 16-20x, allowing me to plough through 20 CDs in an hour. Then, the computer grinds away running lame all day and I've got fresh MP3s waiting for me when I get home at night.

I think this is what I do, but I'm not sure...
Is there an EAC setting that says "rip the whole CD, THEN encode it all." ?
Because all I can seem to make happen is either

"Rip one track then encode it, rip another track, then encode that, etc."
OR
"Rip one track then start encoding it in the background while ripping the next track, etc."

"Rip one track then start encoding it in the background while ripping the next track, etc."

In newish versions of EAC there's a setting for doing the Right Thing: ripping the whole disc as quickly as possible, but starting Lame in the background once the first track has finished ripping, then the second Lame once the first Lame has finished (wherever the ripping side of things has got to) and so on. You can eject the CD once ripping is done -- indeed, you can even start ripping further CDs, and their WAVs will be queued for encoding after the first CD's.

Or you could just buy a Rio Central

Peter

As I tend not to allow any of my home machines to connect to anything outside, CDDB was not an option for me. So as populating the tags was pretty much the bottleneck for me I did my collection this way:

Stack CD's next to PC in my study
Put CD in drive
Fill in data in AudioGrabber
Rip and encode (using LAME VBR 7 IIRC)
Have snack
Remove CD
Go to step 2 until done

Didn't take very long - about 8 minutes per CD. Since then as I only buy a couple of CD's at a time I do them there and then.

The only exceptions to this are new CD's my brother gets - I just take my empeg round and sync on his machine.

Audio quality is superb, file sizes are small (about 4Mb per song) and it's minimum effort (well, except for the typing, but I'm pretty fast)

I usually put date of compilation, but then again I can't say I've ever used the date field anyway. My brain doesn't care what year something is from, so my typical playlist is just an all/random shuffle (or a subset which is 'heavy') and that gets reshuffled (down, down, down) as and when I feel like it, 'cos I can always ff past a track I don't want at the time.

I just use the date because the empeg uses it..

Fair enough

Well I do put it in, I just don't sort songs mentally by date. By genre, yes; even by mood; but I see nothing incongruous in having an early Zappa, followed by a recent Silverchair for example.

I think if I was searching for a song I would always do it by title or artist, as I wouldn't know when the song came out anyway.

Of course, I am renowned (amongst siblings and friends) for not even knowing what year/month/week/day it currently is until I look at my watch or PC clock as it doesn't really affect me.

frog51, AudioGrabber can query a local copy of the CDDB database which can be readily downloaded from .freedb.org
The archive is ~122megs in size, with monthly updates of around 6-10megs in size so the you have the latest Britney albums listed.

Also as AG can append tag info to the WAV file, you can rip several CDs in a row and encode later while asleep/at work and still have the ID3 tags filled in automaticly. Would save you having a snack per CD!

Ahh - wasn't aware I could get a local copy. That would certainly solve that issue completely.

Not sure how much benefit there would be from ripping and encoding separately. Am I likely to get much better than 8 minutes per CD? If so, then I could see it being useful.

The time per CD would be the same, 8 minutes, over all. But you don't need to sit around and eat a snack while it encodes. You leave the encoding till later after you have ripped several CDs. This is useful when ripping a collection/stack of CDs and not when ripping one or two new CDs. Am I making sence yet?

Yup - does kinda make sense. I'll maybe give it a try next time I buy more than a handful of CD's.

But when am I going to have time to eat all my snacks now??

In reply to:

---

As I tend not to allow any of my home machines to connect to anything outside,

---

???

Afraid of "zee Germans"?

This a reference to "Snatch"? (Turgish says it to Tommy)

I think it was Turkish, and although this may have been a reference to Snatch, I think the phrase has been around longer.

I'm sure it has been around longer. But yes, it was in fact a reference to Snatch.

I meant it though - I was really wondering why one would not "tend to allow any of ones home machines to connect to anything outside". Used for "sensitive" work I'd guess, but I was wondering.

I don't about earlier but Jason Statham also used the line "This is the perfect weapon to fight off zee Germans" in the Jet Li movie "The One"