Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: XLD - ripper now disables cache and supports AccurateRip (Read 42253 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

XLD - ripper now disables cache and supports AccurateRip

XLD which has long been my converter of choice recently added the ability to rip with CDParanoia. Been there, seen that on the long, long journey to secure ripping on a Mac.

Well, its ripper has matured very quickly:

"What's new in this version:

    * Supported AccurateRip database to check integrity of the ripped tracks To use, read offset correction value should be correct (please refer to here). Not available when pregaps are excluded.
    * Added option to disable cache of the drive Cache should be disabled to rip in cdparanoia mode.
    * Added support for CRC calculation Both the standard CRC and the EAC-compatible one are displayed.
    * Improved log display format"

If it really can do what it says on the tin, well it's pretty big news.

XLD - ripper now disables cache and supports AccurateRip

Reply #1
Supported AccurateRip database to check integrity of the ripped tracks


Is this the first ripper on a mac to support AccurateRip? If so well done to the developers!

Keep up the good work!

XLD - ripper now disables cache and supports AccurateRip

Reply #2

Supported AccurateRip database to check integrity of the ripped tracks


Is this the first ripper on a mac to support AccurateRip? If so well done to the developers!

Keep up the good work!

First to have offset correction, first to support AccurateRip and, most importantly, first to disable cache (assuming that it does and I have no reason to doubt it so far).

XLD - ripper now disables cache and supports AccurateRip

Reply #3
I've tried it out. All is well, very nice log and all, but I do wonder if the cache has truly been disabled, and, if so, how exactly? As far as I know, there is no Force Unit Access command for CDDA under OS X, so I wonder what the XLD approach is. I guess it's time to start perusing the source code.

(Offset correction has been available on the command line version of cdparanoia for ages, though.)

XLD - ripper now disables cache and supports AccurateRip

Reply #4
It's really great news for Mac users, however there's one problem:
Quote
* Added option to disable cache of the drive Cache should be disabled to rip in cdparanoia mode.

in order to rip the CD in most accurate way, it should be done in cdparanoia mode AND with disabled cache. Meaning, this option should be enabled, like in EAC with secure ripping. If cache can't be disabled then cdparanoia is of no use with drive that caches audio...
Or have i understood the statement wrongly?

XLD - ripper now disables cache and supports AccurateRip

Reply #5
I've looked at the source, and the way the cache is disabled is:

Code: [Select]
fcntl(fd,F_NOCACHE,disable);


I'm not positive, but I don't believe that will affect the drive's cache.

XLD - ripper now disables cache and supports AccurateRip

Reply #6
I've looked at the source, and the way the cache is disabled is:

Code: [Select]
fcntl(fd,F_NOCACHE,disable);


I'm not positive, but I don't believe that will affect the drive's cache.


The fcntl(F_NOCACHE) command descriptor addresses caching on the kernel level, correct? The XLD developer seems to have fundamentally misunderstood the caching issue at hand. In other words, XLD's "disable cache" command, well, doesn't.

I played around some more with the new version of XLD. It produces identical (verified via checksum) results as cdparanoia III 9.8. Nothing new here except fot the Accurate Rip support.

I will say again that the log is rather nice.

Mr. sbooth, can we get a log like this in Max, please?

XLD - ripper now disables cache and supports AccurateRip

Reply #7
I just ran a test run on a previously ripped with cdparanoia and checked with an arcue.pl spin off.

Everything came out as accurate except for the first and last tracks.  I then checked the output again with arcue and all tracks came up accurate, including the first and last.  So I suspect an issue with the first and last few samples that are supposed to be thrown away by Accurate Rip.

Other than that, very nice.  Certainly easier than the cdparanoia / cdrdao / arcue script I've been using.

XLD - ripper now disables cache and supports AccurateRip

Reply #8
Problems in choosing the right address to multiply against the sample and/or forgetting to omit the first 5 frames of the first track and the last 5 frames of the last track?

Combined with doubts concerning the ability to flush cache, it looks like the air is deflating pretty quickly.

XLD - ripper now disables cache and supports AccurateRip

Reply #9
Is the offset the same value that dbpoweramp cd ripper calculates when that program is used to rip music?

XLD - ripper now disables cache and supports AccurateRip

Reply #10
I just ran a test run on a previously ripped with cdparanoia and checked with an arcue.pl spin off.

Everything came out as accurate except for the first and last tracks.  I then checked the output again with arcue and all tracks came up accurate, including the first and last.  So I suspect an issue with the first and last few samples that are supposed to be thrown away by Accurate Rip.

Other than that, very nice.  Certainly easier than the cdparanoia / cdrdao / arcue script I've been using.


Problems in choosing the right address to multiply against the sample and/or forgetting to omit the first 5 frames of the first track and the last 5 frames of the last track?

Combined with doubts concerning the ability to flush cache, it looks like the air is deflating pretty quickly.

I have not had that problem with XLD's AccurateRip reporting. Using a Pioneer DVD-RW DVR-108 (offset +48), I have been getting accurate rips on all tracks.

Below is the log output of the disc I just finished ripping. Note the confidence levels. The cache issue may still be up in the air, but after ripping over 20 discs so far with XLD, I'm more than reasonably satisfied that it plays nice with AccurateRip.

Code: [Select]
XLD extraction logfile from 2008-08-20 23:11:36 -0500

Can / Tago Mago

Used drive : PIONEER DVD-RW  DVR-108 (revision 1.17)

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

TOC of the extracted CD
    Track |  Start  |  Length  | Start sector | End sector
    ---------------------------------------------------------
        1  | 00:00:32 | 07:28:00 |        32    |    33631 
        2  | 07:28:32 | 04:03:03 |    33632    |    51859 
        3  | 11:31:35 | 07:24:37 |    51860    |    85196 
        4  | 18:55:72 | 18:28:10 |    85197    |  168306 
        5  | 37:24:07 | 17:33:38 |    168307    |  247319 
        6  | 54:57:45 | 11:38:02 |    247320    |  299671 
        7  | 66:35:47 | 06:45:73 |    299672    |  330119 

Track 01
    Filename : /Users/x/Desktop/Can Tago Mago/01 Can - Paperhouse.wav

    CRC32 hash            : 1ADEFF0C
    CRC32 hash (EAC style) : E7E7924C
    AccurateRip signature  : B222CBBD
        ->Accurately ripped! (confidence 10)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

Track 02
    Filename : /Users/x/Desktop/Can Tago Mago/02 Can - Mushroom.wav

    CRC32 hash            : CBE7CD2E
    CRC32 hash (EAC style) : 5E237342
    AccurateRip signature  : C02D63BD
        ->Accurately ripped! (confidence 10)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

Track 03
    Filename : /Users/x/Desktop/Can Tago Mago/03 Can - Oh Yeah.wav

    CRC32 hash            : DAE43DCF
    CRC32 hash (EAC style) : 06EE8AED
    AccurateRip signature  : 128C51DC
        ->Accurately ripped! (confidence 11)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

Track 04
    Filename : /Users/x/Desktop/Can Tago Mago/04 Can - Halleluhwah.wav

    CRC32 hash            : 3225FEBC
    CRC32 hash (EAC style) : 0659F2FE
    AccurateRip signature  : 3FC649A4
        ->Accurately ripped! (confidence 10)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

Track 05
    Filename : /Users/x/Desktop/Can Tago Mago/05 Can - Aumgn.wav

    CRC32 hash            : 42BA58B7
    CRC32 hash (EAC style) : A0588DE6
    AccurateRip signature  : FF895D23
        ->Accurately ripped! (confidence 10)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

Track 06
    Filename : /Users/x/Desktop/Can Tago Mago/06 Can - Peking O.wav

    CRC32 hash            : E1D5B39F
    CRC32 hash (EAC style) : 939B1844
    AccurateRip signature  : FB6B0DD1
        ->Accurately ripped! (confidence 8)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

Track 07
    Filename : /Users/x/Desktop/Can Tago Mago/07 Can - Bring Me Coffee Or Tea.wav

    CRC32 hash            : 74CF3981
    CRC32 hash (EAC style) : 19DC8942
    AccurateRip signature  : BF75ABF6
        ->Accurately ripped! (confidence 9)
    Statistics
        Read error                    : 0
        Skipped (treated as error)    : 0
        Edge jitter error (fixed)      : 0
        Atom jitter error (fixed)      : 0
        Dropped bytes error (fixed)    : 0
        Duplicated bytes error (fixed) : 0

No errors occurred

End of status report

This is typical of the results I've been getting since installing XLD last night. Works for me.  XLD is now my ripper of choice. Cache flushing or not, it is thus far the only Mac ripper that utilizes AccurateRip, and that puts it ahead of anything else that's currently available. And did I mention the log? The best log implementation I've ever seen on a Mac ripper.

Thanks to ffooky for bringing this to my attention.

[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Please use a codebox.[/size]

XLD - ripper now disables cache and supports AccurateRip

Reply #11
Makes me wonder if you just happen to have null samples for the first 5 frames and the last five frames.  Whether it is working correctly or not can be tested pretty easily.  Hopefully this was done before the program was released.  Can you verify that any of those 20 discs with edge tracks that were verified have non-null data in the areas I've identified?

Is the offset the same value that dbpoweramp cd ripper calculates when that program is used to rip music?
Yes, otherwise AccurateRip would not work.

XLD - ripper now disables cache and supports AccurateRip

Reply #12
Makes me wonder if you just happen to have null samples for the first 5 frames and the last five frames.  Whether it is working correctly or not can be tested pretty easily.  Hopefully this was done before the program was released.  Can verify that any of those 20 discs with edge tracks that were verified have non-null data in the area I've identified?


I'd be happy to verify that if I knew how to. What's the easiest way to tell whether or not the the first and last 5 frames contain null samples? Forgive my ignorance, but why are the first and last 5 frames of a disc potentially problematic for AccurateRip? If XLD were to report an error-free rip on one of these first or last tracks, but Accuraterip disagrees, does that mean that the rip is in fact incorrect, or is it just padded with silence or ... ?

I'm just trying to understand what this is all about. Thanks.

Thanks for the codebox, greynol, I didn't know about that!

XLD - ripper now disables cache and supports AccurateRip

Reply #13
I just brought up the disc I had ripped in Audacity and can see that there is indeed audio in the first and last 5 frames.  Also based on how the rest of the tracks are listed as accurate within XLD I suspect this isn't an addressing issue but that the app isn't zeroing those first and last frames when calculating the hash.

Pepznez, I think I remember that the first and last 5 frames are discarded so that the ability of a drive to over-read does not influence the hash.  Those first and last frames are probably silence anyway and it's less than a quarter of a second (1/15th), so unless there's a serious error in the rip it won't be noticeable.  Less than ideal perhaps for the pursuit of the "perfect rip", but good enough.

XLD - ripper now disables cache and supports AccurateRip

Reply #14
I just brought up the disc I had ripped in Audacity and can see that there is indeed audio in the first and last 5 frames.  Also based on how the rest of the tracks are listed as accurate within XLD I suspect this isn't an addressing issue but that the app isn't zeroing those first and last frames when calculating the hash.

Pepznez, I think I remember that the first and last 5 frames are discarded so that the ability of a drive to over-read does not influence the hash.  Those first and last frames are probably silence anyway and it's less than a quarter of a second (1/15th), so unless there's a serious error in the rip it won't be noticeable.  Less than ideal perhaps for the pursuit of the "perfect rip", but good enough.


I see. So it sounds like it's a bug that the XLD developer could easily fix ("properly discard first and last 5 frames of the disc rip"). Has anyone here pointed out this thread to the XLD developer? I've never been in contact with him/her.

Still, why am I not having this problem, then? If XLD is not discarding the first and last frames as it is supposed to be doing, why am I getting AccurateRip verification on the first and last tracks and no one else is? Shouldn't I be getting the same errors? Now I'll have to keep ripping discs until I find one that gives me this frame problem. This is starting to bug me now!

XLD - ripper now disables cache and supports AccurateRip

Reply #15
I see. So it sounds like it's a bug that the XLD developer could easily fix ("properly discard first and last 5 frames of the disc rip"). Has anyone here pointed out this thread to the XLD developer? I've never been in contact with him/her.


Yep, I mailed him/her as soon as the cache thing was raised and linked to this thread. The developer was very quick at sorting out a problem I raised with XLD-encoded AAC files not playing when in shared iTunes libraries so I'm pretty hopeful.

XLD - ripper now disables cache and supports AccurateRip

Reply #16
Still, why am I not having this problem, then? If XLD is not discarding the first and last frames as it is supposed to be doing, why am I getting AccurateRip verification on the first and last tracks and no one else is? Shouldn't I be getting the same errors?


As greynol suggested, the discs that you've not been having verification problems with probably have silence in those first and last 5 frames.  The hash calculation for silence would be zero which is what Accurate Rip calculates for the those frames anyway.  Non-silent audio in those frames is an edge case that the developer didn't catch.

I sent a message to the developer as well with a link to the thread.  I also requested the ability to load a lossless image or multiple tracks and evaluate the AR hash.

XLD - ripper now disables cache and supports AccurateRip

Reply #17
If XLD were to report an error-free rip on one of these first or last tracks, but Accuraterip disagrees, does that mean that the rip is in fact incorrect, or is it just padded with silence or ... ?
You can certainly have an accurate track that AR cannot verify.  If more than one person with the exact same pressing are getting consistent rips that don't match yours and we aren't talking about copy controlled or otherwise consistently defective discs, then I'd question the rip that can't be verified.  This is when AR can verify some of the tracks and the tracks that can't be verified return similar confidences (otherwise they are probably coming from a different pressing).  If the tracks that can be verified have a low confidence or none of the tracks can be verified, then I'd look to see if the ripper had to do any extra work to extract them before questioning their accuracy.  I hope this makes sense.

Still, why am I not having this problem, then?
I don't know and I am not 100% certain about what's going on, either, BTW.  Fracai aptly pointed out that if there was a problem with the addresses used, it would be consistent across all tracks.

If XLD is not discarding the first and last frames as it is supposed to be doing, why am I getting AccurateRip verification on the first and last tracks and no one else is? Shouldn't I be getting the same errors?
I'm only reading the testimonials of two people, so I can't conclude all that much.  All I can do is think of a reason why it would work for someone and not for someone else.  20 discs where the first track begins with 5 frames of silence and the last track ends with 5 frames of silence and zero discs that have non-silent data in those areas does seem like a stretch on my theory, though.

XLD - ripper now disables cache and supports AccurateRip

Reply #18
Either way, it's been updated:
Quote
* Fixed an AccurateRip hash calculation for the first and last track
    * Improved tag editor
    * Supported automatic update using Sparkle


Sparkle!

XLD - ripper now disables cache and supports AccurateRip

Reply #19
I was just about to post here to say that I did find some discs that gave me the first and last track AccurateRip hash error, but then saw that XLD had already been updated.

So I ran them again with the updated version. The good news is that the hash error for the last track has been fixed, but the hash error for the first track is still there. 

I'm sure the problem will be fixed very soon!

XLD - ripper now disables cache and supports AccurateRip

Reply #20
Can someone else confirm that bug with first 5 frames still persist?
Thanks.

XLD - ripper now disables cache and supports AccurateRip

Reply #21
I just opened XLD and Sparkle (Yay Sparkle) downloaded a new version (20080822a) with the comment that it fixes a first track hash issue.

Testing the same disc that gave me problems before gave an accurate match on all tracks.

XLD - ripper now disables cache and supports AccurateRip

Reply #22
I just downloaded the 20080822a update, and the problem on track one still persists, unfortunately.

XLD - ripper now disables cache and supports AccurateRip

Reply #23
For whatever it may be worth ...

On a private board I frequent one user received an email from a Monty, purported to be the paranoia guy, in response to questioning about defeating/circumventing drive audio caching, saying:

It will likely be a few more days before any test release. The
release of the new code will be sent to paranoia-announce@xiph.org, as
well as posted to the paranoia site at xiph.org.


XLD - ripper now disables cache and supports AccurateRip

Reply #24
I just downloaded the 20080822a update, and the problem on track one still persists, unfortunately.

Interesting, what discs are you getting failures on?  The one I was testing with (Flobots - Fight with Tools) came out as expected.  Are you sure you have 20080822a?  Macupdate and the XLD site still list 20080822 as the most recent.  And I haven't seen 20080822a anywhere aside from the Sparkle update.  Is that how you downloaded it as well?

I'll see if I have any other discs with early or late audio and test again myself later.  If you can reproduce the issue with certain discs it might be worthwhile contacting the developer.



tim.lance

Which board?  I've been waiting years for progress on cdparanoia.



Pepzhez, are you sure that track 1 is ripping without errors?  Just a thought.