Could anyone tell what are (is?) the best CD-to-MP3 rippers on the market.
Prize does not matter - it must be VERY fast and simple.
I tried a couple from the list on www.dailymp3.com but non of them can beat the Windows Media Player.
It's sad but I have to say that the Microsoft version is really fast and finds much more tag infos than all mp3 rippers I tested so far :-(
But I don't really want to encode to wma...

The must criteria for me is:

1. Find the tag (almost) for every CD (I don't like to type it in myself)

2. Must encode to directory structure <artist> / <album> / <songtitle>
(would be great if this can be configured.

3. Must be FAST (128kbit or 160kbit) - I have to rip a lot of CD's ;-)

Thanks for any hint.
Guschti

Exact Audio Copy, Lame. The only <i>right</i> way to rip and encode in the windows enviroment. It'll do everything you want. Speed however, is not what it focuses on, but it's worth it.

Matthew

There are really only two options for CD info I know of, CDDB and FreeDB. Both of them suck. I have to correct data for at least half of the CDs I put in.

Most can put files wherever you want.

You say it has to be fast and then you list bitrates. I'm not sure what that's about. Personally, I find fast to be irrelevant. If it's fast and bad, then you end up having to rerip, which makes it slow and annoying.

Also note that you're talking about at least three different processes here. There's ripping, which is getting the audio data off the CD. There's encoding, which is saving that audio data as an mp3, a wma, a wav, a flac, or whatever. Then there's getting the track information (I can't think of a comprehensive name for this). Many products do all three of these things.

Really, though, the best would be to use EAC and Lame. EAC is a ripper+info-er, and you can use lame as a plugin (of sorts) to encode. It's probably not the fastest, but it's the most accurate, and it's not slow.

If you really want to, though, you can probably get WiMP to encode to mp3. From here:

Encode MP3s with WiMP
Install an MP3 codec (compression/decompression, required for this operation). You can download it here. Once installed, navigate to the following string in regedit:
HKEY_LOCAL_MACHINE\Software\Microsoft\MediaPlayer\Settings\ then to MP3Encoding and set the following:
"LowRate"=dword:0000dac0
"MediumRate"=dword:0001f400
"MediumHighRate"=dword:0003e800
"HighRate"=dword:0004e200
After reboot, you'll be in the MP3 business without third-party software.

"Best" does not equal "Fast". If you have a lot of CD's, I'd recommend doing them correctly rather than quickly or else you end up doing what I did and re-rip them because the empeg has such great audio quality that you'll be able to tell the difference. 160kps or 192kps at the very least, or go with VBR encoding so you get high resolution when you need it and low when it wont matter (to save space).

Exact Audio Copy and Lame is the way to go. I ripped w. Music Match at 160kps CBR twice, then at 192kps (with a CD collection that has over 400 CD's) before I switched over to EAC and Lame VBR's. Think of how much longer it took me because I was in a hurry..

I posted an EAC setup guide here a few weeks ago.

One thing that makes EAC faster than it seems is that you can pop in a CD, let it rip and then pop in a 2nd CD before the first is done encoding and rip that. A queue will build up allowing you to pop in CD after CD all day long and let it encode over night. With MusicMatch, I was only able to encode 3-4 CD's a day while at work, but with EAC I could do as many as would fill my HD. If EAC is running and has 20 songs in the queue, you can close down EAC, allow that current encoding to finish then when you re-start EAC (even after a re-boot), EAC will resume with the queue. So I ripped CD's all day at work, turned off the notebook, took it home and let it encode while I slept.

Oh, the mp3s sounded way better too and were often not that much bigger in size than a 192kps CBR file depending on the song.

Thanks so far for any information - it's amazing how fast people reply on this board and how kind they are!
In my first post I noted 2 bitrates - I added these just to point out that the enconding should be fast at these rates.

BTW: I know how the ripp, conversion, encode process works - I'm only looking for the best solutions on the market.

The biggest problem I find in _all_ application I tested so far is that CDDB and the Free version of this Database both are really not useful for large ripping amounts.
I wonder how Microsoft does it (they must have contracts with other companies...?). Whenever I use the Media Player it finds the CD-Information (even some weird Latin CD's...)

hmmmm - can't we abuse Mediaplayer to get the tags somehow ? :-)))

Thanks for any further tips!

Get your thoughts into Quality... not Quantity.
Waaaaay to much\many crummy rips\encodes out there.
Everyone is so lazy it sickens me. *sigh...
My choices have been the same for some time now.
EAC = Exact Audio Copy! =RIP!
FHG = Fraunhofer Encoder Professional.
Install FHG and use EAC as the frontend!! your done, and it will do all you request above... and do so well.

Actually, now that I think about it, WiMP uses AllMusic data. I don't think that there's any way you can get to that programatically for free.

I like Fraunhofer Pro for CBR files, but I think it's a bit outdated when it comes to VBR. The only people resistant to VBR are those with 1st Gen mp3 players that don't support it (same goes for the people that hate V2 ID3 tags). But, if CBR is your thing, Fraunhofer Pro is the way to go I spose (at least equal to lame.)

FWIW, MusicMatch uses Fraunhofer (not sure if it's Pro) and as I mentioned, I ripped my entire collection 3 times w. it before moving to Lame. Fraunhofer does seem to boost the bass a bit and people like that (kinda like how radio stations boost the bass and compression the dynamic range to raise the average volume.)

I use CDex and LAME. CDex can be found at www.cdex.n3.net.

I agree with CDeX and LAME. It does an excelent job with the EAC and encoding. Includes LAME and OGG encoding.

Actually, now that I think about it, WiMP uses AllMusic data. I don't think that there's any way you can get to that programatically for free.

I use Tag&Rename, to add AMG data to my mp3s after they're ripped. It's a handy lil' programm and just copies the artist/album/track/title/year/genre/review/coverart info from the webpage.

CDex does a good job with EAC? That's like saying Windows does a good job with Linux.

Exact Audio Copy and Lame is the way to go

I know everyone always says "use EAC, it gives you the best quality rips you can get". But I don't get it.

Until recently I was using Audiograbber for all my rips (and LAME to encode), because EAC just couldn't cope with my old CDROM. I now have a nice Plextor CDRW/DVDROM so I thought it was time to switch to the "best" ripper around.

Using Audiograbber on my PII300 with my new drive it can manage to rip at 15x - 25x (depending on where on the disk the track is). EAC manages 5x - 10x on the recommended settings and still only 10x - 15x on the "fast" setting.

Now I'm happy to sacrifice a bit of speed for better quality. However I have yet to find a single track where the WAV files generated by EAC and Audiograbber differ at all (i.e. I do a bit by bit compare and they are identical).

I would happily use EAC if it actually did produce different results to Audiograbber, but as long as Audiograbber does perfect rips anyway I don't see the point.

All of my CDs are in very good condition, I don't go around mishandling my disks. Does this explain why Audiograbber gives the same results but 3 times faster ?

All of my CDs are in very good condition, I don't go around mishandling my disks. Does this explain why Audiograbber gives the same results [as EAC] but 3 times faster ?

Yes. EAC is optimized for precision and accuracy, especially in the face of potential errors, not speed.

However, neither do I mishandle my disks, but they do simply age as you move them in and out of CD players. I'm not saying they oxidize or that the laser wears them out, but it's hard not to occasionally do something to damage them simply by handling them. And given that, it's better for me to use something that I know will give me the best possible results, even if it might be slower, rather than something that ought to give me the correct results, depending on a few criteria, about which I am significantly less confident. However, if you're confident that all your disks are error-free, then, of course, continue with whatever works for you.

EAC's secure mode is the best ripping around. It will read every piece of data twice and compare the two to make sure it is getting a perfect copy. If they don't match, it will keep reading it until they do, or until it gives up. Yes, that makes it twice as slow as the alternatives, but isn't peace of mind worth it.

If you don't do it that way, I can pretty much guarantee that you have a problems with one of your rips somewhere. No CD drive ever made rips perfectly, especially if the CD is dirty, scratched, or is of low quality (common with classical music CDs for instance). If you don't have some kind of double-checking like this you have no way of knowing if there is a problem.

Oh, there's a description of EAC's extraction modes here.

Andy, that's a good point that you bring up. I forgot the mention that the reason that everyone goes nuts over EAC is because it is supposedly the only program that can gaurentee perfect rips. It really does a good job with CD's that have been in a car (the load mechanisms on most car CD players do hell to CD's) and older CD that have been shuffled around a lot. I've even had a few brand new CD's that have triggered EAC's error correction due to less than perfect pressing.

I used AudioGrabber too and like it. I was having a few damaged CD's that weren't ripping correctly, so that's why I went to EAC. That was after paying the $20 bucks or so. (EAC is free, as is Lame).

On the subject of damaged CD's, I highly recommend the "Skip Dr." device. It buffs a small layer of the plastic away on damaged CD's (much like you can buff scratches out of a car's paint). I've had great results with it. The $30 I spent on it saved about 50 CD's so far.

I would have to say that EAC/Lame is the best. When I first got my empeg all I wanted was to get all my cd's into it, bad idea. I used music match and or audio catalyst to rip them once at 128cbr and then redid them at 192cbr, and when I was done I still just had a lot of nasty sounding mp3's (especialy the pink floyd) so one by one I have been using EAC to redo all of them and wow what a difference. It is slower but well worth it when your done. On my pc at home (amd k6-2 500mhz) it takes about 45 min to an hour or more for one cd but at work on that pc (amd athlon 1.7ghz) It only takes about 10-15 min. per cd. So I just need a faster pc

Im with "SE_Sport_Driver" on the skip dr. it fixed a handfull of unreadable cd's for me too.

...and for all the linux/*nix/*BSD heads, cdparanoia is the equivalent of EAC. It's kinda paranoid about ripping the correct data.

IMHO, the data in freeDB is getting much better. I seem to be finding fewer CDs that aren't known, and more that are 100% correct*.

* Correct in this context meaning with a reasonable interpretation of Artist/Album title/year, even if it isn't what we'd personally prefer in some circumstances (mix albums, classical, compilations etc).

Of the dozen or so CDs that I have acquired for/since Christmas, all but one were 100% correct, and that one just had a typo error in the title.

In reply to:

---

Exact Audio Copy and Lame is the way to go

I know everyone always says "use EAC, it gives you the best quality rips you can get". But I don't get it.

Until recently I was using Audiograbber for all my rips (and LAME to encode), because EAC just couldn't cope with my old CDROM. I now have a nice Plextor CDRW/DVDROM so I thought it was time to switch to the "best" ripper around.

Using Audiograbber on my PII300 with my new drive it can manage to rip at 15x - 25x (depending on where on the disk the track is). EAC manages 5x - 10x on the recommended settings and still only 10x - 15x on the "fast" setting.

Now I'm happy to sacrifice a bit of speed for better quality. However I have yet to find a single track where the WAV files generated by EAC and Audiograbber differ at all (i.e. I do a bit by bit compare and they are identical).

I would happily use EAC if it actually did produce different results to Audiograbber, but as long as Audiograbber does perfect rips anyway I don't see the point.

All of my CDs are in very good condition, I don't go around mishandling my disks. Does this explain why Audiograbber gives the same results but 3 times faster ?

---

This is exactly my experience

Woo hoo ! I'm a member !

100 dumb ass posts. And they're mine. All mine.

Call the BBS Police - BLATENT BLATENT post count boosting, .......unlike this post .

Cheers, Sim

However I have yet to find a single track where the WAV files generated by EAC and Audiograbber differ at all (i.e. I do a bit by bit compare and they are identical).

I would happily use EAC if it actually did produce different results to Audiograbber, but as long as Audiograbber does perfect rips anyway I don't see the point.

All of my CDs are in very good condition, I don't go around mishandling my disks. Does this explain why Audiograbber gives the same results but 3 times faster ?

"However I have yet to find a single room in my house where using a full fire extinguisher differed at all from an empty one (i.e. I count the number of things on fire before and after and they are identical).

I would happily keep a full fire extinguisher if it actually did produce different results to an empty one, but as long as nothing's on fire anyway, I don't see the point.

All of my furnishings are not on fire, I don't go around setting light to them. Does this explain why an empty fire extinguisher gives the same results but is 3 times lighter?"



Peter

Yup - Audiograbber & LAME for me. No issues whatsoever (excluding my first 20 CD's, when I had my CD settings wrong and every track had a blit at about the 5 second mark. Akk!)

My only annoyance is that I can't persuade Audiograbber to remember a different address to grab freeDB info from, as most of my network is not ever connected to any public infrastructure and I want to use a local copy.

Clever clogs !

Ok, I'm sold. I'll persist with EAC.

Now I just need to find a CD scratched enough to return C2 errors, given the scratch free state of my CDs I might actually have to manufacture one...

...now where is that Brittney album ?

I always took the albums missing in freedb as my way of paying back the guys who had to type in all the original data... I mean someone has to be the first one on every album don't they?

The only site worth its salt would be the one that banned the word "various" completely, and insisted upon an artist name - every track.

I might actually have to manufacture one...

...now where is that Brittney album ?

You may borrow anything from my daughter's collection to experiment: What does she do with them!

I'm in the EAC/LAME camp and I've often found CD's in Leeds public library that none of my CD players will play, but I can get perfect playback from the MP3 through EAC. But it's a slow, slow process.

I would only mention that the CD was so invincible, we were told, that it would play with jam spread on it!

One way around the slow encoding speed of LAME (slow when comparing LAME --alt-preset standard to almost any other encoder) is to do your encoding as a seperate step.

IE: Rip several CDs to WAV and then encode the CDs while you do something worth while like sleep.

I've been doing it this way as I find the most labour intensive part is the ripping and ensuring the Album/Artist/Track/Genre/Year info is correct, but this is also the least time intensive, while the encoding requires zero labour but lots of CPU.
That way the 30 minutes encoding time become irrelevent.

Oh, for the record I'm using AudioGrabber & LAME APS

Various reasons why CDDB/FreeDB sucks

I always took the albums missing in freedb as my way of paying back the guys who had to type in all the original data... I mean someone has to be the first one on every album don't they?

Yes, I agree, although in many cases that data has been entered twice to make up for the blatently dishonest piracy of the original cddb data by Gracenote.

In reply to:

---

Now I just need to find a CD scratched enough to return C2 errors, given the scratch free state of my CDs I might actually have to manufacture one...

---

I don't recommend going with C2 error correction, even with a Plextor drives. I've found a few rips that are falsely reported as error free on Plextor drives when using C2 that in fact are not. It seems many drives falsely state that they are C2 compliant but are not.

The best bet is to use EAC in Secure Mode, with Accurate Stream. Also, be sure to check the "Drive caches audio data" box to be safe. Checking this box clears the cache. Even if your "auto detect drive features" process says your drive doesn't cache data (most do) the author of EAC professes that it is usually a false detection. I guess that feature is hard to detect for EAC.

Well, it's supposed to be getting the same data every time, even, potentially, on a flawed disc (in which case the data would be incorrect, but the same every time). So in order to detect it, he'd have to figure out a way to provide a disc that he knew would confuse the drive enough for it to read different data for the same sector at different times. And a disc that did that on one drive isn't necessarily going to do it on another.

So I'd say that it is definitely difficult to detect. Safest, once again, to have it clear the cache as needed, to assume there is one, even though it's slower.

There is some irony in the fact that we'd be searching for a damaged CD in order to ensure proper rips...

...a deep, rich irony indeed...

What is the reason you do not want to rip to WMA? I pretty much converted my entire CD collection that way and saved loads of hard drive space. Do you see any big difference in sound quality between the two formats?

Ed

When MS decides to change the format of WMA and no longer support the old format, you'll probably have no recourse other than to reencode your entire collection. Since there are any number of open source mp3 implementations, not to mention that the mp3 spec is open (in the old 1980s sense of the word), you're not going to have that problem.

Not to mention the political objective related to Microsoft's kowtowing to the recording industry with their asinine Palladium scheme and the whole concept that I would ever want to restrict the playability of audio files I've made myself.

Yup, I've been using audiograbber for years and my rips are perfect. Usually do a CD in just a couple of minutes and I've get to get a bad mp3. My CDs, like yours are well looked after though.

I have to say I am now a complete EAC convert. Despite my pristine CDs EAC still does find some of them that take lots of retries to get a perfect copy.

Oddly it is often CDs without a single visible mark that EAC ends up working hardest on.

I've been using audiograbber for years and my rips are perfect

same here. for bulk rips, AG seems the fastest. then do a batch LAME encode overnight.

now i only rip when the odd single cds is purchased / acquired. For these times, EAC is the easiest,securest single button solution (just hit 'MP3' button and come back in half an hour!)

In reply to:

---

for bulk rips, AG seems the fastest. then do a batch LAME encode overnight

---

Isn't this possible in EAC. Your post made me want to try it but I can't find the option...

yes it can,
but with EAC you still have to do the tagging, AG takes care of that

Maybe you're using an older version, but EAC tags just fine.

Can I rip 100 CDs to WAV and come back two days later to batch encode with LAME (through EAC) with tags?

Don't know what version of EAC was being commented on, nor what new support it has, but it definitely did NOT support this feature in the past. I don't know of anything other than AG that did.

Bruno

Can I rip 100 CDs to WAV and come back two days later to batch encode with LAME (through EAC) with tags?

Yes, if you display a little ingenuity. When I rip (with EAC), I get it to put all of the tags that I care about in the filename (so I end up with album - track - artist - title.wav or whatever). Then I use a Python script to encode them all using LAME. Then, when that's done (several hours/days later), I have another Python script which uses a regex to figure out the tags from the filename, and which runs id3tag (from id3lib) to apply the tags.

I'm currently hacking on a Ruby script to generate/tag FLAC files from the WAV files, so that I don't have to re-rip anything in future.

OH! Batch encoding. Sorry, I read that too fast. Don't mind me.

For batch encoding in Windows I used RazorLame. Haven't had a Windows machine in quite a while, so I can't say for sure if it is still the best option.

Then, of course, you'd have to go back and create the tags from the file name, unless they've added that option to RazorLame lately.

This is possible (Tools menu, 'Compress WAVs Alt+V'), but the .wav files have to have all the tag info in their name, as mentioned. The only thing I'd mention is that EAC must be left open during the entire encoding process. If you quit EAC while LAME processes are still running, they will quit also, leaving incomplete .mp3's with no warnings. If you've set EAC to run the LAME threads minimized, this is not immediately obvious. You can also choose how many concurrent LAME sessions to run.

-Zeke

If you're into Linux, and batch ripping/encoding/tagging is important to you,
consider to use Jack

Jack is written in Python and acts as a frontend for various rippers
(like cdparanoia) and various encoders (like Lame and oggenc).



There are lots of cdparanoia/lame frontends, but Jack
has some really cool features, like

• Jack will continue an interrupted session and only redo what is necessary
• it will find the results of a previous rip even if it is badly filed
• it supports both cddb and freedb (officialy only freedb)
• editing a saved freedb query result will let you automatically rename and retag the affected tunes
• using shell scripting, you can rip and encode multiple CD's after each other, in parallel, or both
• it will save a history of every rip, including cdparanoia output
• if you've got the space, you can keep the wav's and re-encode later
• It uses curses to show its progress (ie does not require X)
  

Using two Nakamichi SCSI 5-CD changers and a tower with five old Toshiba
SCSI CD-ROM drives, I have ripped hundreds of CD's with very few intervention.

The only drawback with Jack was the lack of id3v2 support, but this is
finally coming now, it's in the CVS for testing. And it should be said that
Jack isn't easy to set up; it is dependent on lots of other stuff. But once
it runs, it rocks.

Pim

If you're into Linux, and batch ripping/encoding/tagging is important to you, consider to use Jack

Hey, he stole my name.

(Jack was the name I used for a Fraunhofer/LAME front-end program I wrote a long time ago. Not very many features and isn't all that great, but at the time it was the only tagger/encoder front end that formatted the data the way I wanted it and used the Enter key properly to move to the next field.)

So what you're telling me is that I'm already using the best ripper available, AudioGrabber. That's what I thought. Still going strong after two years. The only reason I'd have to use EAC (yes, it's free), is for its secure ripping. However I've only had a problem with a handful of tracks that received some errors I didn't catch while ripping. Re-ripping solved that of course. AG2.0 is long overdue, but I no longer need to rip 500 CDs at a time (unless someone wants to donate a large crate of discs - I'm always open to that )

Bruno
(Just bought a house (today) - I'll take a donation of anything at this point)

Congrats on the house purchase.
Glad to see you've gotten AG working finally

No need for ingenuity. EAC will do this for you.

If you rip a whole stack of CDs EAC will queue them up and start encoding one by one (or two by two if you have dual CPUs like me). If you then simply quit the main EAC application (not the 1 or 2 encoding windows - let them finish), it will remember where it was up to and all the tags it had to use.

If you simply run EAC when you are ready to encode, it will start encoding from the next track automagically.

All ID3 tags are filled in as if you hadn't quit EAC. On normal single artist albums (i.e. not various artist ones) I don't even need to fix up tags with EAC.

BTW: I use command line LAME encoding (i.e. not the inbuilt .DLL) so I don't know whether this works with the .DLL encoding method.

I am trying to set up AG and Lame to encode some of my wav files that were ripped using EAC. I am having a problem getting the file to encode. I checked external encoder in MP3 options, using user arguments --alt-preset standard. I pointed AG to the folder where LAME.exe is located. I then drag a wav file from Windows Explorer onto AG. It asks me what I want to do and I click create MP3. The dos screen blinks up on the screen for a second and disappears. Then nothing happens or shows up in the directory I specified. Any ideas on what to do to fix this? Would it be easier to use the Lame.dll file in AG as an internal encoder? The only problem is that if I do this it does not seem to let you create user arguments like the external encoder dialogue box does. Any insight into this sure would be appreciated.

It sounds to me like lame is starting and immediately exiting. Do you have to specify something in the command-line options to tell it what filename to encode? It might be something like ``%s''. (I know nothing about AG; just taking a guess.)

Seems it may be a problem with my user arguments string. I am not too privy as how to write the argument I need. Maybe one of you might be able to help.
1. Wave file is named Artist - Album - Track # - Title
2. I want to use the external Lame.exe to encode from a Ripped directory.
3. I want the encoded file to be placed in Encoded\Artist \Album parent -child directories after encoding.
4. I also want to tag the files from the file name.
5. I want to use --alt-preset standard as my switch.

Any AG users have any idea how to enter this?

After I made the original post I went back and found that to be the case. I just don't know how to interpret what I want to do so AG gets the job done for me.

sounds like it does not like what you have in the external encoder dialogue box
what do you have in there?
remember it should start with %S %D and then have the lame encoding parameters