I just bought a Mac computer and I've been using EAC on Windows to rip all my cd's. Is there anything out there on Mac that can give me the same quality?

How comfortable are you using the command line? If you don't mind using Terminal (and it's not hard, believe me), your only real choice is to use cdparanoia 0.9.8. The GUI front ends that use cdparanoia -- like xACT and Max -- are too limited. They won't allow you to specify offsets, and Max currently does not even generate a log. cdparanoia will allow you to do what you want.

You can easily install it via a package manager like Fink or Macports.

If you just want something basic, use xACT.

I'd try to get Ruby Ripper ported over. Maybe it's FUD but there's a dark cloud looming over cdparanoia's ability to adequately deal with drives that cache audio data.

I like Max a lot. It's not as powerful as EAC but it does the job quite well, can export to a lot of different formats and uses cdparanoia for ripping (as Pepzhez said without the opportunity to specify offsets, but if you don't use these settings in Windows you don't have to care).

You can download it at http://sbooth.org/Max/

If you're running Leopard use the latest beta which fully supports 10.5

...again, the looming caching issue.

http://sbooth.org/forums/viewtopic.php?f=5...fa688bdbcaca640

Actually, you *can* defeat the cache, but you need to change the readhead value in paranoia/p_block.c, then rebuild cdparanoia.

Yes, it does work.



http://www.hydrogenaudio.org/forums/index....mp;#entry467357




http://www.nabble.com/cdparanoia-and-cache-to6662854.html

Better to change the value to 300 (for 2 MB buffer), unless you have a mega-caching Plextor.

IOW, without the patch you may run into trouble.

It would have been nice if you had pointed this out in the first place.

PS: The buffer size is not a good indication of how much audio data a drive caches.

EDIT: "you'll run into trouble" changed to "you may run into trouble".

It's easy enough to change the read ahead value. If you are using cdparanoia through Fink, you can make the edit using Xcode, and then let Fink rebuild it.

Why aren't the front end designers making this change before they compile cdparanoia for their apps? They really ought to!

It may be easy enough to change, but being aware of potentially needing the change is another issue altogether!

You are correct about the buffer size not being an indication of how much audio a drive caches, but it's nevertheless easy enough to experiment with different read ahead values in order to make certain that the error correction is actually working.

I have uploaded three different cdparanoia builds, with different 'readahead' values, for those willing to give it a try.
1. cdparanoia-150 (default)
2. cdparanoia-1200 (8x)
3. cdparanoia-4800 (32x)

http://rapidshare.com/files/98802306/cdparanoia.zip.html

Indeed! There aren't too many users who even want to touch the command line, much less dig around in Xcode searching for lines to edit. And then rebuilding......

My experience is that most Mac users remain unaware of these issues. One Mac evangelist even told me that offsets were "just a Windows thing; they need it because they have an inferior OS."

It doesn't help that the front ends aren't even allowing users the provision to specify the offsets. cdparanoia can do so much more than the front ends will have you believe. (sigh)

D'oh! I just remembered something. There's a very nice free script for using cdparanoia via iTunes --

http://scriptbuilders.net/files/itunestocdparanoia0.10.html

Using this in conjunction with one of the paranoia rebuilds uploaded by krmathis (above) may be all you'll ever need.

This script will automatically tag, and will do double verification (if you want it to). Plus, you can specify offsets for multiple drives. It also produces a quite detailed log.

I have used this in the past, and it works quite well. The author did an impressive scripting job.

I haven't yet tested this on Leopard, but I will. A couple of the paths may have slightly changed for 10.5, but I can edit/update it, if need be.

Do any of the mentioned programms support AccurateRip, or is there any other way (maybe a script for this exact purpose) to test the ripped tracks/image against the AR database?

No.

The folks over at AccurateRip believe that Windows is the only OS that exists.

If your heart is set on using EAC, you can run it through WINE on an Intel Mac.

Like IP addresses?



http://www.rinkworks.com/stupid/cs_online.shtml



(I love Macs, but some of the users do have false ideas about them.)

I see no reason why someone with a little programming knowledge couldn't create a script that would allow a MAC user to check rips against the AR database with the wealth of knowledge that has already been shared on this forum.

If anyone wants any help in doing this and if it's ok with Spoon, I'd be more than happy to lend my services. The unfortunate part is that I don't code.

...and if we're lucky, maybe the Windows and *nix users can get a much needed improvement over what currently exists.

>The folks over at AccurateRip believe that Windows is the only OS that exists.

There is an open source perl / c++ script, nothing to stop this being written into a ripper on Linux, but that requires work, it is easier to instead make out that AR is closed on anything but Windows...

There are really three parts to cdparanoia: the interface, paranoia, and the front end (CLI). The interface presents an OS-neutral version of a CD drive used for reading blocks/sectors from the disc. paranoia (the engine) performs overlap checking, jitter detection, etc. of the data returned by the interface. Finally, the CLI adds functionality such as offset correction, output file format selection, endian specification and more.

With this in mind, I don't believe it is fair to say or imply that Max is a stripped-down front end to cdparanoia. Max uses paranoia directly- not the CLI- which as mentioned above does not natively support offset correction. At the time I implemented the ripping engines of Max, offset correction was not a high priority feature.

While I understand the appeal of "bit-perfect" rips, practically speaking offset correction doesn't make a huge difference. The drive I use on my MacBook Pro has a read offset of +102 sample frames. So, my non-offset corrected rips are are off by 102/44100 = .0023 seconds. For the vast majority of listening will 0.0023 seconds make a big difference? I seriously doubt it.

This isn't to say I discount the validity of offset correction; in fact, I plan on adding the feature to Max in the future. Offset correction allows for better comparison of DAE accuracy, thanks to Accurate Rip.

When I shifted from Windows to Mac 18 months ago (Intel C2D iMac), I thought I would need VMware or Parallels for some Windows apps. I was wrong; it turns out there was nothing of great value that I was missing. I simply run everything in OS X and I am a very happy camper.

I have been using both Max and of course iTunes for all CD rips. When I find any actual problems with this, I might note it - but there haven't been any. EAC is just a tool I used to use when it appeared necessary, but in my current setup it does not appear to be of value. Case closed for now.

It may not matter to many folks, but of course ITUNES is NOT a secure ripper (such as EAC or dbpoweramp). I'd have no problem with managing a music collection with ITUNES but would not feel comfortable relying on it to get secure rips. Don't know anything about MAX.

sbooth, I didn't mean to imply that Max is a stripped down front end to cdparanoia. I do think that your application has the potential to be the ultimate Mac ripping program, and I VERY MUCH appreciate your work. I think a ripping log is far more useful to have than offset settings.

If you please, do check out the log that the 'iTunes to cdparanoia' script generates. (I linked to it above.) It would be wonderful to have Max output something like this.

Thanks. I was not aware of the existence of this script.

A quick glance at it leads me to wonder what the minimum ripper feature requirements would be? Offsets, obviously, and am I correct in my impression that this requires the output file to be written in WAV format only?

(Not complaining, just trying to grasp this.)

Offset correction and an internal CRC calculation (of discID and track crc), the ripping program could implement the script internally and lookup its self.

what about X Lossless Decoder? Im not all that savy when it comes to scripts and stuff. I like EAC because it did a good job of ripping my cd collection and it sounds better than iTunes. Also I like the fact that it put my sounds in folders and sub-folders.

i second that question
anyone?

(here´s the link to the homepage of XLD)

X Lossless Decoder is a, well, decoder/converter; not a ripper. Perhaps it works fine for its intended purpose. I haven't used it it, so I couldn't tell you. Note that Max can convert into all of these formats as well, plus it can also rip CDs.

If the goal is to rip CDs securely on OS X (complete with an output log), the only reliable option at the moment is to use the patched cdparanoia build (for caching drives). For GUI/tagging convenience, you can use it in conjunction with the 'itunes to cdparanoia' script.