First experience with Rip

[ryans]

I have been experimenting with discs today and have come up with a problem. I am running Rip (version 1.0pb2) on a late 2008 Macbook running MacOS X 10.5.6 and discs would refuse to rip even a single track while Use C2 was selected. I tested with 6 different discs (all in AccurateRip). It would start to rip the first track but after extracting the audio it would start to run through re-extracting sectors. It would continue to repeat this over and over until the app crashed, I have the crash log if needed. After turning off Use C2 the same 6 discs ripped successfully without having to re-read sectors.

The stock drive in this model of Macbook is:

Drive used: MATSHITA DVD-R UJ-868 (KA14)
Interconnect type: Serial ATA
Location: Internal
Stream accurate: Yes
Read offset: 102

Another interesting thing I have noticed when comparing rips with ones from XLD is that all tracks in XLD report as being accurately ripped by AccurateRip, but in Rip only about half display Accurately ripped and the confidence level while the others show only Copy verified.

Other than that it is looking good at the moment.

[sbooth]

The issue causing the crash is something I've fixed for the next beta.

The way C2 works right now is that if a sector returns ANY C2 errors on a re-read, the data is discarded. So if a problematic sector on disc always returns a C2 error Rip will never mark that sector as "good", so the rip will never finish. This is why C2 can be turned off. Perhaps there is a more robust way to handle this case, but I haven't come up with a solution I like yet.

[Fuga]

I find the below from the original post kinda troubling.

Another interesting thing I have noticed when comparing rips with ones from XLD is that all tracks in XLD report as being accurately ripped by AccurateRip, but in Rip only about half display Accurately ripped and the confidence level while the others show only Copy verified.

[khead]

I find the below from the original post kinda troubling.

Another interesting thing I have noticed when comparing rips with ones from XLD is that all tracks in XLD report as being accurately ripped by AccurateRip, but in Rip only about half display Accurately ripped and the confidence level while the others show only Copy verified.

I've been getting some cases of Rip showing Copy Verified where the rip is off. Apparently, repeating errors that can slip through are not all that uncommon.

[Fuga]

Please. What do you mean by:

repeating errors that can slip

[chris5s]

I have been experimenting with discs today and have come up with a problem. I am running Rip (version 1.0pb2) on a late 2008 Macbook running MacOS X 10.5.6 and discs would refuse to rip even a single track while Use C2 was selected. I tested with 6 different discs (all in AccurateRip). It would start to rip the first track but after extracting the audio it would start to run through re-extracting sectors. It would continue to repeat this over and over until the app crashed, I have the crash log if needed. After turning off Use C2 the same 6 discs ripped successfully without having to re-read sectors.

The stock drive in this model of Macbook is:

Drive used: MATSHITA DVD-R UJ-868 (KA14)
Interconnect type: Serial ATA
Location: Internal
Stream accurate: Yes
Read offset: 102

Hm, I have a late 08 MB as well, but with a different stock drive (HL-DT-ST DVDRW GS21N: Firmware-Version: SA15) and have similiar problems ripping with C2 enabled. Could this be related to the drives or the chipset in the new Macbooks?
Cheers
Chris

[khead]

Please. What do you mean by:

repeating errors that can slip

Errors that are identical on the comparison rips won't get recognized as errors. If the disk isn't in AccurateRip, there's a small bit of uncertainty about Rip's report.

[Fuga]

Please. What do you mean by:

repeating errors that can slip

Errors that are identical on the comparison rips won't get recognized as errors. If the disk isn't in AccurateRip, there's a small bit of uncertainty about Rip's report.

Thanks. Unfortunately is as I figured. Unfortunate.