IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
Do you believe the drive cache problem has beeen fixed in XLD?, XLD using latest version of CD Paranoia III 10.2.
Do you believe that XLD's "Disable cache" feature works correctly?
You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Total Votes: 43
Guests cannot vote 
macman4hire
post Sep 15 2008, 01:42
Post #1





Group: Members
Posts: 185
Joined: 5-June 08
From: USA
Member No.: 54037



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.

This post has been edited by macman4hire: Sep 24 2008, 19:45
Go to the top of the page
+Quote Post
tim.lance
post Sep 15 2008, 02:04
Post #2





Group: Members
Posts: 89
Joined: 9-July 07
Member No.: 45161



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.
Go to the top of the page
+Quote Post
vulc44n
post Sep 15 2008, 02:10
Post #3





Group: Members
Posts: 91
Joined: 5-October 05
From: USA
Member No.: 24889



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.
Go to the top of the page
+Quote Post
macman4hire
post Sep 15 2008, 02:30
Post #4





Group: Members
Posts: 185
Joined: 5-June 08
From: USA
Member No.: 54037



QUOTE (vulc44n @ Sep 14 2008, 19:10) *
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.

This post has been edited by macman4hire: Sep 15 2008, 02:32
Go to the top of the page
+Quote Post
Pepzhez
post Sep 15 2008, 03:03
Post #5





Group: Members
Posts: 256
Joined: 18-May 03
Member No.: 6685



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.

This post has been edited by Pepzhez: Sep 15 2008, 09:58
Go to the top of the page
+Quote Post
tim.lance
post Sep 15 2008, 03:27
Post #6





Group: Members
Posts: 89
Joined: 9-July 07
Member No.: 45161



This is a keeper. Copied and stored.
Go to the top of the page
+Quote Post
knucklehead
post Sep 15 2008, 12:43
Post #7





Group: Members
Posts: 129
Joined: 27-October 04
Member No.: 17880



QUOTE (Pepzhez @ Sep 14 2008, 18:03) *
(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.
Go to the top of the page
+Quote Post
knucklehead
post Sep 15 2008, 13:41
Post #8





Group: Members
Posts: 129
Joined: 27-October 04
Member No.: 17880



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.
Go to the top of the page
+Quote Post
knucklehead
post Sep 15 2008, 14:32
Post #9





Group: Members
Posts: 129
Joined: 27-October 04
Member No.: 17880



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

CODE


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

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.
Go to the top of the page
+Quote Post
Pepzhez
post Sep 15 2008, 14:38
Post #10





Group: Members
Posts: 256
Joined: 18-May 03
Member No.: 6685



QUOTE (knucklehead @ Sep 15 2008, 03:43) *
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.
Go to the top of the page
+Quote Post
knucklehead
post Sep 15 2008, 15:23
Post #11





Group: Members
Posts: 129
Joined: 27-October 04
Member No.: 17880



QUOTE (Pepzhez @ Sep 15 2008, 05:38) *
QUOTE (knucklehead @ Sep 15 2008, 03:43) *

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.
smile.gif
Go to the top of the page
+Quote Post
frozenspeed
post Sep 15 2008, 16:41
Post #12





Group: Members
Posts: 207
Joined: 16-October 01
From: Seattle, WA
Member No.: 301



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?
Go to the top of the page
+Quote Post
macman4hire
post Sep 15 2008, 19:45
Post #13





Group: Members
Posts: 185
Joined: 5-June 08
From: USA
Member No.: 54037



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. smile.gif

End of status report
Go to the top of the page
+Quote Post
greynol
post Sep 15 2008, 19:54
Post #14





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (macman4hire @ Sep 15 2008, 11:45) *
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.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
knucklehead
post Sep 15 2008, 20:10
Post #15





Group: Members
Posts: 129
Joined: 27-October 04
Member No.: 17880



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. smile.gif

--- 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. smile.gif

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. smile.gif


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?

This post has been edited by knucklehead: Sep 15 2008, 20:23
Go to the top of the page
+Quote Post
xiphmont
post Sep 15 2008, 21:13
Post #16


Xiph.org


Group: Developer
Posts: 169
Joined: 24-September 01
Member No.: 16



QUOTE (knucklehead @ Sep 15 2008, 15:10) *
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. smile.gif

--- 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.

This post has been edited by xiphmont: Sep 15 2008, 21:25
Go to the top of the page
+Quote Post
knucklehead
post Sep 15 2008, 21:23
Post #17





Group: Members
Posts: 129
Joined: 27-October 04
Member No.: 17880



QUOTE (xiphmont @ Sep 15 2008, 12:13) *
QUOTE (knucklehead @ Sep 15 2008, 15:10) *

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. smile.gif

--- 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.
Go to the top of the page
+Quote Post
spoon
post Sep 15 2008, 21:26
Post #18


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



@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.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
xiphmont
post Sep 15 2008, 21:54
Post #19


Xiph.org


Group: Developer
Posts: 169
Joined: 24-September 01
Member No.: 16



QUOTE (spoon @ Sep 15 2008, 16:26) *
@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.

This post has been edited by xiphmont: Sep 15 2008, 21:57
Go to the top of the page
+Quote Post
greynol
post Sep 15 2008, 22:02
Post #20





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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).

This post has been edited by greynol: Sep 15 2008, 22:04


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
xiphmont
post Sep 15 2008, 22:11
Post #21


Xiph.org


Group: Developer
Posts: 169
Joined: 24-September 01
Member No.: 16



QUOTE (greynol @ Sep 15 2008, 17:02) *
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
Go to the top of the page
+Quote Post
greynol
post Sep 15 2008, 22:21
Post #22





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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

This post has been edited by greynol: Sep 15 2008, 22:27


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
xiphmont
post Sep 15 2008, 22:25
Post #23


Xiph.org


Group: Developer
Posts: 169
Joined: 24-September 01
Member No.: 16



QUOTE (greynol @ Sep 15 2008, 17:21) *
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 :-)

This post has been edited by xiphmont: Sep 15 2008, 22:26
Go to the top of the page
+Quote Post
greynol
post Sep 15 2008, 22:36
Post #24





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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

This post has been edited by greynol: Sep 15 2008, 22:43


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Pepzhez
post Sep 16 2008, 01:42
Post #25





Group: Members
Posts: 256
Joined: 18-May 03
Member No.: 6685



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

CODE

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. smile.gif

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. smile.gif

End of status report



QUOTE (xiphmont @ Sep 15 2008, 12:13) *
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. ohmy.gif

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.

This post has been edited by Pepzhez: Sep 16 2008, 02:09
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th April 2014 - 11:25