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!
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.
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.
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%
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)
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 (http://www.accuraterip.com/driveoffsets.htm) and find your drive there. Matshita drives are labeled Panasonic.
Matshita is such an unfortunate name here in the west...
I ripped this CD and XLD produce this log report posted below. This feature is excellent!
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.
(http://farm4.static.flickr.com/3285/2823606060_d0e03cee2c.jpg)(http://farm4.static.flickr.com/3194/2822821309_cb6fca72a9_m.jpg)
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Code changed to codebox.[/size]
To have more faith in the rip you might want to check both test before copy and verify suspicious sectors.
For tracks that AR verifies, T&C is a complete waste of time.
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.
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.
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
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?
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.
- How do you check to see if a CD is in the Accuraterip data base before ripping?
- How do you turn off cdparanoia to do a burtst rip?
- How long is an average rip when you check verify suspicious sectors and test before copy take?
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.
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).
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!
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 (http://www.accuraterip.com/driveoffsets.htm) 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?
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.
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.
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 (http://tmkk.hp.infoseek.co.jp/xld/xld-gui-20080822.tbz)
Are there any alternative locations ?
Click on this link Down Load XLD (http://www.macupdate.com/download.php/23430/xld-gui-20080822.tbz.zip) 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.
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.
.
- 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.
Has that CD been in your computer before? In iTunes? Or, in Max using the iTunes Metadata script? If so, what you first saw is the tags from Gracenote CDDB which is what iTunes uses. Apple pays Gracenote a fee. Max, XLD(?), and most others use Musicbrainz (free). Once a bunch of metadata is associated with a CD the OS remembers it. In your case, when you had it get names the previous were replaced. So, yes, there is in effect two different databases used.
I wonder if Max's script can be modified for XLD?
I have created a comparison for three CD rippers that use CDParanoia on the Mac. This comparison is in no way a definitive comparison as the feature sets of these applications constantly change. Please contact me if any information appears inaccurate or you feel a crucial feature has been omitted. I attempted to list the features in an unbiased manner. All these applications offer several audio codecs which are listed in HA's 2008 ripping/encoding polls which confirms the most the popular ones are offered. I intentionally did not list the audio codecs because the focus for this comparison is the DAE capabilities on the Mac.
(http://farm4.static.flickr.com/3010/2890249662_5c22a8557a.jpg)
Click here for a larger image (http://farm4.static.flickr.com/3010/2890249662_9927d3c966_o.gif)
Today XLD added a new feature to recognize if a CD is in the AccurateRip DB before ripping is started. This will give the user the option to use the burst rip mode vs. the CDParanoia mode which takes longer to rip. If the users CD condition is fine they could rely on the AccurateRip results to determine if one should rerip using the CDParanoia mode. Another great feature added quickly by the developer!
Notice [AR] in the top of XLD application window in front of the album name. This indicates that this CD is in the AccurateRip DB.
(http://farm4.static.flickr.com/3208/2828382955_277a0a50cc.jpg)
I have created a comparison for three CD rippers that use CDParanoia on the Mac. This comparison is in know way a definitive comparison as the feature sets of these applications constantly change. Please contact me if any information appears inaccurate or you feel a crucial feature has been omitted.
From the other thread on this subject, I think it's not yet entirely clear that XLD actually disables the drives cache.
Just an update on Mac DAE. Today sbooth the developer of Max posted on his forum that he is working on a CD ripper with following features:
* Drive read offset support
* AccurateRip support
* Multiple metadata sources [via plugins], including MusicBrainz, FreeDB and iTunes
* Plugin-based encoders
He also posted that he has currently completed maybe 70% of the features, and plans a public beta soon.
I have created a comparison for three CD rippers that use CDParanoia on the Mac. This comparison is in know way a definitive comparison as the feature sets of these applications constantly change. Please contact me if any information appears inaccurate or you feel a crucial feature has been omitted.
From the other thread on this subject, I think it's not yet entirely clear that XLD actually disables the drives cache.
I can place a comment in notes area of the Mac CD Ripper Comparison that some HA members question this features effectiveness.
Their seems to be some disagreement if the disable cache is effective in XLD. I am in no way an expert about DAE. My goals are to learn as much as I can about this subject and help inform the Mac community. We must find a way to test this feature in a way the majority can agree on. Unfortunately I did not have the technical expertise to devise such a test and must rely on the help of other members of HA to accomplish this. Any help to reach this objective would be appreciated.
4. Can the the error log report be trusted in XLD?
Thank you for answers and help. 500 plus CD's to rip!
Here's a damaged disk I just ripped where the log report shows no problems on some tracks the AR does not show as a match:
X Lossless Decoder version 20080906 (85.2)
XLD extraction logfile from 2008-09-06 11:38:38 -0400
Frank Zappa & The Mothers Of Invention / Playground Psychotics (Disc 1)
Used drive : PLEXTOR CD-R PX-230A (revision 1.02)
Use cdparanoia mode : YES
Disable audio cache : NO
Read offset correction : 738
Max retry count : 100
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 00:00:32 | 01:00:40 | 32 | 4571
2 | 01:00:72 | 01:20:50 | 4572 | 10621
3 | 02:21:47 | 01:18:73 | 10622 | 16544
4 | 03:40:45 | 00:23:47 | 16545 | 18316
5 | 04:04:17 | 01:21:30 | 18317 | 24421
6 | 05:25:47 | 00:55:35 | 24422 | 28581
7 | 06:21:07 | 00:29:43 | 28582 | 30799
8 | 06:50:50 | 01:11:25 | 30800 | 36149
9 | 08:02:00 | 00:24:72 | 36150 | 38021
10 | 08:26:72 | 02:02:15 | 38022 | 47186
11 | 10:29:12 | 00:25:00 | 47187 | 49061
12 | 10:54:12 | 02:40:65 | 49062 | 61126
13 | 13:35:02 | 01:46:15 | 61127 | 69091
14 | 15:21:17 | 01:30:18 | 69092 | 75859
15 | 16:51:35 | 02:26:15 | 75860 | 86824
16 | 19:17:50 | 02:59:67 | 86825 | 100316
17 | 22:17:42 | 01:39:48 | 100317 | 107789
18 | 23:57:15 | 04:52:00 | 107790 | 129689
19 | 28:49:15 | 04:23:27 | 129690 | 149441
20 | 33:12:42 | 02:53:40 | 149442 | 162456
21 | 36:06:07 | 06:19:00 | 162457 | 190881
22 | 42:25:07 | 04:43:25 | 190882 | 212131
23 | 47:08:32 | 00:57:25 | 212132 | 216431
24 | 48:05:57 | 02:59:10 | 216432 | 229866
25 | 51:04:67 | 05:53:55 | 229867 | 256396
26 | 56:58:47 | 06:06:53 | 256397 | 283899
Track 01
Filename : /Users/davesprou/Desktop/XLD Rips/01 Frank Zappa & The Mothers Of Invention - Here Comes The Gear, Lads.m4a
CRC32 hash : F7B0D958
CRC32 hash (skip zero) : 45B6FC8F
AccurateRip signature : 0FC9203C
->Accurately ripped! (confidence 5)
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
Track 02
Filename : /Users/davesprou/Desktop/XLD Rips/02 Frank Zappa & The Mothers Of Invention - The Living Garbage Truck.m4a
CRC32 hash : D544CB3E
CRC32 hash (skip zero) : 2C143187
AccurateRip signature : 1120B36A
->Accurately ripped! (confidence 5)
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
Track 03
Filename : /Users/davesprou/Desktop/XLD Rips/03 Frank Zappa & The Mothers Of Invention - A Typical Sound Check.m4a
CRC32 hash : 3493634D
CRC32 hash (skip zero) : 3C8C298D
AccurateRip signature : D7E0472C
->Accurately ripped! (confidence 5)
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
Track 04
Filename : /Users/davesprou/Desktop/XLD Rips/04 Frank Zappa & The Mothers Of Invention - This is Neat.m4a
CRC32 hash : ACDB1465
CRC32 hash (skip zero) : D0AED323
AccurateRip signature : 22947D66
->Accurately ripped! (confidence 5)
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
Track 05
Filename : /Users/davesprou/Desktop/XLD Rips/05 Frank Zappa & The Mothers Of Invention - The Motel Lobby.m4a
CRC32 hash : C7E1E5A0
CRC32 hash (skip zero) : A34721DA
AccurateRip signature : 6F09E226
->Accurately ripped! (confidence 5)
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
Track 06
Filename : /Users/davesprou/Desktop/XLD Rips/06 Frank Zappa & The Mothers Of Invention - Getting Stewed.m4a
CRC32 hash : 19C1FBD2
CRC32 hash (skip zero) : 6DC511EB
AccurateRip signature : 0CEDB716
->Accurately ripped! (confidence 5)
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
Track 07
Filename : /Users/davesprou/Desktop/XLD Rips/07 Frank Zappa & The Mothers Of Invention - The Motel Room.m4a
CRC32 hash : 3606C5B2
CRC32 hash (skip zero) : D426AD6C
AccurateRip signature : 83CDD72D
->Accurately ripped! (confidence 5)
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
Track 08
Filename : /Users/davesprou/Desktop/XLD Rips/08 Frank Zappa & The Mothers Of Invention - Don't Take Me Down.m4a
CRC32 hash : 23024286
CRC32 hash (skip zero) : 01D36E8D
AccurateRip signature : 191D3297
->Accurately ripped! (confidence 5)
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
Track 09
Filename : /Users/davesprou/Desktop/XLD Rips/09 Frank Zappa & The Mothers Of Invention - The Dressing Room.m4a
CRC32 hash : 3C61170D
CRC32 hash (skip zero) : 24809A51
AccurateRip signature : 24FDE159
->Accurately ripped! (confidence 5)
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
Track 10
Filename : /Users/davesprou/Desktop/XLD Rips/10 Frank Zappa & The Mothers Of Invention - Learning "Penis Dimension".m4a
CRC32 hash : 5914E7C6
CRC32 hash (skip zero) : 84A79476
AccurateRip signature : 6BB93C3B
->Accurately ripped! (confidence 5)
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
Track 11
Filename : /Users/davesprou/Desktop/XLD Rips/11 Frank Zappa & The Mothers Of Invention - You There, With The Hard On!.m4a
CRC32 hash : AB913AEC
CRC32 hash (skip zero) : 796E3BDD
AccurateRip signature : FF3A70EE
->Accurately ripped! (confidence 5)
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
Track 12
Filename : /Users/davesprou/Desktop/XLD Rips/12 Frank Zappa & The Mothers Of Invention - Zanti Serenade.m4a
CRC32 hash : 75DE6F51
CRC32 hash (skip zero) : 6040EA49
AccurateRip signature : EE847E29
->Accurately ripped! (confidence 5)
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
Track 13
Filename : /Users/davesprou/Desktop/XLD Rips/13 Frank Zappa & The Mothers Of Invention - Divan.m4a
CRC32 hash : 56FD5781
CRC32 hash (skip zero) : CF5DF872
AccurateRip signature : EFEB5DE8
->Accurately ripped! (confidence 5)
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
Track 14
Filename : /Users/davesprou/Desktop/XLD Rips/14 Frank Zappa & The Mothers Of Invention - Sleeping In A Jar.m4a
CRC32 hash : ADD4ED05
CRC32 hash (skip zero) : A3A7A1AC
AccurateRip signature : 14E262BC
->Accurately ripped! (confidence 5)
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
Track 15
Filename : /Users/davesprou/Desktop/XLD Rips/15 Frank Zappa & The Mothers Of Invention - Don't Eat There.m4a
CRC32 hash : FF7D8E81
CRC32 hash (skip zero) : F74AB475
AccurateRip signature : 356E77D0
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 8
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 16
Filename : /Users/davesprou/Desktop/XLD Rips/16 Frank Zappa & The Mothers Of Invention - Brixton Still Life.m4a
CRC32 hash : 657D1202
CRC32 hash (skip zero) : 09856824
AccurateRip signature : C72CBE12
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 70
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 2
List of suspicious positions :
(1) 00:57:37
(2) 01:37:46
Track 17
Filename : /Users/davesprou/Desktop/XLD Rips/17 Frank Zappa & The Mothers Of Invention - Super Grease.m4a
CRC32 hash : 9E3AB0B2
CRC32 hash (skip zero) : 9982326F
AccurateRip signature : F150AB3E
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 8
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 18
Filename : /Users/davesprou/Desktop/XLD Rips/18 Frank Zappa & The Mothers Of Invention - Wonderful Wino.m4a
CRC32 hash : 8D252ECF
CRC32 hash (skip zero) : 123A2CBA
AccurateRip signature : 5D5E8A14
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 66
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 2
List of suspicious positions :
(1) 00:33:58
(2) 00:33:72
Track 19
Filename : /Users/davesprou/Desktop/XLD Rips/19 Frank Zappa & The Mothers Of Invention - Sharleena.m4a
CRC32 hash : 6178899C
CRC32 hash (skip zero) : 0F746850
AccurateRip signature : 8981725D
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 43
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 0
Track 20
Filename : /Users/davesprou/Desktop/XLD Rips/20 Frank Zappa & The Mothers Of Invention - Crusin' for Burgers.m4a
CRC32 hash : 59910784
CRC32 hash (skip zero) : 764EBC66
AccurateRip signature : 1A460BB2
->Accurately ripped! (confidence 5)
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
Track 21
Filename : /Users/davesprou/Desktop/XLD Rips/21 Frank Zappa & The Mothers Of Invention - Diptheria Blues.m4a
CRC32 hash : 01FECD71
CRC32 hash (skip zero) : 86798940
AccurateRip signature : 1A87BE4A
->Accurately ripped! (confidence 5)
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
Track 22
Filename : /Users/davesprou/Desktop/XLD Rips/22 Frank Zappa & The Mothers Of Invention - Well.m4a
CRC32 hash : E1ECF841
CRC32 hash (skip zero) : 56D53EDF
AccurateRip signature : C84007DD
->Accurately ripped! (confidence 5)
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
Track 23
Filename : /Users/davesprou/Desktop/XLD Rips/23 Frank Zappa & The Mothers Of Invention - Say Please.m4a
CRC32 hash : 6B0A9115
CRC32 hash (skip zero) : 93BDDDB3
AccurateRip signature : C732B1F4
->Accurately ripped! (confidence 5)
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
Track 24
Filename : /Users/davesprou/Desktop/XLD Rips/24 Frank Zappa & The Mothers Of Invention - Aaawk.m4a
CRC32 hash : 26338445
CRC32 hash (skip zero) : E2A2B367
AccurateRip signature : 6F92155D
->Accurately ripped! (confidence 5)
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
Track 25
Filename : /Users/davesprou/Desktop/XLD Rips/25 Frank Zappa & The Mothers Of Invention - Scumbag.m4a
CRC32 hash : 2F800CBD
CRC32 hash (skip zero) : 0B6F1802
AccurateRip signature : 43995F98
->Accurately ripped! (confidence 5)
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
Track 26
Filename : /Users/davesprou/Desktop/XLD Rips/26 Frank Zappa & The Mothers Of Invention - A Small Eternity With Yoko Ono.m4a
CRC32 hash : 6C854669
CRC32 hash (skip zero) : 83C1C60E
AccurateRip signature : 0686B31D
->Rip may not be accurate.
Statistics
Read error : 0
Skipped (treated as error) : 0
Edge jitter error (maybe fixed) : 0
Atom jitter error (maybe fixed) : 54
Dropped bytes error (maybe fixed) : 0
Duplicated bytes error (maybe fixed) : 0
Inconsistency in error sectors : 2
List of suspicious positions :
(1) 06:03:07
(2) 06:03:27
Some inconsistencies found
End of status report
..... can't seem to get the code box thing ....
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Instead of "code" and "/code", use "codebox" and "/codebox".[/size]
This post is not correct. 8 and 0 look pretty indistinguishable in font XLD uses in it's log.
I mistook the two tracks that reported 8 errors for 0 errors.
The log matches AR results
Here's a damaged disk I just ripped where the log report shows no problems on some tracks the AR does not show as a match
For the sake of experiment could you rip the disc again with cache disabled (allegedly)
Here's a damaged disk I just ripped where the log report shows no problems
It looks like there are problems in the log to me...
Track 15
Atom jitter error ([b]maybe[/b] fixed) : 8
Track 16
Atom jitter error ([b]maybe[/b] fixed) : 70
Inconsistency in error sectors : 2
List of suspicious positions :
(1) 00:57:37
(2) 01:37:46
Track 17
Atom jitter error ([b]maybe[/b] fixed) : 8
Track 18
Atom jitter error ([b]maybe[/b] fixed) : 66
Inconsistency in error sectors : 2
List of suspicious positions :
(1) 00:33:58
(2) 00:33:72
Track 19
Atom jitter error ([b]maybe[/b] fixed) : 43
Track 26
Atom jitter error ([b]maybe[/b] fixed) : 54
Inconsistency in error sectors : 2
List of suspicious positions :
(1) 06:03:07
(2) 06:03:27
[b]Some inconsistencies found[/b]
For the sake of experiment could you rip the disc again with cache disabled (allegedly)
...especially since the PX-230A is a caching drive.
Time for new glasses...
The 8's were hiding in the crossed 0's (who on earth invented those things?) in the XLD log.
I'm doing come cahe on and off comparisons now.
Here's a damaged disk I just ripped where the log report shows no problems on some tracks the AR does not show as a match:
You didn't use "test before copy" on this rip.
You didn't use "test before copy" on this rip.
Surely forgiveable/understandable if you have "Only when the track does not exist in AccurateRip DB" checked ?
You didn't use "test before copy" on this rip.
Surely forgiveable/understandable if you have "Only when the track does not exist in AccurateRip DB" checked ?
Yep. One sweet feature that is.
XLD updated via automatic update today with some interesting new features. I posted all the XLD updates since 2008/08/22 because the website has not been updated since then and after you automatically download the new version of XLD you won't have any record of these updates or added features until the website is updated.
Version 20080907:
• Added feature to fix a wrong offset of the existing files using AccurateRip database
• You can detect and fix an offset from "Detect Offset" and "Save with Offset Correction..." in File menu, after opening a file (with cuesheet) that you want to fix.
• Separated drift errors from skip errors in cdparanoia statistics
• Added option to treat AccurateRip mismatch as an inconsistency in log
• Modified loading method of Sparkle.framework to support OSX 10.3
Version 20080906:
• Sorted character encoding pop-up menu by alphabetical order
Version 20080905:
• XLD now shows "[AR]" string in the titlebar of the window when a disc is available in AccurateRip DB
Version 20080904:
• Added option to avoid testing when the track exists in AccurrateRip DB
• Supported creating a cue sheet for separated track files
• You can choose type in the save dialog. Note that currently XLD can't read this type of cue sheet.
Version 20080902:
• Fixed a problem in ALAC decoder
Version 20080830:
• Added option to test before copy
Version 20080829:
• Added option to veryfy suspicious sectors
Version 20080828:
• Added option to save a log file automatically
• Improved progress view to show a speed and remaining time
Version 20080827:
• XLD now automatically recognizes inserted/ejected CD
• Supported embedding album art in WavPack encoder
• Fixed to ask output directory if the default directory is not writable
Version 20080826:
• Fixed to report correctly in case AccurateRip doesn't have informations for all tracks
Version 20080825:
• Fixed several bugs in cdparanoia routine according to the latest release
• Fixed UTF-8 NFD issue when looking up Gracenote database
• Fixed MusicBrainz query failure on PPC Mac
Version 20080824:
• Fixed a problem that XLD sometimes failed to find a CD in AccurateRip database
Version 20080823:
• Added feature to calculate an AccurateRip hash for the existing files
• Choose "Check file with AccurateRip" from the File menu.
• Fixed again an AccurateRip hash calculation for the first track
• Sorry for confusion... I hope this will be the solution...
Version 20080822a:
• Fixed an AccurateRip hash calculation for the first track with pregap
Version 20080822:
• Fixed an AccurateRip hash calculation for the first and last track
• Improved tag editor
• Supported automatic update using Sparklelong
Yep. One sweet feature that is.
I think the developer deserves a great deal of credit for the nearly daily updates, all of which are to add genuinely useful features.
Edit: Took the words right out of my mouth mm4h
You didn't use "test before copy" on this rip.
Surely forgiveable/understandable if you have "Only when the track does not exist in AccurateRip DB" checked ?
Yes and no. Yes, if AR reports that everything checks out OK.
No, if you have problems like you do in your log and want to confirm that they are truly error free.
Try ripping the tracks in question again with "test before copy" and "verify suspicious sectors" enabled. I predict that the log will show a mismatch between the test and copy CRCs on the problem tracks.
This is not a caching issue, I am certain.
No sh*t. I have never seen such user driven (or anything otherwise!) development. Amazing. And to do it smartly (do test/copy if track not in AR) and functionally/individual preference (have as option for how log is worded re: AR inconsistencies) is damn near elegant.
Now for some clarification re: drive cache defeating (for whatever it's relevancy on modern drives) and handling of fancy discs (Super/enhanced/whatever).
Try ripping the tracks in question again with "test before copy" enabled. I predict that the log will show a mismatch between the test and copy CRCs on the problem tracks.
This is not a caching issue, I am certain.
And then there's that.
Yep. One sweet feature that is.
I think the developer deserves a great deal of credit for the nearly daily updates, all of which are to add genuinely useful features.
Edit: Took the words right out of my mouth mm4h
The pace this application is being developed is truly amazing. Great Work!
Did we determine if the "Only when the track does not exist in AccurateRip DB" setting takes into account the very real possibility of having a different pressing from what's in the database???
Did we determine if the "Only when the track does not exist in AccurateRip DB" setting takes into account the very real possibility of having a different pressing from what's in the database???
It doesn't take that into account. That is one of the problems with this option.
If you want to rely on the AR results first and foremost, then it's probably better to burst rip, then check the AR results.
Is it realistically possible for different pressings to have some tracks that match ? If it's not then it should be obvious what the situation is unless you have a disc with 100% of the tracks damaged.
Now for some clarification re: drive cache defeating (for whatever it's relevancy on modern drives) and handling of fancy discs (Super/enhanced/whatever).
The handling of "fancy discs" (enhanced CDs with videos, photos or any other extras included) is definitely a problem with XLD. It can't deal with them at all. XLD hangs during the "detecting pregap" stage."
Both xACT and cdparanoia III 9.8 are able to deal with enhanced discs, so I'm sure that XLD can be made to work with these as well.
As for caching, well, I'm still waiting for someone to prove a caching problem with cdparanoia/XLD. I'm not saying that it can't happen, just that no one has shown it to be a demonstrable problem -- and I've been comparing EAC and cdparanoia III 9.8 rips for more than half a decade, using both caching and non-caching drives.
Is it realistically possible for different pressings to have some tracks that match ? If it's not then it should be obvious what the situation is unless you have a disc with 100% of the tracks damaged.
It is possible. I have seen it. I have several discs of which I own a couple of different pressings. On at least two titles, a few of the tracks in common have identical CRCs, while the other tracks produce entirely different CRCs. I'm not sure how common this phenomenon is, but it can and does occur.
You didn't use "test before copy" on this rip.
Surely forgiveable/understandable if you have "Only when the track does not exist in AccurateRip DB" checked ?
Yes and no. Yes, if AR reports that everything checks out OK.
No, if you have problems like you do in your log and want to confirm that they are truly error free.
Try ripping the tracks in question again with "test before copy" and "verify suspicious sectors" enabled. I predict that the log will show a mismatch between the test and copy CRCs on the problem tracks.
This is not a caching issue, I am certain.
Just to be clear - My post above on the log not showing errors while AR showed a mismatch was my error in mistaking the 8's for 0's in XLD's log.
The log and AR's results match in this instance ---- My mistake.
Yep. One sweet feature that is.
I think the developer deserves a great deal of credit for the nearly daily updates, all of which are to add genuinely useful features.
Edit: Took the words right out of my mouth mm4h
The pace this application is being developed is truly amazing. Great Work!
Indeed! The XLD developer has done an amazing job. He not only took Mac ripping out of the dark ages, but the *daily* improvements he has been making to XLD are truly a wonder to behold. I really cannot thank him enough for everything he has done (and continues to do).
I have created a comparison for three CD rippers that use CDParanoia on the Mac. This comparison is in no way a definitive comparison as the feature sets of these applications constantly change. Please contact me if any information appears inaccurate or you feel a crucial feature has been omitted. I attempted to list the features in an unbiased manner. All these applications offer several audio codecs which are listed in HA's 2008 ripping/encoding polls which confirms the most the popular ones are offered. I intentionally did not list the audio codecs because the focus for this comparison is the DAE capabilities on the Mac.
I notice an incorrect entry on your ripper comparison chart: xACT does NOT have a "verify suspicious sectors" option, nor does it verify them.
Also, xACT does query Freedb (you can see it on the log), although it will not actually title the tracks on output. One problem with xACT is that the developer made it a "run only" application, so you cannot edit the app. I believe this may be a violation of the cdparanoia GPL, but what do I know?
I notice an incorrect entry on your ripper comparison chart: xACT does NOT have a "verify suspicious sectors" option, nor does it verify them.
Also, xACT does query Freedb (you can see it on the log), although it will not actually title the tracks on output. One problem with xACT is that the developer made it a "run only" application, so you cannot edit the app. I believe this may be a violation of the cdparanoia GPL, but what do I know?
cdda2wav: There is no sound support configured!
Type: ROM, Vendor 'SONY ' Model 'DVD RW DW-D150A ' Revision '1.MD' MMC+CDDA
176128 bytes buffer memory requested, transfer size 32768 bytes, 4 buffers, 13 sectors
#Cdda2wav version 2.01.01a28_darwin_8.10.1_i386_i386, libparanoia support
AUDIOtrack pre-emphasis copy-permitted tracktype channels
1-13 no no audio 2
Table of Contents: total tracks:13, (total time 66:23.13)
1.( 5:22.50), 2.( 5:48.73), 3.( 5:04.00), 4.( 7:40.50), 5.( 2:35.60),
6.( 8:20.62), 7.( 7:53.05), 8.( 2:32.05), 9.( 5:42.05), 10.( 1:59.70),
11.( 6:45.18), 12.( 1:18.17), 13.( 5:19.48)
Table of Contents: starting sectors
1.( 32), 2.( 24232), 3.( 50405), 4.( 73205), 5.( 107755),
6.( 119440), 7.( 157002), 8.( 192482), 9.( 203887), 10.( 229542),
11.( 238537), 12.( 268930), 13.( 274797), lead-out( 298770)
CDINDEX discid: R2nrzEhgxe9Io70AQkUL_6wpHNs-
CDDB discid: 0xcc0f8f0d CDDBP titles: resolved
CD-Text: not detected
CD-Extra: not detected
Album title: 'Kiss My Axe' [from Al Di Meola]
Track 1: 'South Bound Traveler'
Track 2: 'The Embrace'
Track 3: 'Kiss My Axe'
Track 4: 'Morocco'
Track 5: 'Gigi's Playtime Rhyme (Interlude #1)'
Track 6: 'One Night Last June'
Track 7: 'Phantom'
Track 8: 'Erotic Interlude (Interlude #2)'
Track 9: 'Global Safari'
Track 10: 'Interlude #3'
Track 11: 'Purple Orchids'
Track 12: 'The Prophet (Interlude #4)'
Track 13: 'Oriana (September 24, 1988)'
samplefile size will be 13799228 bytes.
recording 78.2266 seconds stereo with 16 bits @ 44100.0 Hz ->'audio'...
using lib paranoia for reading.
percent_done:
0%
0%
1%
2%
3%
4%
5%
6%
7%
8%
9%
10%
11%
12%
13%
14%
15%
16%
17%
18%
19%
20%
21%
22%
23%
24%
25%
26%
27%
28%
29%
30%
31%
32%
33%
34%
35%
36%
37%
38%
39%
40%
41%
42%
43%
44%
45%
46%
47%
48%
49%
50%
51%
52%
53%
54%
55%
56%
57%
58%
59%
60%
61%
62%
63%
64%
65%
66%
67%
68%
69%
70%
71%
72%
73%
74%
75%
76%
77%
78%
79%
80%
81%
82%
83%
84%
85%
86%
87%
88%
89%
90%
91%
92%
93%
94%
95%
96%
97%
98%
99%
100% track 12 'The Prophet (Interlude #4)' recorded with minor problems (1.2% problem sectors)
100% 0 rderr, 0 skip, 72 atom, 0 edge, 0 drop, 0 dup, 0 drift
100% 81 overlap(0.5 .. 0.5)
Pepzhez I will change Mac CD Ripper Comparison Chart to reflect the fact xACT does query Freedb placing the info in the log only after the rip is completed and currently does does write tags to outputted files. I will clarify that xACT does not verify suspicious sector but does report problem sector % in the log, I did not make this clear getting lazy! Thanks for the correction.
I have created a comparison for three CD rippers that use CDParanoia on the Mac. This comparison is in know way a definitive comparison as the feature sets of these applications constantly change. Please contact me if any information appears inaccurate or you feel a crucial feature has been omitted.
From the other thread on this subject, I think it's not yet entirely clear that XLD actually disables the drives cache.
Click here (http://www.hydrogenaudio.org/forums/index.php?showtopic=65873&hl=) to learn more about the status of XLD and CDParanoia capability to disable the drives cache from this thread posted September 12,2008.
I'm new to XLD - just downloaded and started learning about it today.
I noticed that there has been some discussion/debate about the new version of CDParanoia and also of drive cache disabling. There are a few posts on this very thread that show before/after rip logs that have different results.
My question: if an XLD rip matches the AccurateRip database, and all the log results are "0" (with an accurate rip confidence factor of 200) is that not an accurate rip? I see how turning cache on/off might affect the results, but wouldn't that result in a questionable rip log?
For the record (and for any further advice) here are my settings:
Version: 20080913 (89.0)
Drive offset: 48 (Pioneer DVD-RW DRV-106D)
Disable cache: OFF
Test before copy: only when track does not exist in AccurateRip DB
Any help is appreciated.
My question: if an XLD rip matches the AccurateRip database, and all the log results are "0" (with an accurate rip confidence factor of 200) is that not an accurate rip? I see how turning cache on/off might affect the results, but wouldn't that result in a questionable rip log?
If a confidence level of 200 isn't an accurate rip, I don't know what is.
Would turning cache on or off result in a questionable log? Experience tells me "not necessarily." You can try ripping it both ways and comparing logs for differences (if there are any).
I just ripped the same track twice - once with the "Disable cache" checked, and one with it unchecked.
I compared the result logs side-by-side, and they are identical (both are confidence 200 rips with "0" in all the line-item fields). Would that be indicative of what I can expect across the board in regards to cache performance/effectiveness?
And, having said that - which setting (disable or not) do most people use?
I just ripped the same track twice - once with the "Disable cache" checked, and one with it unchecked.
I compared the result logs side-by-side, and they are identical (both are confidence 200 rips with "0" in all the line-item fields). Would that be indicative of what I can expect across the board in regards to cache performance/effectiveness?
And, having said that - which setting (disable or not) do most people use?
Was that track a previously "troublesome" track? Doesn't sound like it.
I just ripped the same track twice - once with the "Disable cache" checked, and one with it unchecked.
I compared the result logs side-by-side, and they are identical (both are confidence 200 rips with "0" in all the line-item fields). Would that be indicative of what I can expect across the board in regards to cache performance/effectiveness?
And, having said that - which setting (disable or not) do most people use?
Was that track a previously "troublesome" track? Doesn't sound like it.
You're right, but I don't have many troublesome CDs or tracks. I've never used Accurate Rip or a log until today. Right now I'm doing a little research to get the right settings before I start ripping en masse.
You're right, but I don't have many troublesome CDs or tracks. I've never used Accurate Rip or a log until today. Right now I'm doing a little research to get the right settings before I start ripping en masse.
Yeah, I had to go get some from the library. I did have some with rot but the rest are well kept. Keep us informed.
I have created a comparison for three CD rippers that use CDParanoia on the Mac.
I'd like contribute to this summary with a little research on very important subject, completely omitted in any XLD-related topic. It is a question of
Pre-Emphasis.
I've found the only solution how to correctly detect
PRE flag, and it is provided by
xAct, only as a result log that is not even saved with rip.
Log looks like this (check the last two lines):
cdda2wav: There is no sound support configured!
Type: ROM, Vendor 'TSSTcorp' Model 'CDDVDW SH-S202N ' Revision 'SB01' MMC+CDDA
176128 bytes buffer memory requested, transfer size 32768 bytes, 4 buffers, 13 sectors
cdda2wav: Read TOC CD Text failed (probably not supported).
#Cdda2wav version 2.01.01a28_darwin_8.10.1_i386_i386, libparanoia support
cdda2wav: Host is down. Cddb connect failed.
AUDIOtrack pre-emphasis copy-permitted tracktype channels
1-10 yes no audio 2
How to handle such CD is another question, probably best solution is to burn on CD-R using reliable sw with PRE flag set ON. Toast supports this, but does not read this setting from CUE. It has to be set manually.
For those who want to play files from computer, there are some options: iTunes 7 during ripping performs frequency equalization similar to the one provided by stand-alone CD player, when encounters a PRE flag. The resulting Wav file is of course not a bit-perfect copy of a CD track. Any other ripping sw ignores this. Only some rippers can write correct PRE flag on the CUE sheet [like EAC], bot none on Mac OS-X. Playback with equalization on-the-fly is only possible in Foobar2000 / Win.
So for this reason, line containing Pre-Emphasis should be added to the table, with important benefit of xAct allowing to detect it, at least, and there's also a recommendation to XLD developer to consider implementing of proper PRE flag reading and logging.