I got to thinking about the order of how I've been ripping my CD collection (since it was completely unripped before buying the empeg), and I'm curious to know how you all ripped your collections. Did you go alphabetically? By genre? Random according to mood? Reverse date of purchase?

I found I was going in a pretty random manner -- I'd just pull a CD off my shelf, and go rip. My CDs aren't in any particular order on the shelf, either. The only exception to the randomness has been with my classical CDs, which I saved till the end because tagging them was going to be a pain in the butt (which I'm going through now).

I think I did my collection in a combination of what-ever-is-on-the-top-of-the-pile and what-I-wanted-to-listen-to-next

Try to have some sort of logical order though. Otherwise you'll end up reripping stuff or forgetting to do things. I stuck some PostIt notes on the edges of CD cases that I'd already done so I knew which to skip. And PostIt's are nice and easy to take off.

- Trevor

I attacked my collection in the order by which it sits in my CD rack (which is alphabetical). Each whole CD was CDDB'ed and ripped with EAC until my 60GB scratch drive was full of WAVs, I then distributed the encoding across my three desktop machines and my laptop using LAME with the --r3mix setting.
After I did this I then encoded all my girlfriends decent CDs. But lets not get into a discussion about the legalities of copying other peoples CD's. In the case of my girlfriends collection, almost all the CDs I copied were ones I'd bought her!

I got to thinking about the order of how I've been ripping my CD collection (since it was completely unripped before buying the empeg), and I'm curious to know how you all ripped your collections.

I think more important than the order you rip them in is how you go about it.

The temptation is to sit down and do a marathon multi-gigabyte session, get it done and over with and loaded into the player so you can sit back and listen to it.

Don't do it that way.

Better is to do it just a few CDs at a time. I rarely did more than three or four in a night. Take your time, spend more time making sure all your tag info and filenames and directory setups etc. are exactly, perfectly right. Put as much information into the tag fields as you possibly can. So what if it takes you weeks to get all the music in your player? You will be listening to it for years afterwards.

tanstaafl.

I'd have to disagree with you there Doug. If I'd done a couple of CDs at a time, I'd probably never have finished by now.

I took my entire CD collection into work (all 200-300 CDs), and while I was working during the day, I'd have EAC rip each CD to WAV. By skipping the encoding step, I was able to rip about 12 CDs a day, meaning that it took just over a month to do all of them. I'd have done more, but the PC didn't have that much disk space in it.

I'd then set an encoder going overnight, so that the tracks were ready to be loaded on my empeg in the morning.

As for the order, I guess I did them fairly randomly -- I did the compilation CDs first, though.

Of course, I then had to take the CD collection home again -- having that many CDs lying around is just too tempting for people testing the Rio Central, and I could never keep track of where my CDs had gone .

Since then, I've probably bought another 100 or so CDs, but I can do them in batches of 5 or so.

Yeah, but most of us don't have the luxury of being able to claim that ripping and encoding our CDs is a valid use of our employers' time.

I prefer the batch approach - ripping and encoding a manageable number and ensuring that the tags are correct. I've found that tagging is the biggest holdup in the whole process, as it is impossible to know for any given CD how accurate CDDB data is. Some CDs have been perfect, others pretty bad, so all of the CDs need to be checked. The ripping and encoding itself is pretty smooth - just rip away for as long as you have time to swap CDs and then let the encoding happen overnight.

I'd have to disagree with you there Doug.

Nah, I think Doug's on the money (though I was expecting him to say he did a statistical analysis of the frequency each CD was played, correlated to the probability of wanting to listen to that CD again in the near future ), at least for people who don't have the luxury of ripping CDs at work. I have a monitor, keyboard and mouse at my desk -- I have no clue where the actual machine is, let alone whether or not it's got a CDROM on it (I use an SGI octane at work).

I drop in a CD when I wake up in the morning and start it ripping/encoding while I go to work. I don't have a really large HD, so I don't want to/can't maintain multiple CDs worth of WAV files. When I get home, I start another one, and do a third or fourth before I go to bed. I have three sections on my shelf of CDs -- ones already ripped, ones to be rippped, and ones that I need to re-rip.

..and now I know how he's been spending his time, Roger won't have the luxory of ripping his CD's at work either *evil laugh*

Rob

It's difficult to get a year for album's without manually searching for the information and putting it in.

I wish there was a way to automatically do this

Once I'd got the music loaded onto my empeg, I spent several (dozens?) of evenings with a copy of the Guinness Book of Hit Singles and emplode, fixing up my collection. I'm still missing years for about 80% of my music, which brings me to another of my pet hates, and a question:

Why don't compilation albums list the original release date of the track?

Should I be using the date of the compilation instead?

My pet peeve as well.... I'm missing about 50% of the years in my collection. When I originally ripped my stuff, I did it marathon style... and well missed a lot of editing with tag info. Thats the benefit of encoding your music one album at a time. You can go through and edit your tags and make sure everything is good, which can be overwhelming with 600 albums...

i have waay too many songs that are not attached to albums and they dont have the year.

I rarely rip the whole album, i only keep the tracks that i like or even remotely like.

If it stinks, i delete it or skip ripping it.

Yeah, but some sleeve notes just don't have the year, whether you're taking your time or not. And that's irritating.

As an addendum to the above question, I've been using Razorlame to encode, and then setting my tags with MP3Tag Studio. It'd be awfully handy to have a LAME frontend that rips and encodes so that the CDDB info gets written to the ID3 tags. I could then just check for accuracy. Anyone know of anything like this?

Audiograbber ($20) or EAC (free) will both grab CDDB info, rip the CD, encode using LAME (or almost any encoder), but neither makes a good cup of tea.

There are many differances between the two.

So there any cons in moving EAC/Lame? I'm gonna give it a try....

Should I be using the date of the compilation instead?

Nope, go for the original year or nothing at all. It's not a big deal with the compilation coming out only a few years after the original, but when you listen to older stuff (e.g., 1930's jazz), then it makes all the difference in the world. I look down at the year field all the time and it's cool to be able to place all the music into a historical context.

Jazz labels tend to give you all the bibliographical details you could ever want. For recent pop labels, the best bet I've found is to dig around on the web for discographies of the band in question.

In reply to:

---

Yeah, but some sleeve notes just don't have the year, whether you're taking your time or not. And that's irritating.

---

Yeah I hate that... but normally you can look that up and add it... via cdnow, amazon or an internet search. Which is a pain but not so bad if it's only for an album or two.

Oh yeah, my current pipeline is to rip with EAC, encode with lame, then clean up the tags with MP3 Tag Studio. This lets me have different years and everything else. The only problem is that, because my CD-ROM is so much faster at ripping than lame is at encoding, I'll sometimes have 100+ songs waiting to be compressed. If I rip in the morning, I might be running MP3 Tag Studio in the evening...

The learning curve....
I don't use EAC so I can't tell you about it, but I did recently download it and one of the feature it did not have which I use a lot in Audiograbber was the ability to append ID3 tag info to WAVs. This allows me to rip CDs for encoding at a later time and not lose the ID3 tags
How ever EAC does have the ability to spawn any number of LAME encoding process in the background while you are ripping in the fore-ground - this is quite useful on a multi-processor PC.

What have you been previously using to rip you CDs?

EAC/Lame is a great way to rip. Check out the tutorials at www.chrismyden.com about it. EAC isn't the most user friendly program to setup, but once you are running, it is awesome (and free!). EAC is the only program that guarentees perfect rips. It has powerful error correction. I liked AudioGrabber too, but it wouldn't work with Win2K and costs $20.

I rarely rip the whole album, i only keep the tracks that i like or even remotely like.

There's a downside to that... I have a fair number of songs that I didn't like at first, but that have "grown on me" to where I do like them now.

I actually have a playlist on my player called STSMTIDTIL that stands for "Songs Tony Sent Me That I Don't Think I Like" and some of the songs that were originally in that list have now made it to my "Favorites" list, and one of them (Tori Amos: "Spark") even made it to my "Favorite Favorites" list.

I have sent a few of my best songs to Tony, and he tells me that he has a SDSMTIDTIL playlist, only he calls his "Classical".

tanstaafl.

I'll sometimes have 100+ songs waiting to be compressed.

I rip using EAC at about 3x, but I have had it rip at 10 x, I found that if I played with my "Drive Options" I could use more reliable settings, while sacrificing rip speed. Ripping at 3x is kind of poo poo, using my IDE Acer CD Burner, but I'd rather it rip slowly and more reliably....

As far as encoding speed, I use LAME like this :

-k -q0 -v --vbr-new -V0 -b192 -B320 -F -ms

this gives me 6 : 1 compression on the wav files and encodes at 10x in winME on my Athlon 1600 XP.

Furthermore, I allow 2 instances of LAME to run in the background, (I figure my machine's got the horsepower) so that ripping can continue on to the next track while encoding happens in the background. I never have to wait for encoding after a rip.

so the empeg uses id3v1 or v2 tags?

so the empeg uses id3v1 or v2 tags?

Both/either. Emplode takes the V2 tag over the V1 tag if both are present.

Actually, it would be more accurate to say: "The empeg itself does not use the tags at all, it uses its internal database. Only Emplode uses the tags at import time to fill the database fields."

I use Tag&rename and change the id3v1 album tag on a 3000 mp3s then i performed a sync. nearly 15 out of 16 mp3s have no ablum tag filled in under id3v2.

Needless to say, I have to retag and resync. A Labour of Love!

I allow 2 instances of LAME to run in the background, (I figure my machine's got the horsepower)

I don't see you benefiting from running too instances of LAME. You computer will just split the CPU power between the two (less some scheduling over head - but lets just ignore that) meaning that each instance of LAME will get the equivalent of an Athlon 800 XP. Meaning that it still take about the same amount of time.
Now if you have a dual or quad CPU computer it would make sense to run as many instance of LAME as you have CPUs. Because as LAME is not a multi-threaded application the other CPUs would lay idle if only one instance was executed.

But then the time taken is not really that big of an issue, is it? Remember these are MP3 to which we are planning on spending a long time listening to - so spending the time on getting them right. Anyway just let the computer encode them overnight - it amazing how much quick a kettle boils when your not watching it!

As far as encoding speed, I use LAME like this : -k -q0 -v --vbr-new -V0 -b192 -B320 -F -ms

As for you choice of LAME settings Dave, you a better man then I. I never looked at the LAME help file till now, and even then I am only fascinated (confused?) by the wide array of options available. But I think you'ld benefit from a visit to r3mix and especially to their forums as these people have spent more time experimenting with the LAME settings than anyone else. Personally I have been more then happy to use the preset options available from LAME, but then maybe you have better ears or better listening equipment then I. /me glances at stock factory speakers.... Of course some would argue the that with the noisy environment of the car it makes little difference - but hey this is what makes the world go 'round.

I don't see you benefiting from running too instances of LAME.

I can't disagree with you more.
If LAME is not allowed to run in the background,
ripping stops between each track to wait for
encoding to complete before it starts ripping the next track.
And since encoding on my machine is so much faster than ripping,
the limiting factor is the rip.

When allowing only one instance of LAME to run
in the background allows the ripping to run uninterrupted.

I ask :
"Why would I want to interrupt the already slow process of
ripping the track with the any amount of the encoding process ?"

It's a winME box, 1 chip and plenty fast.
2 instances of LAME using only half of the
available processing power is a non issue,
because even one "Athlon 800 XP" would
encode the track faster than it is being ripped.

the real issue is my rips are done at 3x.
Mostly for accuracy, the drive allows for 8x ripping,
it's just not as relaible.

To further illustrate my point :

If you do not allow LAME to run
in the background you get this routine :

insert disc
rip track 1
encode track 1
rip track 2
encode track 2
rip track 3
encode track 3
rip track 4
encode track 4
rip track 5
encode track 5
rip track 6
encode track 6
rip track 7
encode track 7

Allowing LAME to run in background
produces this routine :

insert disc
rip track 1
rip track 2 and encode track 1
rip track 3 and encode track 2
rip track 4 and encode track 3
rip track 5 and encode track 4
rip track 6 and encode track 5
rip track 7 and encode track 6
encode track 7


As far as preset LAME settings,
I'm not sure they make sense to me,
as a general rule of thumb I figure,
any decision that is made FOR you,
is probably a bad one.

-k -q0 -v --vbr-new -V0 -b192 -B320 -F -ms
seems to make a LOT of sense to me,
and I just can't rely on someone else's "preset"
to make sure all of this stuff happens.

Defined : -k -q0 -v --vbr-new -V0 -b192 -B320 -F -ms

-k
keep all frequencies,

-q0
mp3 encoding quality 0 (highest)

-v
use variable bitrate encoding

--vbr-new
use the "newer" vbr encoding method

-V0
variable bitrate encoding quality 0 (highest)

-b192
use 192 as lowest bitrate

-B320
use 320 as highest bitrate

-F
enforce 192 as the lowest bitrate
i.e. use 192, even for silence

-ms
use stereo mode, 2 independant channels

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.

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. 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.

Ah Dave, I think you missed the compliment in my post, in the LAME settings section....the bit where I say you are the better man then I for having spent time digging through the selection of LAME options to choose what you felt was best for you?

Okay now that we have that cleared away.
The rebuttle
With regards ripping & encoding, it has in the past been my experience that ripping occurs much quicker then encoding - except when using an encoder like Xing. In my case my plextor cdr rips ~26x, my pioneer dvd at ~11x and the toshiba dvd in my work PC at ~6x - all without error. While encoding drags along at around 2x to 4x an my P3-700, my work PC also has a P3 of around the same speed and returns similar results. So yes I am guilty of judging your results compare to my experiences.

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.
You seem to have confused "encoding in the background while ripping" with "running multiple instance of LAME in the background while ripping".

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.

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.

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

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"