Which CD DAE software is the most accurate for Mac OS X?, Is XLD the most accurate with feature set? Options

[macman4hire]

I would like to archive my CD collection and have chosen to use FLAC as my lossless codec. I believe FLAC's wide range of hardware support, comparable compression rates vs. other lossless codecs and the encode/decode rates are a par with its competition. I have tried the following software for DAE XLD, Max, xACT, iTunes and Toast. I am leaning towards using XLD with its new features of AccurateRip, disable cache and its log report. Please read the following questions posted below and give your answers and advice about XLD or any other DAE software for Mac Os X.

1. I have read CD Paranoia will not allow the cache to be disabled if the cache is larger than 1 meg. Is the this correct?

2. Does the disable cache feature work in XLD?

3. Can the AccurateRip feature be trusted in XLD?

4. Can the the error log report be trusted in XLD?

5. What about using VMware Fusion with XP and EAC. Would this method produce accurate results?

Thank you for answers and help. 500 plus CD's to rip!

This post has been edited by macman4hire: Sep 2 2008, 05:38

[Pepzhez]

I have spent a lot of time in other forums rigorously testing XLD with a group of other people. So far we have had very satisfactory results. The XLD developer has been very responsive to our suggestions, plus he has also used our test results to incorporate new features and work out any bugs.

1. I have read CD Paranoia will not allow the cache to be disabled if the cache is larger than 1 meg. Is the this correct?

Yes, but most drives cache less than 1 MB of audio anyway. Which drive will you be using to rip? This usually is not a problem. Certainly no one in the testing group has encountered caching problems.

2. Does the disable cache feature work in XLD?

It appears to work, yes, but see above.

3. Can the AccurateRip feature be trusted in XLD?

It is as reliable under XLD as it is with EAC, yes. XLD's AccurateRip feature had some bugs in the beginning (CRC miscalculations), but those problems have been successfully solved.

4. Can the the error log report be trusted in XLD?

Yes. XLD has added some very useful features over the past week that make it even more secure. Namely, "verify suspicious sectors" and "test before copy."

So far, all comparisons to EAC rips have proven to be identical in almost all cases. Damaged discs can produce varying results between the two apps, but we are talking about damaged discs that neither EAC nor XLD can successfully salvage. (I don't know why we've been having so much fun throwing so many damaged discs its way, really.)

5. What about using VMware Fusion with XP and EAC. Would this method produce accurate results?

Yes. It'll be much slower than using a native OS X app like XLD, though.

Why not try XLD for yourself? It's free. Just download it, use auto update in order to insure that you have the latest build, find the proper offset for your drive, then try ripping a few discs. See if you are happy with the results. I recommend that you rip with both "test before copy" and "verify suspicious sectors" options turned on.

This post has been edited by Pepzhez: Sep 2 2008, 06:40

[Pepzhez]

I failed to answer the main question, didn't I? I would say that XLD is by far the best Mac ripper at the moment.

[macman4hire]

Thank you for your answers Pepzhez. The drives I use are listed below.

Model Correction Offset Submitted By Percentage Agree

HP - CD-Writer+ 7500 +1160 2 100%
PIONEER - DVD-RW DVR-103 -54 4 100%
SONY - DVD RW DW-D150A +48 17 100%

[Tyashki]

Um, does any Mac use those?

Also, is there a way of finding out the read offset without resorting to installing Windows? (I have a 2,1 Macbook)

[tim.lance]

Um, does any Mac use those?

Also, is there a way of finding out the read offset without resorting to installing Windows? (I have a 2,1 Macbook)

Use System Profiler to find your drive (probably a Matshita).
/Applications/Utilities/System Profiler>Hardware>Disc Burning

Go to Accurate Rip's drive listing and find your drive there. Matshita drives are labeled Panasonic.

[spoon]

Matshita is such an unfortunate name here in the west...

[macman4hire]

I ripped this CD and XLD produce this log report posted below. This feature is excellent!

CODE

X Lossless Decoder version 20080830 (84.0)

XLD extraction logfile from 2008-09-01 21:20:51 -0400

Michael Hedges / Oracle

Used drive : HP CD-Writer+ 7500 (revision 1.0a)

Use cdparanoia mode : YES
Disable audio cache : YES
Read offset correction : 1160
Max retry count : 100

TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:00 | 03:07:70 | 0 | 14094
2 | 03:07:70 | 03:30:30 | 14095 | 29874
3 | 06:38:25 | 02:12:00 | 29875 | 39774
4 | 08:50:25 | 03:31:05 | 39775 | 55604
5 | 12:21:30 | 02:40:42 | 55605 | 67646
6 | 15:01:72 | 04:10:40 | 67647 | 86436
7 | 19:12:37 | 02:22:55 | 86437 | 97141
8 | 21:35:17 | 04:04:10 | 97142 | 115451
9 | 25:39:27 | 03:21:73 | 115452 | 130599
10 | 29:01:25 | 03:00:05 | 130600 | 144104
11 | 32:01:30 | 02:11:62 | 144105 | 153991
12 | 34:13:17 | 02:45:50 | 153992 | 166416
13 | 36:58:67 | 04:19:65 | 166417 | 185906
14 | 41:18:57 | 03:08:58 | 185907 | 200064

All Tracks
Filename : /Users/macman4hire/Desktop/Oracle.flac
CRC32 hash : EABF8784
CRC32 hash (skip zero) : 6EAD7433
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 01
CRC32 hash : C94ACE7A
CRC32 hash (skip zero) : 15AFAF2C
AccurateRip signature : D3A7BC46
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 02
CRC32 hash : EA21E84A
CRC32 hash (skip zero) : 0C3F1691
AccurateRip signature : F7FEBB42
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 03
CRC32 hash : 423BFCF1
CRC32 hash (skip zero) : 4C9EA8EC
AccurateRip signature : EE1D2449
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 04
CRC32 hash : 44BB6BA3
CRC32 hash (skip zero) : 0D968679
AccurateRip signature : A0984EAA
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 05
CRC32 hash : 70C4EA9B
CRC32 hash (skip zero) : 248D67FC
AccurateRip signature : 765C0C6E
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 06
CRC32 hash : 6AB7533A
CRC32 hash (skip zero) : 50D12B36
AccurateRip signature : 45020BB7
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 07
CRC32 hash : 37444EED
CRC32 hash (skip zero) : BC207CF5
AccurateRip signature : 62008641
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 08
CRC32 hash : A10590CB
CRC32 hash (skip zero) : 6A63CE63
AccurateRip signature : 49C5B93E
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 09
CRC32 hash : EA7DEBA5
CRC32 hash (skip zero) : D319FC09
AccurateRip signature : A907A9AE
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 10
CRC32 hash : 235D169F
CRC32 hash (skip zero) : 2AF2EEEA
AccurateRip signature : 058E2C0D
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 11
CRC32 hash : DB6328F6
CRC32 hash (skip zero) : 3379536F
AccurateRip signature : E06C7EDA
->Accurately ripped! (confidence 27)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 12
CRC32 hash : B9214E7D
CRC32 hash (skip zero) : 45BD2AAC
AccurateRip signature : A56B787B
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 13
CRC32 hash : 8806A2C3
CRC32 hash (skip zero) : 4EB456D6
AccurateRip signature : 39F524B9
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

Track 14
CRC32 hash : 31599532
CRC32 hash (skip zero) : EA0D715E
AccurateRip signature : 5A15CF24
->Accurately ripped! (confidence 26)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0

No errors occurred

End of status r

I choose to save as single file(+cue) with album art work embedded in the FLAC file. XLD produces an external cue sheet and also embeds the cue sheet into the FLAC file.



Moderation: Code changed to codebox.

This post has been edited by macman4hire: Sep 7 2008, 06:09

[tim.lance]

To have more faith in the rip you might want to check both test before copy and verify suspicious sectors.

[greynol]

For tracks that AR verifies, T&C is a complete waste of time.

[tim.lance]

For tracks that AR verifies, T&C is a complete waste of time.

Is there a way to know that there is an AR entry for a CD before you rip (whether using XLD or EAC)? Please forgive my ignorance. For a period of time I tried no classical discs I was ripping were in there so I quit paying attention. With this testing I have found some so am only now learning about AR.

[greynol]

In EAC my advice is to copy, check AR and then test. I don't know if this is possible with XLD.

The other option is to test a track and see if it can be verified. If so then proceed to copy without testing. If not then use test and copy if you like, though with EAC it may still be a waste if you're using secure mode without C2 pointers.

Can someone tell me if the GUI XLD has the ability to display test and copy CRCs like EAC or color-code them like dBpa? I suppose I should back up and ask if the option in question behaves the same way as EAC's test and copy feature.

[tim.lance]

In EAC my advice is to copy, check AR and then test. I don't know if this is possible with XLD.

The other option is to test a track and see if it can be verified. If so then proceed to copy without testing. If not then use test and copy if you like, though with EAC it may still be a waste if you're using secure mode without C2 pointers.

Can someone tell me if the GUI XLD has the ability to display test and copy CRCs like EAC or color-code them like dBpa? I suppose I should back up and ask if the option in question behaves the same way as EAC's test and copy feature.

Yes, XLD does display test and copy though no color-code. Unsure what you mean by "behaves the same way."

Here's a sample for a track:

Track 01
Filename : /Volumes/Jean/XLD test/01 - Callin' Baton Rouge.flac

CRC32 hash (test run) : 0038CAD0
CRC32 hash : 0038CAD0
CRC32 hash (skip zero) : 1F1C285B
AccurateRip signature : 48ED22AD
->Accurately ripped! (confidence 50)
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 0
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0

[greynol]

I'm interested in what is displayed in the GUI, not the log. I already know what's shown in the log file.

Can XLD perform a test pass without performing a copy pass?

[Pepzhez]

The only thing displayed in the GUI is a progress bar with a countdown timer (separate progress bars per track, one of each for test and copy stages). There is no EAC-like color coding displayed.

There is currently no option to perform only a test pass, although that could be easily implemented. If you mean just do "copy," yes, you can choose that option.

If you know that your disc is in the AR database, you can choose not to perform a test pass. For that matter, you could just do a burst rip (turn cdparanoia off). If AR gives the all clear, then you are fine.

Needless to say, if your disc is not in AR (and a surprising number of them are not, particularly classical, jazz, obscure Japanese psychedelia, etc.), it's best to always use the "test before copy" as well as "verify suspicious sectors" options.

This post has been edited by Pepzhez: Sep 3 2008, 05:13

[macman4hire]

1. How do you check to see if a CD is in the Accuraterip data base before ripping?
2. How do you turn off cdparanoia to do a burtst rip?
3. How long is an average rip when you check verify suspicious sectors and test before copy take?

This post has been edited by macman4hire: Sep 3 2008, 07:14

[Pepzhez]

How do you check to see if a CD is in the Accuraterip data base before ripping?

There isn't any way to check AR before ripping, at least not with XLD. A bit annoying, I must admit. My not entirely satisfactory solution to this has been to burst rip the first track of a disc, so I can then quickly see if AR recognizes it or not. Certainly not an ideal solution. Hopefully this issue will be addressed in upcoming XLD builds.

How do you turn off cdparanoia to do a burst rip?

Uncheck "Rip as accurate as possible (CDParanoia Mode)"

How long is an average rip when you check verify suspicious sectors and test before copy take?

About twice as long as a non-"test before copy" rip. I recommend always having "verify suspicious sectors" on when using "test before copy." It doesn't slow down the rip any, and "verify suspicious sectors" will inform you precisely where the problem is if the ripper encounters any inconsistencies between the test and copy stages.

This post has been edited by Pepzhez: Sep 3 2008, 07:38

[spoon]

EAC & dBpoweramp will detect if the CD is in AR before ripping and convey that information, but it might be a different pressing (which would not be known until ripping is done).

[tim.lance]

I'm interested in what is displayed in the GUI, not the log. I already know what's shown in the log file.

Too damn late that was and now too early. I refrain from saying more!

[Tyashki]

Um, does any Mac use those?

Also, is there a way of finding out the read offset without resorting to installing Windows? (I have a 2,1 Macbook)

Use System Profiler to find your drive (probably a Matshita).
/Applications/Utilities/System Profiler>Hardware>Disc Burning

Go to Accurate Rip's drive listing and find your drive there. Matshita drives are labeled Panasonic.

Sorry to be a pain, but here's my issue. My drive is designated as "HL-DT-ST DVDRW GSA-S10N". The drive list has an S10, but no S10N. I tried the offset marked for the S10 (667) but no luck.

Any chance someone else has a second gen macbook here?

[tim.lance]

Sorry, no help here and I've checked three different MacBooks and one MacBook Pro. All but one MB have the Matshita DVDs. The other MB has Matshita CD.

Moderation: Removed useless quotation.

This post has been edited by greynol: Sep 3 2008, 17:47

[macman4hire]

Today XLD added an additional feature under the Test before copy preference check box. This new feature located under the Test before copy preference is Only when the track does not exist in Accuraterip DB.

Does any know who the developer is? The developer must read the HA board as this topic was just discussed last night. I hope the developer noticed the topic about the absence of the ability to check if the CD is in the Accuraterip DB before ripping is started. If this feature were to be added it would give the user the option to use the burst rip mode vs. the CDParanoia mode which takes about 3.5 times longer on my hardware. If the users CD condition is fine they could rely on the Accuraterip results to determine if one should rerip using the CDParanoia mode. The developer should be thanked and congratulated on bringing Mac OS X out of the dark ages of DAE.

[Kees de Visser]

This thread made me curious, so I tried to download XLD but the link seems broken (404 not found):
http://tmkk.hp.infoseek.co.jp/xld/xld-gui-20080822.tbz
Are there any alternative locations ?

[macman4hire]

Click on this link Down Load XLD to down load XLD. This link is from the MacUpdate site. It appears the link on the XLD site is broken at the moment. Enjoy!

After launching XLD it should ask you if you want to update say yes and you will have the most recent version of XLD.

This post has been edited by macman4hire: Sep 4 2008, 06:47

[Kees de Visser]

That link works fine and so does XLD's built-in updater. Thanks.
There doesn't seem to be any help file. Is there any additional info or is this forum the best source for that ?

- I finally found my (MacBook's) drive offset on the accuraterip site. I'm not a programmer, but wouldn't this be easy to do automatically ? XLD's log lists my drive correctly, so that info is known. Can't be too difficult to do a lookup, would it ?
- The log looks rather comprehensive. This is a great advantage over Max, my favorite ripper until now.
- I inserted a (classical) cd and XLD displays the track info correctly. However, when I click on "Get CD Track Names", the info changes and the names now include Japanese (?) characters. Are there different databases being used ?

First impressions are very positive.