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.

Poll

Do you belive that XLD's "Disable cache" feature works correctly?

Yes
[ 10 ] (58.8%)
No
[ 1 ] (5.9%)
Uncertain at this time
[ 6 ] (35.3%)

Total Members Voted: 43

Topic: Do you believe the drive cache problem has beeen fixed in XLD? (Read 20293 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Do you believe the drive cache problem has beeen fixed in XLD?

Do you believe that drive cache issues have been fixed with the release of XLD version 20080913 which incorporates the latest version of CD Paranoia III 10.2 ripping engine.  The following release notes are from CD Paranoia's website:

September 11, 2008

cdparanoia 10.2 final released

10.2 is a substantial upgrade release over 10.1.

10.2 includes a raft of minor bugfixes in device scan, device autosense and the transport layer.

More importantly, 10.2 addresses serious CDROM drive cache modelling deficiencies that exist in earlier versions. In a nutshell, a sizable fraction of modern drives exhibit new and exciting readahead cache abuses/bugs of which older versions of cdparanoia were not fully aware. This means that skips and cracks could slip through the cache management strategy of older versions completely undetected. 10.2 fully addresses and models these new cache behaviors.

10.2 also includes a cache analysis option (-A) to do a slow and thorough offline check of the drive's cache behavior. The feature also dumps a detailed log to assist in debugging should either the test or cdparanoia's ripping go awry in any way. After all... better thoroughly safe than sorry.

This has been a highly debated topic for sometime and I would like to find out what the members of HA think. 

After reading this thread please check the XLD Master Thread List for other important XLD threads.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #1
As far as cache is indeed an issue in these days and times? Yes. With Accurate Rip as a backup and such a sweet informative log, the days of Parallels/XP/EAC on my drive are numbered.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #2
I'm a relatively new mac user and just stumbled upon XLD tonight.

Up until now I have been using DBPA CD Ripper on a windows server.  For various reasons, I want to eliminate that and be able to do everything on my mac.

Originally I had intended to use a virtual machine but I found that it absolutely made my machine unusable...

In any case, if XLD works how I expect it to (still need to do some extended testing) I see little reason to use something else.

Not to get too far off topic, but is there a way deal with noncompliant cue sheets in XLD?  All of my existing rips are in separate flac files with EAC noncompliant cue sheets.  As I understand it XLD does not yet have support for reading these files.  Is there some automated way I convert them into the compatible single file + cue format?

Also, is there any way XLD can create directories based on the artist / album, or do I need to do some scripting for the time being?

Thanks.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #3
I'm a relatively new mac user and just stumbled upon XLD tonight.

Up until now I have been using DBPA CD Ripper on a windows server.  For various reasons, I want to eliminate that and be able to do everything on my mac.

Originally I had intended to use a virtual machine but I found that it absolutely made my machine unusable...

In any case, if XLD works how I expect it to (still need to do some extended testing) I see little reason to use something else.

Not to get too far off topic, but is there a way deal with noncompliant cue sheets in XLD?  All of my existing rips are in separate flac files with EAC noncompliant cue sheets.  As I understand it XLD does not yet have support for reading these files.  Is there some automated way I convert them into the compatible single file + cue format?

Also, is there any way XLD can create directories based on the artist / album, or do I need to do some scripting for the time being?

Thanks.

Please click this link to check the  XLD Requested Features List and read the 1st post and also click on the XLD release notes link located at the bottom the post for more information.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #4
It's like this: on one hand, we have received wisdom, and on the other hand there exists a certain degree of measurable, objective reality.

First of all, I believe that it has always been extremely difficult to prove there were cache issues with cdparanoia 9.8 and so-called caching drives. I've tried for the past 5 years or so to produce a demonstrable caching issue with cdparanoia III 9.8. I have run tests comparing the results of several drives (non-caching Plextors and NECs; caching Pioneer, Plextor and Matshita drives) -- and comparing those resulting file checksums to corresponding EAC rips. (I would do the EAC rips twice as well: the first with cache disabled; the second without cache disabled.)

Now, I have never, NOT ONCE, ever managed to find a real difference. Pristine discs, mildly damaged discs, all the way up the scale to hopelessly damaged discs. The truth of it is that they were all more or less the same. Discs with medium damage would of course produce varying results between the two applications. Neither application could rip all those tracks 100% successfully, so they did their best with them. (And needless to say that it comes as no surprise that neither EAC nor cdparanoia can salvage a hopelessly scratched or rotted disc.)

The conventional wisdom at HA has long been that "cdparanoia is useless with caching drives." Said "wisdom" -- yes, let's put that in quotes -- has been plastered over every FAQ and thread, but I learned to entirely discount that some time ago. I know people mean well here, but it didn't take me very long to see that some (not all) of the most vocal and vehement cdparanoia critics turned out to have never once used the program, never mind having methodically compared results between drives and to EAC rips.

On top of that, I've yet to encounter any conclusive proof that EAC's "flush cache" switch really does what it is supposed to do. In theory it "should" work, but how to prove that? It is taken as an article of faith that it works because it is claimed to work. And perhaps on certain drives it does indeed work as advertised, but across the board, on every drive? I'm very skeptical about that. As Monty pointed out the other day in the cdparanoia 10.2 thread, there is a wide gulf between how the cache commands are "supposed to work" and what most drives are actually doing.

Furthermore -- and this is a very important point that was completely ignored in the thread, Monty stated that almost every drive tested ignored outright ALL of the cache commands when handling redbook audio CD.

Has the EAC developer ever extensively tested or addressed this issue? I have no idea. My point here is that both EAC and cdparanoia 9.8 seem to get the job done equally well, whether you are using a caching or non-caching drive. So either the cache issue is overblown, or it is entirely misundersood/misguided -- or a bit of both.

I'm not claiming that cdparanoia 9.8 was/is immune to caching issues, but I have the feeling that you'd have to have one hell of a large audio cache on your drive in order to experience that. Perhaps one of the recent Plextors with the large buffers would demonstrate caching issues? I can't say, because I've never had access to one, and I wasn't about to buy one just to find out.

I am not saying that these issues don't exist, Rather, I am saying that in real world tests the reality of this matter is quite different from the received, secondhand notion that gets endlessly propagated.

I recall an HA thread a year or two ago that claimed to "prove" the alleged inferiority of cdparanoia over EAC and dbPoweramp by showing results of tests performed on discs with holes in them, etc. That person used CDex to rip -- and compared that failed rip to failed rips from EAC and dbPoweramp. What is the point of such a test? Granted, if you are really bored, it may be mildly amusing for you to see how long a hopelessly damaged disc hangs up a given application, but, really, it is rather like testing and comparing three sets of speakers that all have blown drivers. How useful is that test going to be, apropos anything?

(Someone trotted out again this peculiar test the other day on the cdparanoia 10.2 thread; I don't know why the beyond silly "CD-with-the-hole-in-it proves cdparanoia is subpar!" test has become a mini-tradition at HA. Try that same disc on EAC and then tell us what you think that "proves" about that particular application. Do you see what I mean?)

Never mind that CDex has a cdparanoia implementation that is either totally screwed up, or (to be polite) not exactly compliant with a proper cdparanoia build. Its error correction behaves in a different manner than that of cdparanoia III 9.8 and xACT. I noticed that CDex would let certain errors pass through undetected; errors that cdparanoia III 9.8 and xACT caught every time, as well they should. As far as I was concerned, this made CDex utterly unacceptable. I didn't peruse its code in order to find out what changes the developer(s) made, but something is (or was) very different (or outright wrong) about the cdparanoia implementation in CDex. (For that matter, I can also tell you that cdda2wav has its own set of problematic issues.) Regardless, badly designed front ends are certainly not Monty's fault.

(I should also add that this was some time ago. Perhaps CDex has been improved since that time. I honestly do not know. I was sufficiently unimpressed with it. So much so that I never bothered trying CDex again.)

I'm not trying to be a windbag here. In order to properly answer your question, you would first need to demonstrate that you were having a cache issue with the prior, pre-10.2 cdparanoia XLD build in the first place. If you can do that, I'd be happy to see the results, because I have tried and failed for years to get a single verifiable one. I do believe that 10.2 handles cache issues more effectively and efficiently than earlier cdparanoia builds (why else would Monty have seen the need to design 10.2 otherwise?), but I also believe that the problem was never as common or as exaggerated as many people seem to believe.

I will also admit that I have no idea what the XLD "disable cache" feature is doing, or is supposed to be doing. I'm guessing that it is increasing the sector read ahead value (which can effectively work, if properly implemented), but that's just a guess.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #5
This is a keeper. Copied and stored.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #6
(Someone trotted out again this peculiar test the other day on the cdparanoia 10.2 thread; I don't know why the beyond silly "CD-with-the-hole-in-it proves cdparanoia is subpar!" test has become a mini-tradition at HA. Try that same disc on EAC and then tell us what you think that "proves" about that particular application. Do you see what I mean?)


You seem to have unloaded a lot of your own emotional baggage on my test there.
Calm down a bit, and go back and re-read it. It's only about comparing how Paranoia II and III handled that disk with one particular drive.
Why on earth would you have a problem about with that?
Anything about EAC there is from your imagination.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #7
Too early to tell for me.

I don't really consider caching to be much of an issue - if at all.
My favorite drive to use with cdparanoia is a caching drive. I'd love to try it out with Paranoia III, but unfortunately I'm about 2000 miles away from it now, and won’t get a chance till about the end of the year.

So far, I've been having a hard time coming up with trouble CD's to test with the drives I have available to me right now. I do have a couple of caching, and one non-caching drive to play around with. I'll keep trying with these.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #8
Here's the only problem disk that I've come up with so far.

Code: [Select]

X Lossless Decoder version 20080914a (90.1)

XLD extraction logfile from 2008-09-14 12:12:17 -0400

Various Artists / Whatever - The '90s Pop & Culture Box (Disc 7)

Used drive : _NEC DVD_RW ND-3550A (revision 1.05)

Use cdparanoia mode    : NO
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:00 | 04:49:58 |        0    |    21732 
        2  | 04:49:58 | 03:15:57 |    21733    |    36414 
        3  | 08:05:40 | 03:41:13 |    36415    |    53002 
        4  | 11:46:53 | 03:15:55 |    53003    |    67682 
        5  | 15:02:33 | 02:47:24 |    67683    |    80231 
        6  | 17:49:57 | 04:12:69 |    80232    |    99200 
        7  | 22:02:51 | 04:28:32 |    99201    |  119332 
        8  | 26:31:08 | 04:46:14 |    119333    |  140796 
        9  | 31:17:22 | 04:33:28 |    140797    |  161299 
      10  | 35:50:50 | 02:53:26 |    161300    |  174300 
      11  | 38:44:01 | 03:25:15 |    174301    |  189690 
      12  | 42:09:16 | 03:58:16 |    189691    |  207556 
      13  | 46:07:32 | 04:06:47 |    207557    |  226053 
      14  | 50:14:04 | 05:28:58 |    226054    |  250711 
      15  | 55:42:62 | 03:33:44 |    250712    |  266730 
      16  | 59:16:31 | 03:27:29 |    266731    |  282284 
      17  | 62:43:60 | 03:59:04 |    282285    |  300213 
      18  | 66:42:64 | 05:03:44 |    300214    |  322982 
      19  | 71:46:33 | 04:13:20 |    322983    |  341977 

List of suggested offset correction values
        #  | Absolute | Relative | Confidence
    ------------------------------------------
        1  |    48  |  -690  |      6   

All Tracks
    Album gain            : -7.72 dB
    Peak                  : 0.988495
Track 01
    Filename : /Users/davesprou/Desktop/XLD Rips/01 De La Soul - Itszoweezee (Hot).m4a

    Track gain            : -6.13 dB
    Peak                  : 0.968292
    CRC32 hash            : 90482681
    CRC32 hash (skip zero) : FA76B8BF
    AccurateRip signature  : 550E7317
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 02
    Filename : /Users/davesprou/Desktop/XLD Rips/02 The Cardigans - Lovefool.m4a

    Track gain            : -6.40 dB
    Peak                  : 0.888184
    CRC32 hash            : 85C2A1AD
    CRC32 hash (skip zero) : 1204805B
    AccurateRip signature  : 76DF74A7
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 03
    Filename : /Users/davesprou/Desktop/XLD Rips/03 Fountains Of Wayne - Radiation Vibe.m4a

    Track gain            : -8.82 dB
    Peak                  : 0.968231
    CRC32 hash            : 8E9E80AF
    CRC32 hash (skip zero) : A7C7E4B3
    AccurateRip signature  : 2EB0D4AA
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 04
    Filename : /Users/davesprou/Desktop/XLD Rips/04 The Mighty Mighty Bosstones - The Impression That I Get.m4a

    Track gain            : -9.25 dB
    Peak                  : 0.915649
    CRC32 hash            : 570D54B8
    CRC32 hash (skip zero) : BDD75C55
    AccurateRip signature  : BAF143EE
        ->Rip may not be accurate.

Track 05
    Filename : /Users/davesprou/Desktop/XLD Rips/05 Sleater-Kinney - Turn It On.m4a

    Track gain            : -9.02 dB
    Peak                  : 0.943970
    CRC32 hash            : 0CDB3D1C
    CRC32 hash (skip zero) : A676F301
    AccurateRip signature  : 36A72BDE
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 06
    Filename : /Users/davesprou/Desktop/XLD Rips/06 Meredith Brooks - Bitch.m4a

    Track gain            : -8.76 dB
    Peak                  : 0.955231
    CRC32 hash            : EF45169C
    CRC32 hash (skip zero) : E1E54103
    AccurateRip signature  : EF429073
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 07
    Filename : /Users/davesprou/Desktop/XLD Rips/07 Hanson - MMMBop.m4a

    Track gain            : -7.94 dB
    Peak                  : 0.933502
    CRC32 hash            : 4CAF6631
    CRC32 hash (skip zero) : E0B073E0
    AccurateRip signature  : 9FC5FF9A
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 08
    Filename : /Users/davesprou/Desktop/XLD Rips/08 Barenaked Ladies - Brian Wilson (Live).m4a

    Track gain            : -7.49 dB
    Peak                  : 0.988434
    CRC32 hash            : 01CC5D9C
    CRC32 hash (skip zero) : C55E478F
    AccurateRip signature  : 7CF4CF2E
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 09
    Filename : /Users/davesprou/Desktop/XLD Rips/09 Ben Folds Five - Brick.m4a

    Track gain            : -5.65 dB
    Peak                  : 0.937378
    CRC32 hash            : 963DD15A
    CRC32 hash (skip zero) : 2019BBDD
    AccurateRip signature  : BFF98A3E
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 10
    Filename : /Users/davesprou/Desktop/XLD Rips/10 Marcy Playground - Sex and Candy.m4a

    Track gain            : -7.21 dB
    Peak                  : 0.976410
    CRC32 hash            : 9F7E7D11
    CRC32 hash (skip zero) : 4C630465
    AccurateRip signature  : 3F332B5C
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 11
    Filename : /Users/davesprou/Desktop/XLD Rips/11 Smash Mouth - Walking On the Sun.m4a

    Track gain            : -8.05 dB
    Peak                  : 0.870117
    CRC32 hash            : 0E6DBE30
    CRC32 hash (skip zero) : 26C12E7C
    AccurateRip signature  : 1707746C
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 12
    Filename : /Users/davesprou/Desktop/XLD Rips/12 Chumbawamba - Tubthumping.m4a

    Track gain            : -7.47 dB
    Peak                  : 0.903870
    CRC32 hash            : 52ED8252
    CRC32 hash (skip zero) : 31E49FF7
    AccurateRip signature  : DEDE5ECD
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 13
    Filename : /Users/davesprou/Desktop/XLD Rips/13 Sneaker Pimps - 6 Underground.m4a

    Track gain            : -5.34 dB
    Peak                  : 0.882416
    CRC32 hash            : F5CFC805
    CRC32 hash (skip zero) : F87F3AB4
    AccurateRip signature  : 41862173
        ->Rip may not be accurate.

Track 14
    Filename : /Users/davesprou/Desktop/XLD Rips/14 Shawn Mullins - Lullaby.m4a

    Track gain            : -6.84 dB
    Peak                  : 0.988495
    CRC32 hash            : A84742D9
    CRC32 hash (skip zero) : 561019FF
    AccurateRip signature  : BED3BCEC
        ->Rip may not be accurate.

Track 15
    Filename : /Users/davesprou/Desktop/XLD Rips/15 Goo Goo Dolls - Slide.m4a

    Track gain            : -7.46 dB
    Peak                  : 0.938385
    CRC32 hash            : FC8A4E47
    CRC32 hash (skip zero) : 7061D271
    AccurateRip signature  : E211AB57
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 16
    Filename : /Users/davesprou/Desktop/XLD Rips/16 Sixpence None the Richer - Kiss Me.m4a

    Track gain            : -6.84 dB
    Peak                  : 0.900513
    CRC32 hash            : DFF79C87
    CRC32 hash (skip zero) : 75B48000
    AccurateRip signature  : 2F945EF5
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)

Track 17
    Filename : /Users/davesprou/Desktop/XLD Rips/17 Len - Steal My Sunshine.m4a

    Track gain            : -4.64 dB
    Peak                  : 0.958649
    CRC32 hash            : 771A1362
    CRC32 hash (skip zero) : 49504C08
    AccurateRip signature  : 016D33E8
        ->Rip may not be accurate.

Track 18
    Filename : /Users/davesprou/Desktop/XLD Rips/18 Everlast - What It's Like.m4a

    Track gain            : -5.69 dB
    Peak                  : 0.866638
    CRC32 hash            : DDF70F26
    CRC32 hash (skip zero) : 46B197BD
    AccurateRip signature  : C47169B0
        ->Rip may not be accurate.

Track 19
    Filename : /Users/davesprou/Desktop/XLD Rips/19 Moby - Natural Blues.m4a

    Track gain            : -5.05 dB
    Peak                  : 0.855316
    CRC32 hash            : 3E8A6CC2
    CRC32 hash (skip zero) : 42A78FDF
    AccurateRip signature  : 0A44CA7F
        ->Rip may not be accurate.

End of status report

Code: [Select]
X Lossless Decoder version 20080914a (90.1)

XLD extraction logfile from 2008-09-14 12:37:23 -0400

Various Artists / Whatever - The 90's Pop & Culture Box

Used drive : _NEC DVD_RW ND-3550A (revision 1.05)

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:00 | 04:49:58 |        0    |    21732 
        2  | 04:49:58 | 03:15:57 |    21733    |    36414 
        3  | 08:05:40 | 03:41:13 |    36415    |    53002 
        4  | 11:46:53 | 03:15:55 |    53003    |    67682 
        5  | 15:02:33 | 02:47:24 |    67683    |    80231 
        6  | 17:49:57 | 04:12:69 |    80232    |    99200 
        7  | 22:02:51 | 04:28:32 |    99201    |  119332 
        8  | 26:31:08 | 04:46:14 |    119333    |  140796 
        9  | 31:17:22 | 04:33:28 |    140797    |  161299 
      10  | 35:50:50 | 02:53:26 |    161300    |  174300 
      11  | 38:44:01 | 03:25:15 |    174301    |  189690 
      12  | 42:09:16 | 03:58:16 |    189691    |  207556 
      13  | 46:07:32 | 04:06:47 |    207557    |  226053 
      14  | 50:14:04 | 05:28:58 |    226054    |  250711 
      15  | 55:42:62 | 03:33:44 |    250712    |  266730 
      16  | 59:16:31 | 03:27:29 |    266731    |  282284 
      17  | 62:43:60 | 03:59:04 |    282285    |  300213 
      18  | 66:42:64 | 05:03:44 |    300214    |  322982 
      19  | 71:46:33 | 04:13:20 |    322983    |  341977 

List of suggested offset correction values
        #  | Absolute | Relative | Confidence
    ------------------------------------------
        1  |    48  |  -690  |      6   

All Tracks
    Album gain            : -7.72 dB
    Peak                  : 0.988495
Track 01
    Filename : /Users/davesprou/Desktop/XLD Rips/01 Various Artists - Itszoweezee (Hot).m4a

    Track gain            : -6.13 dB
    Peak                  : 0.968292
    CRC32 hash            : 90482681
    CRC32 hash (skip zero) : FA76B8BF
    AccurateRip signature  : 550E7317
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 3
        Atom jitter error (maybe fixed)      : 1
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 1
        Duplicated bytes error (maybe fixed) : 1

Track 02
    Filename : /Users/davesprou/Desktop/XLD Rips/02 Various Artists - Lovefool.m4a

    Track gain            : -6.40 dB
    Peak                  : 0.888184
    CRC32 hash            : 85C2A1AD
    CRC32 hash (skip zero) : 1204805B
    AccurateRip signature  : 76DF74A7
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 03
    Filename : /Users/davesprou/Desktop/XLD Rips/03 Various Artists - Radiation Vibe.m4a

    Track gain            : -8.82 dB
    Peak                  : 0.968231
    CRC32 hash            : 8E9E80AF
    CRC32 hash (skip zero) : A7C7E4B3
    AccurateRip signature  : 2EB0D4AA
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 04
    Filename : /Users/davesprou/Desktop/XLD Rips/04 Various Artists - The Impression That I Get.m4a

    Track gain            : -9.25 dB
    Peak                  : 0.915649
    CRC32 hash            : FDD2FC54
    CRC32 hash (skip zero) : 974BC3E6
    AccurateRip signature  : D343C430
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 8
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 05
    Filename : /Users/davesprou/Desktop/XLD Rips/05 Various Artists - Turn It On.m4a

    Track gain            : -9.02 dB
    Peak                  : 0.943970
    CRC32 hash            : 0CDB3D1C
    CRC32 hash (skip zero) : A676F301
    AccurateRip signature  : 36A72BDE
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 06
    Filename : /Users/davesprou/Desktop/XLD Rips/06 Various Artists - Bitch.m4a

    Track gain            : -8.76 dB
    Peak                  : 0.955231
    CRC32 hash            : 6F8A35FF
    CRC32 hash (skip zero) : BCA1AB8D
    AccurateRip signature  : AD542D7A
        ->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)      : 4
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 07
    Filename : /Users/davesprou/Desktop/XLD Rips/07 Various Artists - Mmmbop.m4a

    Track gain            : -7.94 dB
    Peak                  : 0.933502
    CRC32 hash            : 4CAF6631
    CRC32 hash (skip zero) : E0B073E0
    AccurateRip signature  : 9FC5FF9A
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 08
    Filename : /Users/davesprou/Desktop/XLD Rips/08 Various Artists - Brian Wilson.m4a

    Track gain            : -7.49 dB
    Peak                  : 0.988434
    CRC32 hash            : 01CC5D9C
    CRC32 hash (skip zero) : C55E478F
    AccurateRip signature  : 7CF4CF2E
        ->Rip may not be accurate.
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 1
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 1
        Duplicated bytes error (maybe fixed) : 1

Track 09
    Filename : /Users/davesprou/Desktop/XLD Rips/09 Various Artists - Brick.m4a

    Track gain            : -5.65 dB
    Peak                  : 0.937378
    CRC32 hash            : 963DD15A
    CRC32 hash (skip zero) : 2019BBDD
    AccurateRip signature  : BFF98A3E
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 1
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 1
        Duplicated bytes error (maybe fixed) : 1

Track 10
    Filename : /Users/davesprou/Desktop/XLD Rips/10 Various Artists - Sex And Candy.m4a

    Track gain            : -7.21 dB
    Peak                  : 0.976410
    CRC32 hash            : 9F7E7D11
    CRC32 hash (skip zero) : 4C630465
    AccurateRip signature  : 3F332B5C
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 11
    Filename : /Users/davesprou/Desktop/XLD Rips/11 Various Artists - Walkin' On The Sun.m4a

    Track gain            : -8.05 dB
    Peak                  : 0.870117
    CRC32 hash            : 0E6DBE30
    CRC32 hash (skip zero) : 26C12E7C
    AccurateRip signature  : 1707746C
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 12
    Filename : /Users/davesprou/Desktop/XLD Rips/12 Various Artists - Tubthumping.m4a

    Track gain            : -7.47 dB
    Peak                  : 0.903870
    CRC32 hash            : 52ED8252
    CRC32 hash (skip zero) : 31E49FF7
    AccurateRip signature  : DEDE5ECD
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 2
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 13
    Filename : /Users/davesprou/Desktop/XLD Rips/13 Various Artists - 6 Underground.m4a

    Track gain            : -5.34 dB
    Peak                  : 0.882416
    CRC32 hash            : 033BCF8E
    CRC32 hash (skip zero) : D046BA81
    AccurateRip signature  : 68E59272
        ->Rip may not be accurate.
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 2
        Atom jitter error (maybe fixed)      : 148
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 1

Track 14
    Filename : /Users/davesprou/Desktop/XLD Rips/14 Various Artists - Lullaby.m4a

    Track gain            : -6.84 dB
    Peak                  : 0.988495
    CRC32 hash            : B16AAFF9
    CRC32 hash (skip zero) : 390CD1EB
    AccurateRip signature  : FBDF6DDF
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 9
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 15
    Filename : /Users/davesprou/Desktop/XLD Rips/15 Various Artists - Slide.m4a

    Track gain            : -7.46 dB
    Peak                  : 0.938385
    CRC32 hash            : FC8A4E47
    CRC32 hash (skip zero) : 7061D271
    AccurateRip signature  : E211AB57
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 16
    Filename : /Users/davesprou/Desktop/XLD Rips/16 Various Artists - Kiss Me.m4a

    Track gain            : -6.84 dB
    Peak                  : 0.900513
    CRC32 hash            : DFF79C87
    CRC32 hash (skip zero) : 75B48000
    AccurateRip signature  : 2F945EF5
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 0
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 17
    Filename : /Users/davesprou/Desktop/XLD Rips/17 Various Artists - Steal My Sunshine.m4a

    Track gain            : -4.64 dB
    Peak                  : 0.958649
    CRC32 hash            : B978F4AE
    CRC32 hash (skip zero) : 67624197
    AccurateRip signature  : 2414F7E0
        ->Accurately ripped! (confidence 6)
          (matched with the different offset correction value;
          calculated using an additional offset of -690)
    Statistics
        Read error                          : 0
        Skipped (treated as error)          : 0
        Edge jitter error (maybe fixed)      : 0
        Atom jitter error (maybe fixed)      : 3
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 18
    Filename : /Users/davesprou/Desktop/XLD Rips/18 Various Artists - What It's Like.m4a

    Track gain            : -5.69 dB
    Peak                  : 0.866638
    CRC32 hash            : 01A20507
    CRC32 hash (skip zero) : 26AB1826
    AccurateRip signature  : 1CC24E89
        ->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)      : 56
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

Track 19
    Filename : /Users/davesprou/Desktop/XLD Rips/19 Various Artists - Natural Blues.m4a

    Track gain            : -5.05 dB
    Peak                  : 0.855316
    CRC32 hash            : BA71BB50
    CRC32 hash (skip zero) : 8AD32DED
    AccurateRip signature  : 9C322AF6
        ->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)      : 74
        Drift error (maybe fixed)            : 0
        Dropped bytes error (maybe fixed)    : 0
        Duplicated bytes error (maybe fixed) : 0

No errors occurred

End of status report

This is a non-caching drive.
The second rip is using Paranoia II.

I tried several times with Paranoia III, but the drive stopped on the last track every time. No successful rip.

The CD ripped fine with my Plextor 230 and MacBook internal Matshita without cdparanoia or verification enabled.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #9
You seem to have unloaded a lot of your own emotional baggage on my test there.
Calm down a bit, and go back and re-read it. It's only about comparing how Paranoia II and III handled that disk with one particular drive.
Why on earth would you have a problem about with that?
Anything about EAC there is from your imagination.


I wasn't really referring to your test. I was referring to the earlier thread, and -- more to the point -- the fact that I have seen that very thread cited elsewhere, and offered as "proof" that cdparanoia "doesn't work."

I don't have a problem with anything you said in the cdparanoia 10.2 thread, nor do I have to reread it to know that you said nothing about EAC there. The only reason I mentioned your missive is that I was mildly amused to read that you used a CD-with-a-hole-in-it to test this. I couldn't help but think "what is it about cdparanoia that makes people reach for the CD with a hole?" (Insert your own Freudian joke here.)

"Emotional baggage"? That's funny ... only because it's not true.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #10

You seem to have unloaded a lot of your own emotional baggage on my test there.
Calm down a bit, and go back and re-read it. It's only about comparing how Paranoia II and III handled that disk with one particular drive.
Why on earth would you have a problem about with that?
Anything about EAC there is from your imagination.


I wasn't really referring to your test. I was referring to the earlier thread, and -- more to the point -- the fact that I have seen that very thread cited elsewhere, and offered as "proof" that cdparanoia "doesn't work."

I don't have a problem with anything you said in the cdparanoia 10.2 thread, nor do I have to reread it to know that you said nothing about EAC there. The only reason I mentioned your missive is that I was mildly amused to read that you used a CD-with-a-hole-in-it to test this. I couldn't help but think "what is it about cdparanoia that makes people reach for the CD with a hole?" (Insert your own Freudian joke here.)

"Emotional baggage"? That's funny ... only because it's not true.


Hey - Some CD's have holes, some don't.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #11
Does anyone know how cdparanoia is implemented in CDex? Isn't it designed for *NIX kernel or will it run on the Win32 kernel as well?

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #12
XLD has integrated drive caching ability measurement routine of CDParanoia III 10.2.  Posted below is what the feature detected about my systems drive.  What is interesting is that EAC auto configuration indicated that the my systems drive does not cache.  Both seem to reporting the same.

XLD drive cache analysis logfile

Used drive : SONY DVD RW DW-D150A (revision 1.MD)

Your drive seems to have a cache of 3 sectors (6 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

End of status report

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #13
What is interesting is that EAC auto configuration indicated that the my systems drive does not cache.

EAC's test for audio caching is intended for its purposes only.  While it is unfortunate that people take EAC's wording literally; the result given is perfectly normal.  Drives that cache less than 64kB of audio data do not need to be configured as caching in EAC.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #14
XLD drive cache analysis logfile

Used drive : PLEXTOR CD-R  PX-230A (revision 1.02)

Your drive seems to have a cache of 588 sectors (1350 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

--- That's a bit of a surprise to me.


Used drive : _NEC DVD_RW ND-3550A (revision 1.05)

Your drive seems to have a cache of 2 sectors (4 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

Used drive : MATSHITA DVD-R  UJ-857E (revision ZF1E)

Your drive seems to have a cache of 8 sectors (18 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.


According  to this, I don't have any caching drives.

Is anyone getting any positive results?

Edit - Could have a wee bit to do with the caching controversy. What size cache is considered too much, and how many drives exceed that?

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #15
XLD drive cache analysis logfile

Used drive : PLEXTOR CD-R  PX-230A (revision 1.02)

Your drive seems to have a cache of 588 sectors (1350 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

--- That's a bit of a surprise to me.

[...]

Edit - Could have a wee bit to do with the caching controversy. What size cache is considered too much, and how many drives exceed that?


For purposes of cdparanoia, any drive that does not dump 100% of its cache on a non-monotonically increasing read offset is a caching drive.  That means even one sector of cache is a cache.  Only one drive in the immediate test set of ten works this way.  All versions of cdparanoia were designed to deal with caches, but before 10.2 made assumptions about cache size (150 sectors or less) and behavior (backward access of > 16 sectors dumps cache, etc) that are no loner true.

For a ripper that reads beginning to end, then compares against new reads that are also all beginning-to-end, cache isn't an issue.  The 'beginning to end strategy' is, in many ways, superior to the way cdparanoia works for mostly pristine discs and if you have the temp space and don't need to stream (cdparanoia was also begun in an era when 1G drives were really expensive.  Also no longer true  :-)  For heavy error situations, or the particularly nasty drives that were more common 10 years ago, cdparanoia is considerably more efficient.  Of course, using both together in either case makes perfect sense when concerned about maximum rip reliability.

If XLD, rubyripper, etc, never seek back a short amount and reread, then the only worry is if the cache is bigger than the size of the track your ripping.  It's actually really nice to not have to deal with cache.

EDIT:

OH!  and it's worth mentioning that the cdparanoia cache analysis code is doing all of its determinations empirically by watching drive timing and doing some inline statistical tricks (it is not asking the drive-- drives lie).  It would not surprise me if the results occasionally vary from run to run on some drives, particularly ones that get 'distracted' while performing readahead operations, or otherwise don't service requests when busy with an implicit background operation.  It goes without saying that moderate to heavy system load could also potentiall throw things off.  I've done everything I could to guard against inconsistency, but it's still a wild ride inside to code for some drives (that has nothing at all to do with the cache handling code inside cdparanoia itself).  In general, the cache analysis will underreport cache size if it gets thwarted, which shouldn't happen often.  It cannot overreport unless the drive is exhibiting faster-than-physically-possible seek behavior (via, perhaps, a nontraditional seek mechanism that isn't a laser/lens on a mechanical carriage).  I think the liklihood of that is low given that it would be more expensive to implement.

The analysis option is actually primarily meant to dump a huge logfile for human interpretation in the even that the drive raises exceptions or causes problems.  All the cache destruction code is new, and this is meant as a tool for users to easily report a ton of infomation back to me in the event of a problem.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #16

XLD drive cache analysis logfile

Used drive : PLEXTOR CD-R  PX-230A (revision 1.02)

Your drive seems to have a cache of 588 sectors (1350 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

--- That's a bit of a surprise to me.

[...]

Edit - Could have a wee bit to do with the caching controversy. What size cache is considered too much, and how many drives exceed that?


For purposes of cdparanoia, any drive that does not dump 100% of its cache on a non-monotonically increasing read offset is a caching drive.  That means even one sector of cache is a cache.  Only one drive in the immediate test set of ten works this way.  All versions of cdparanoia were designed to deal with caches, but before 10.2 made assumptions about cache size (150 sectors or less) and behavior (backward access of > 16 sectors dumps cache, etc) that are no loner true.

For a ripper that reads beginning to end, then compares against new reads that are also all beginning-to-end, cache isn't an issue.  The 'beginning to end strategy' is, in many ways, superior to the way cdparanoia works for mostly pristine discs and if you have the temp space and don't need to stream (cdparanoia was also begun in an era when 1G drives were really expensive.  Also no longer true  :-)  For heavy error situations, or the particularly nasty drives that were more common 10 years ago, cdparanoia is considerably more efficient.  Of course, using both together in either case makes perfect sense when concerned about maximum rip reliability.

If XLD, rubyripper, etc, never seek back a short amount and reread, then the only worry is if the cache is bigger than the size of the track your ripping.  It's actually really nice to not have to deal with cache.


Yikes! I'm gonna have to work a while on it before I understand that one.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #17
@Pepzhez

Caching is very easy to test, with a drive and a disc which can just be recovered - if caching was not invalidated then there would be more insecure rips. When talking of cache flushing, only certain plextors work with FUA. For other caching drives the cache can be removed by reading more than the cache size.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #18
@Pepzhez
When talking of cache flushing, only certain plextors work with FUA.


Not quite true.  Modern Plextors are ATAPI/MMC and there are no commands, zero, none, that allow FUA on audio discs.  Disabling the read cache on a Plextor only affects data discs.  try it with hdparm/sdparm and then run the cdparanoia cache analysis.  Zero difference.  if the cache was disabled, the analysis would say the drive was not caching.

(FUA stands for 'Force Unit Access'; it was a bit available in old SCSI-style read commands, back when Read10 and Read12 were repurposed to read audio discs as well.  Since the mid-1990s, new drives have read audio discs using a different command according to the new 'MMC' command set that replaced the SCSI command set for media drives.  This commnd is 'READ CD' and does not have an FUA bit.  There is no provision in MMC for forcing media access on an audio CD.  I have not seen a working FUA bit on a drive since the late 1990s, and only then on SCSI drives).

There was a time long ago when I recommended Plextor drives, but since 2000 or so, they've been the worst possible choice for DAE because they constantly interfere with the process and disobey spec (we fix it up in th Windows drivers!) with respect to timeouts.  Plextor drives are the #1 cause of Linux machines locking up hard during rips.

EDIT: i should say 'trigger' not 'cause'.  because the Plextors disobey timeout requests, the Linux kernel starts frantically issuing bus resets.  Several low level  Linux IDE drivers have bugs dealing with this error rcovery, and sometimes issue the reset to the wrong port or device.  Hilarity ensues.

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #19
I've seen a couple of non-Plextor drives that appear to accept the FUA command from EAC and dBpoweramp just fine (as does every true Plextor drive that I've ever encountered).

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #20
I've seen a couple of non-Plextor drives that appear to accept the FUA command from EAC and dBpoweramp just fine (as does every true Plextor drive that I've ever encountered).


There is no 'FUA Command'.  I'm not sure which actual command you mean.

And 'accepting' the command is different than actually doing something.  Even drives that have only one access speed accept the SPEED SET command.  They just do nothing.  Plextors will happily accept cache disabling commands when loaded with an audio disc, the command.... just does nothing.

Monty

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #21
Let's just say that despite the specifics of implementation and semantics over "accepting", the function is real and works...
http://www.hydrogenaudio.org/forums/index....st&p=360830

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #22
I'm not interested in arguing over semantics.

The function is real...
http://www.hydrogenaudio.org/forums/index....st&p=360830


I'm not either.  I'm trying to figure out what you meant.  i work from the specs the manufacturers use, and there is no 'FUA Command'.

Thanks for the link.  This is apparently Plextor using one of the reserved areas in the command to force FUA in a propriaetary way. This is annoying-- but only that it isn't part of the official MMC spec.  MMC absolutely should have this.

I have plenty of Plextors, will go give it a spin.  I don;t suppose you have a link for 'Seriously, Plextor, turn off the disappear for five minutes behavior'?  I need that way more than FUA :-)

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #23
I wish I could give you more information, but as you have probably already noticed this is beyond my level of expertise.  I'd check with Spath, Spoon or Andre.

EDIT:  I'm not sure if this is helpful but you might want to have a look at cachex:
http://www.hydrogenaudio.org/forums/index....showtopic=45996

Do you believe the drive cache problem has beeen fixed in XLD?

Reply #24
XLD cache analysis report for the two drives I have immediately at hand:

Code: [Select]
X Lossless Decoder version 20080916a (91.1)

XLD drive cache analysis logfile

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

Your drive seems to have a cache of 141 sectors (323 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

End of status report



X Lossless Decoder version 20080916a (91.1)

XLD drive cache analysis logfile

Used drive : PIONEER DVD-RW  DVR-K05 (revision Q523)

Your drive seems to have a cache of 141 sectors (323 Kbytes).
The cache size is too small to have an effect.
You can turn off "Disable cache" option.

End of status report


All versions of cdparanoia were designed to deal with caches, but before 10.2 made assumptions about cache size (150 sectors or less) and behavior (backward access of > 16 sectors dumps cache, etc) that are no loner true.

So it's no wonder that I never had cache issues with cdparanoia III. Both of these drives fall under the 150 sector tolerance -- and I'm willing to bet that the other drives I used in the past for my tests did as well.

I was using the EAC cache test as a benchmark for whether or not a drive cached. The problem has always been that we've never been able to test drive cache for cdparanoia's own purposes on OS X until today, now that XLD has incorporated the 10.2 (-A) option.

As greynol points out, EAC measures cache for its own purposes. Obviously, EAC (in its cache enabled mode) and cdparanoia III have always had different cache thresholds. I've long suspected that the tolerances for both programs were different, but how was I to confirm that? The upshot is that I and many others have spent all of these years misapplying to cdparanoia III the drive cache status reported by EAC -- and getting it wrong. 

I still am wondering what the XLD "defeat cache" switch is doing. Is it having any effect at all if your drive doesn't in fact cache with cdparanoia? I guess it's time to do some comparison rips.