Skip to main content ↑ ↓

Notice

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

Cdparanoia options in Rubyrip

By default, it uses -Z, which disables cdparanoias, well, paranoia. Makes it run just like cdda2wav.

Now why would it be off by default? is the Secure ripping chunk checking a sort of replacement? If there is a scratch on the disc that effects the read, would it be different for both passes making them not match up and pass, or will it just have the same error in the file and still "pass"

Just wondering if I should remove -Z, and even maybe add -z (lowercase, it will force it to retry over and over for forever to try to get the valid data from a sector it cant read, prob from a scratch) or even -X (cancels rip upon finding a scratch)

Prettymuch  dont want any "errors" on my files, rather find out right away have it deleted and then know I need a replacement CD, then have it tery to "fix" the bad sector and find out later on that many songs "may" have errors.

Cdparanoia options in Rubyrip

Reply #1 –
RubyRipper assumes that read errors are random.  Thus, since every track is ripped (at least) twice and compared (kind of like EAC's test & copy), this is considered more secure than 'paranoia -Z'.  This, if I remember correctly, doesn't play well with a lot of drives, so -Z is no guarantee of accuracy anyway.

Cdparanoia options in Rubyrip

Reply #2 –
Doesn't -Z mean "remove all paranoia" while -z sets the amount of retries (none = infinate)

Or when referring to it like that it means what it would be removing?

You also say it assumes read errors are random, are they? is there is a scratch, wont the read errors be in the same sectors?

Thanks man

Cdparanoia options in Rubyrip

Reply #3 –
Quote from: Heliologue on
This, if I remember correctly, doesn't play well with a lot of drives, so -Z is no guarantee of accuracy anyway.
I'm assuming this is because the data the drive offers when it can't correct an error really isn't random, or is there yet another reason?

Cdparanoia options in Rubyrip

Reply #4 –
Quote from: greynol on
Quote from: Heliologue on
This, if I remember correctly, doesn't play well with a lot of drives, so -Z is no guarantee of accuracy anyway.
I'm assuming this is because the data the drive offers when it can't correct an error really isn't random, or is there yet another reason?


I think because cdparanoia -Z will reread audio data from C2 cache if a drive supports it, rather than performing 2 distinct reads.  I recall reading something like that in a linux ripper thread here on HA.  But I'm obviously not the best resource for a definitive answer.




[edited for clarity]

Cdparanoia options in Rubyrip

Reply #5 –
Paranoia doesn't always work on all newer drives due to drive caching, it prevents rereads of the sectors as it just spits back out what was cached, reread it 20 times, and your getting the same info cached from the first.

You sure thats what -Z does?

Code: [Select]
-X, --abort-on-skip

    If a read fails and must be skipped, skip the entire track and delete any partially completed output file.

-Z, --disable-paranoia

    Disable data verification and correction. Causes cdparanoia to behave exactly as cdda2wav would.

-z, --never-skip[=retries]

    If a read fails (for example, due to a scratch in the disc), try again and again. If you specify a number, cdparanoia will try that number of times. If you do not, cdparanoia will retry until it succeeds. The default number of attempts is 20.


Im just trying to figure out if in Rubyrip, if I want a a 100% chance to not have MP3's with bad data on them from a faulty read (due to a scratch or some other sort of error with the read) zo I leave the default -Z (which I "think" disables all paranoia) or replace/compliment it with -X (cancels on skip)

Wish I knew if -X cancels on skips it couldnt get through after retrying or if it does it on the first skip (assume first skip if you disable all paranoia though )

Or if I should replace -Z with -z, which instead will never work past a scratch, will just keep retrying. (you will know that there is a problem with the CD if it stays on that track )


This all hinges on 1 thing though, when reading as disk, will a scratch/blemish/whatever that causes a problem with the read create the EXACT same data on a rip, I wanna know if the Rubyrips secure ripping where it rips twice and compares will be effective for finding glitches/read errors (like scratches).

Cdparanoia options in Rubyrip

Reply #6 –
Quote from: Heliologue on
I think because cdparanoia -Z will reread audio data from C2 cache if a drive supports it, rather than performing 2 distinct reads.  I recall reading something like that in a linux ripper thread here on HA.  But I'm obviously not the best resource for a definitive answer.
It is my understanding that Rubyripper has addressed the caching issue.  It doesn't fix the false assumption that drives produce random data upon errors, however.

Cdparanoia options in Rubyrip

Reply #7 –
Quote from: greynol on
Quote from: Heliologue on
I think because cdparanoia -Z will reread audio data from C2 cache if a drive supports it, rather than performing 2 distinct reads.  I recall reading something like that in a linux ripper thread here on HA.  But I'm obviously not the best resource for a definitive answer.
It is my understanding that Rubyripper has addressed the caching issue.  It doesn't fix the false assumption that drives produce random data upon errors, however.

So then it is a good idea to remove the -Z from it, and maybe add -z and/or -X ?

Cdparanoia options in Rubyrip

Reply #8 –
Quote from: Zaskar on
So then it is a good idea to remove the -Z from it, and maybe add -z and/or -X ?
I'm a Windows guy, so I can't help you with that.  I was answering your other question.

Cdparanoia options in Rubyrip

Reply #9 –
Quote from: greynol on
Quote from: Heliologue on
I think because cdparanoia -Z will reread audio data from C2 cache if a drive supports it, rather than performing 2 distinct reads.  I recall reading something like that in a linux ripper thread here on HA.  But I'm obviously not the best resource for a definitive answer.
It is my understanding that Rubyripper has addressed the caching issue.  It doesn't fix the false assumption that drives produce random data upon errors, however.


First of all most errors do indeed seem to be random ones for the same sector. If not, how would it ever be possible that some tracks do seem to need correction? Because discs in bad condition usually do need correction. Take for instance the test-disc that I scratched against the wall. It needs about 4-5 trials to have a match for each sector. I can't hear any audible difference though. The corrected positions of the track are reported in the logfile, so they are easily checked. Something that Exact Audio Copy fails to do.

In my view the ripper, cdparanoia, has a hard time reading the damaged sectors. Thereby mostly coming to slightly different results. The only valuable info that can be distilled from doing multiple reads for this sector is that what cdparanoia spits out most of the time is the correct result. Any other choice might actually be the correct one, though it's highly unlikely in my opinion.

If a damaged sector consequently spits out the same incorrect result than repairing is simply not possible! I highly doubt Exact Audio Copy could do anything about this. Only difference might be that the results of the ripping can be compared to the Accureterip database. Which is in my opinion is the very reason the database was set up in first place.

Time will tell if Rubyripper in future will support Accuraterip as well.
A secure audio ripper for linux: code.google.com/p/rubyripper

Cdparanoia options in Rubyrip

Reply #10 –
Quote from: frodoontop on
First of all most errors do indeed seem to be random ones for the same sector. If not, how would it ever be possible that some tracks do seem to need correction?
You say "seem to be random", but do you honestly think that drives produce random data when they encounter errors?    I mean, do you think the drive just makes up random numbers for samples once correction using CIRC has been exhausted?

Quote from: frodoontop on
Because discs in bad condition usually do need correction. Take for instance the test-disc that I scratched against the wall. It needs about 4-5 trials to have a match for each sector.
How can you be sure that matching data means the error was corrected?

Quote from: frodoontop on
In my view the ripper, cdparanoia, has a hard time reading the damaged sectors. Thereby mostly coming to slightly different results. The only valuable info that can be distilled from doing multiple reads for this sector is that what cdparanoia spits out most of the time is the correct result. Any other choice might actually be the correct one, though it's highly unlikely in my opinion.
Of several thousand tracks ripped that produce errors, how many of them do you think are consistent?  How do you have any way of truly knowing without the use of AccurateRip or C2 pointers (two things cdparanoia cannot do).

Quote from: frodoontop on
If a damaged sector consequently spits out the same incorrect result than repairing is simply not possible! I highly doubt Exact Audio Copy could do anything about this. Only difference might be that the results of the ripping can be compared to the Accureterip database. Which is in my opinion is the very reason the database was set up in first place.
This is true, but Exact Audio Copy isn't the only game in town.  dBpowerAMP has the ability deliver correct date in the event that errors are consistent, at least with drives that can provide C2 pointers.

Without understanding exactly how drives produce data upon reading errors, we're left to speculative hand-waving.  It is my experience that most errors that cannot be corrected produce different results with different attempts, however I've seen plenty of situations where errors have shown consistency; enough to know better than to just dismiss them as freak occurrences.

Cdparanoia options in Rubyrip

Reply #11 –
Quote from: greynol on
Quote from: frodoontop on
First of all most errors do indeed seem to be random ones for the same sector. If not, how would it ever be possible that some tracks do seem to need correction?
You say "seem to be random", but do you honestly think that drives produce random data when they encounter errors?    I mean, do you think the drive just makes up random numbers for samples once correction using CIRC has been exhausted?

Suppose you're right. How would you explain any differences between trials? Differences do occur from time to time. The only way to explain this is indeed to claim that drives tend to provide random data when a damaged sector is read.

Quote from: greynol on
Quote from: frodoontop on
Because discs in bad condition usually do need correction. Take for instance the test-disc that I scratched against the wall. It needs about 4-5 trials to have a match for each sector.
How can you be sure that matching data means the error was corrected?

I am not and didn't claim to be. It was only to support my argument that differences do occur when ripping damaged discs.

Quote from: greynol on
Quote from: frodoontop on
In my view the ripper, cdparanoia, has a hard time reading the damaged sectors. Thereby mostly coming to slightly different results. The only valuable info that can be distilled from doing multiple reads for this sector is that what cdparanoia spits out most of the time is the correct result. Any other choice might actually be the correct one, though it's highly unlikely in my opinion.
Of several thousand tracks ripped that produce errors, how many of them do you think are consistent?  How do you have any way of truly knowing without the use of AccurateRip or C2 pointers (two things cdparanoia cannot do).

Nobody can possibly know this. Consistent errors cannot be corrected. I've said so in my previous post. The use of C2 pointers might help, but cdparanoia doesn't support them. Anyway, the use of C2 pointers is still a bit controversial last time I read a discussion about them. Not all drives provide reliable C2 pointers.

Quote from: greynol on
Quote from: frodoontop on
If a damaged sector consequently spits out the same incorrect result than repairing is simply not possible! I highly doubt Exact Audio Copy could do anything about this. Only difference might be that the results of the ripping can be compared to the Accureterip database. Which is in my opinion is the very reason the database was set up in first place.
This is true, but Exact Audio Copy isn't the only game in town.  dBpowerAMP has the ability deliver correct date in the event that errors are consistent, at least with drives that can provide C2 pointers.

Without understanding exactly how drives produce data upon reading errors, we're left to speculative hand-waving.  It is my experience that most errors that cannot be corrected produce different results with different attempts, however I've seen plenty of situations where errors have shown consistency; enough to know better than to just dismiss them as freak occurrences.


That might be true altogether. But let's not forget Rubyripper isn't aimed at Windows users. Those users may indeed have better choices. In the GNU/Linux world not much was there to do anything about read errors, not even the inconsistent ones. I do believed I fixed the latter.

It's my opinion most read errors are indeed inconsistent. You are perfectly right to ask me for proof. Something that cannot easily be provided. Actual use of the program with some discs in bad condition might be worthwile. But then again, if you didn't even bother to try Rubyripper, how can you be so sure it's correction doesn't work?

Maybe your claims that consistent errors are more than just "freaky occurrences" should be provided with some proof as well. I'm looking forward to see it.
A secure audio ripper for linux: code.google.com/p/rubyripper

Cdparanoia options in Rubyrip

Reply #12 –
Quote from: frodoontop on
Suppose you're right. How would you explain any differences between trials? Differences do occur from time to time. The only way to explain this is indeed to claim that drives tend to provide random data when a damaged sector is read.
This is purely speculative, but I'd say that when a sector or several sectors in a row are trashed to the point where the drive can no longer recreate good data it uses data it thinks is good to fill in the parts it cannot determine.  Multiple reads over the same area may deliver a different set of points that it believes are good resulting in a different parts that are filled in.  The end result is data that appears to be random.

Quote from: frodoontop on
Anyway, the use of C2 pointers is still a bit controversial last time I read a discussion about them. Not all drives provide reliable C2 pointers.
This may be true from the aspect of using EAC. dBpowerAMP R12 Reference, OTOH, has the ability to determine when pointers are not reliable as well as successfully use them to get good data during re-reads of areas believed to be in error.

Quote from: frodoontop on
Quote from: greynol on
It is my experience that most errors that cannot be corrected produce different results with different attempts, however I've seen plenty of situations where errors have shown consistency; enough to know better than to just dismiss them as freak occurrences.
That might be true altogether. But let's not forget Rubyripper isn't aimed at Windows users. Those users may indeed have better choices. In the GNU/Linux world not much was there to do anything about read errors, not even the inconsistent ones. I do believed I fixed the latter.
I didn't forget and I do believe your program is capable of fixing errors when the drive is able to provide correct data often enough to meet whatever threshold your program has set and when bad data does not repeat itself with the same frequency.

Quote from: frodoontop on
It's my opinion most read errors are indeed inconsistent. You are perfectly right to ask me for proof. Something that cannot easily be provided.
[...]
Maybe your claims that consistent errors are more than just "freaky occurrences" should be provided with some proof as well. I'm looking forward to see it.
The burden of proof is difficult for either of us, though I feel it may a little bit harder for you since consistent errors can go undetected.  Luckily I usually keep such data whenever I encounter it.  (I hope you don't mind my reordering of your last sentences.)

Quote from: frodoontop on
Actual use of the program with some discs in bad condition might be worthwile. But then again, if you didn't even bother to try Rubyripper, how can you be so sure it's correction doesn't work?
Please don't take my criticism to mean that I think your program doesn't work!  I simply want people to understand that getting consistent data from a rip does not guarantee that the result was accurate.

Now for the data...
Code: [Select]
Used drive  : PLEXTOR DVDR   PX-716A   Adapter: 3  ID: 1
Read mode   : Secure with NO C2, accurate stream, disable cache

Track 11

     Track quality 99.7 %
     Test CRC 4AB5F428
     Copy CRC 727F4614
     Copy OK
------------------------------------------------------------
Track 11

     Suspicious position 0:01:21

     Track quality 99.7 %
     Test CRC 727F4614
     Copy CRC 727F4614
     Copy finished
------------------------------------------------------------
Track 11
     
     Suspicious position 0:01:20 - 0:01:21

     Track quality 99.6 %
     Test CRC 4AB5F428
     Copy CRC 4AB5F428
     Copy finished
------------------------------------------------------------
Track 11

     Track quality 99.8 %
     Test CRC AE99CD57
     Copy CRC AE99CD57
     Copy OK
The correct CRC for this track is 4AB5F428 which has been verified two ways: against accurate rip and a bit-for-bit comparison against a second copy of the disc.  The first rip shown of this track indicates different CRCs between the test pass and the copy pass with no errors being reported for either pass.  If you're not intimately familiar with EAC, this means that during any given set of re-reads the same data appeared at least 8 of 16 times.  If any of the data that made these passes different wasn't subjected to re-reads then it was read the same way twice out of two attempts (provided C2 pointers weren't being used).  As you can see, there are three different ripped versions of this same track that did not result in an error which means that they passed one of these criteria.

Anytime you see a pair of CRCs that do not match in EAC's secure mode (without C2 pointers and cache flushing used when necessary) and it says Copy OK, you can be certain that there were consistent errors.

I've seen numerous instances of this occurring over the years I have been looking at EAC log files.

Here's another example from a different disc (which I just ripped for this post)...
Code: [Select]
EAC extraction logfile from 26. August 2007, 19:29 for CD

Used drive  : PLEXTOR DVDR   PX-716A   Adapter: 3  ID: 1
Read mode   : Secure with NO C2, accurate stream, disable cache

Track  9

     Track quality 99.9 %
     Test CRC A3174342
     Copy CRC 421D347D
     Copy OK
------------------------------------------------------------
EAC extraction logfile from 26. August 2007, 19:34 for CD

Track  9

     Track quality 99.9 %
     Test CRC 6A1FB013
     Copy CRC 9F15701C
     Copy OK
The correct CRC is 6A1FB013, as verified by AccurateRip, BTW.

dBpowerAMP allows you to change the number of re-reads to perform before giving up while keeping the passing criteria fixed to 10 matches.  It isn't uncommon that increasing this number will eventually result in bad data being passed off as good, at least in cases when C2 pointers aren't being used.  10 matches certainly demonstrates at least some consistency, even if the number of tries is as large as 500 and perhaps even larger.
 

Cdparanoia options in Rubyrip

Reply #13 –
I'm also in the process of looking at some EAC logs posted here and just encountered this one...
Quote from: bozobalbo on
STAGE 1.1
edit: test 1 using pre-beta 0.99a with Massive Attack Mezzanine (Accuraterip keydisc)
Log 0.99 pre-beta: cache yes: c2 no
Code: [Select]
Exact Audio Copy V0.99 prebeta 1 from 25. May 2007
EAC extraction logfile from 31. July 2007, 11:39
Massive Attack / Mezzanine
Used drive  : PLEXTOR DVDR   PX-800A   Adapter: 1  ID: 0

Read mode			   : Secure
Utilize accurate stream : Yes
Defeat audio cache	  : Yes
Make use of C2 pointers : No

Read offset correction					  : 48
Overread into Lead-In and Lead-Out		  : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Used interface							  : Installed external ASPI interface
Gap handling								: Appended to previous track
...
Track  8
	 Filename E:\Documents and Settings\Rob\Desktop\EAC tests\Mezzanine\prebeta cache no c2\08 - Massive Attack - Black Milk .wav
	 Pre-gap length  0:00:01.49
	 Peak level 98.9 %
	 Track quality 99.5 %
	 Test CRC E3996D34
	 Copy CRC 4B67A6E5
	 Not accurately ripped (confidence 56)  [A5032F51], but should be [1DC46142]
	 Copy OK
...
Not all tracks ripped accurately
End of status report
Here's another post I made a while back indicating consistent errors ripped in burst mode...
http://www.hydrogenaudio.org/forums/index....st&p=441313

Quote from: greynol on
dBpowerAMP allows you to change the number of re-reads to perform before giving up while keeping the passing criteria fixed to 10 matches.  It isn't uncommon that increasing this number will eventually result in bad data being passed off as good, at least in cases when C2 pointers aren't being used.  10 matches certainly demonstrates at least some consistency, even if the number of tries is as large as 500 and perhaps even larger.
I also wanted to point out the beauty of using C2 pointers with dBpA.  When this is done in conjunction with large numbers of re-reads, consistent data will be dropped if flagged erroneous by a C2 pointer.  This is easily visible in a log file...
Code: [Select]
dBpoweramp Release 12.2 Digital Audio Extraction Log from Sunday, August 26, 2007 10:56 PM

Drive & Settings
----------------

Ripping with drive 'J:   [PLEXTOR  - DVDR   PX-716A  ]',  Drive offset: 30,  Overread Lead-in/out: Yes
AccurateRip: Active,  Using C2: Yes,  Cache: None,  FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Bad Sector Re-rip::  Drive Speed: 8,  Maximum Re-reads: 200

Encoder: Wave -compression="PCM"

Extraction Log
--------------

Track 10:  Ripped LBA 173385 to 193720 (4:31) in 0:54.
  AccurateRip: Accurate (confidence 6)     [Pass 1, Re-Rip 55 Frames]
  CRC32: 354BEE9E
    Re-rip Frame: 173676 (00:00:03.880) matched 10 / 11  (c2 dropped 31)
    Re-rip Frame: 173694 (00:00:04.120) matched 10 / 11  (c2 dropped 78)
    Re-rip Frame: 173924 (00:00:07.186) matched 10 / 11
    Re-rip Frame: 173941 (00:00:07.413) matched 10 / 11
    Re-rip Frame: 173942 (00:00:07.426) matched 10 / 11
    Re-rip Frame: 173959 (00:00:07.653) matched 10 / 11
    Re-rip Frame: 173960 (00:00:07.666) matched 10 / 11
    Re-rip Frame: 173977 (00:00:07.893) matched 10 / 11
    Re-rip Frame: 173978 (00:00:07.906) matched 10 / 11
    Re-rip Frame: 173994 (00:00:08.120) matched 10 / 11
    Re-rip Frame: 173995 (00:00:08.133) matched 10 / 11  (c2 dropped 4)
    Re-rip Frame: 174047 (00:00:08.826) matched 10 / 11  (c2 dropped 1)
    Re-rip Frame: 174048 (00:00:08.840) matched 10 / 11  (c2 dropped 14)
    Re-rip Frame: 174065 (00:00:09.066) matched 10 / 11
    Re-rip Frame: 174066 (00:00:09.080) matched 10 / 11
    Re-rip Frame: 174083 (00:00:09.306) matched 10 / 11
    Re-rip Frame: 174084 (00:00:09.320) matched 10 / 11
    Re-rip Frame: 174101 (00:00:09.546) matched 10 / 11  (c2 dropped 18)
    Re-rip Frame: 174118 (00:00:09.773) matched 10 / 11
    Re-rip Frame: 174119 (00:00:09.786) matched 10 / 11
    Re-rip Frame: 174136 (00:00:10.013) matched 10 / 11
    Re-rip Frame: 174137 (00:00:10.026) matched 10 / 11
    Re-rip Frame: 174154 (00:00:10.253) matched 10 / 11  (c2 dropped 9)
    Re-rip Frame: 174155 (00:00:10.266) matched 10 / 11
    Re-rip Frame: 174171 (00:00:10.480) matched 10 / 11  (c2 dropped 1)
    Re-rip Frame: 174172 (00:00:10.493) matched 10 / 11  (c2 dropped 14)
    Re-rip Frame: 174189 (00:00:10.720) matched 10 / 11
    Re-rip Frame: 174190 (00:00:10.733) matched 10 / 11
    Re-rip Frame: 174207 (00:00:10.960) matched 10 / 11  (c2 dropped 12)
    Re-rip Frame: 174208 (00:00:10.973) matched 10 / 11  (c2 dropped 4)
    Re-rip Frame: 174224 (00:00:11.186) matched 10 / 11
    Re-rip Frame: 174225 (00:00:11.200) matched 10 / 11
    Re-rip Frame: 174242 (00:00:11.426) matched 10 / 11
    Re-rip Frame: 174243 (00:00:11.440) matched 10 / 11
    Re-rip Frame: 174260 (00:00:11.666) matched 10 / 11
    Re-rip Frame: 174261 (00:00:11.680) matched 10 / 11
    Re-rip Frame: 174277 (00:00:11.893) matched 10 / 11
    Re-rip Frame: 174278 (00:00:11.906) matched 10 / 11
    Re-rip Frame: 174295 (00:00:12.133) matched 10 / 11
    Re-rip Frame: 174296 (00:00:12.146) matched 10 / 11
    Re-rip Frame: 174313 (00:00:12.373) matched 10 / 11
    Re-rip Frame: 174314 (00:00:12.386) matched 10 / 11
    Re-rip Frame: 174331 (00:00:12.613) matched 10 / 11
    Re-rip Frame: 174348 (00:00:12.840) matched 10 / 11
    Re-rip Frame: 174349 (00:00:12.853) matched 10 / 11
    Re-rip Frame: 174366 (00:00:13.080) matched 10 / 11
    Re-rip Frame: 174367 (00:00:13.093) matched 10 / 11
    Re-rip Frame: 174384 (00:00:13.320) matched 10 / 11
    Re-rip Frame: 174385 (00:00:13.333) matched 10 / 11
    Re-rip Frame: 174401 (00:00:13.546) matched 10 / 11
    Re-rip Frame: 174402 (00:00:13.560) matched 10 / 11
    Re-rip Frame: 177421 (00:00:53.813) matched 10 / 11
    Re-rip Frame: 177546 (00:00:55.480) matched 10 / 11
    Re-rip Frame: 177670 (00:00:57.133) matched 10 / 11
    Re-rip Frame: 177671 (00:00:57.146) matched 10 / 11

--------------

1 Tracks Ripped Accurately


====================

dBpoweramp Release 12.2 Digital Audio Extraction Log from Sunday, August 26, 2007 10:59 PM

Drive & Settings
----------------

Ripping with drive 'J:   [PLEXTOR  - DVDR   PX-716A  ]',  Drive offset: 30,  Overread Lead-in/out: Yes
AccurateRip: Active,  Using C2: No,  Cache: None,  FUA Cache Invalidate: Yes
Pass 1 Drive Speed: Max,  Pass 2 Drive Speed: Max
Bad Sector Re-rip::  Drive Speed: 8,  Maximum Re-reads: 200

Encoder: Wave -compression="PCM"

Extraction Log
--------------

Track 10:  Ripped LBA 173385 to 193720 (4:31) in 0:56.
  AccurateRip: Inaccurate (confidence 55)   Secure (Warning)  [Pass 1 & 2, Re-Rip 48 Frames]
  CRC32: BA1A863E
    Re-rip Frame: 173676 (00:00:03.880) matched 10 / 20
    Re-rip Frame: 173694 (00:00:04.120) matched 10 / 39
    Re-rip Frame: 173959 (00:00:07.653) matched 10 / 11
    Re-rip Frame: 173960 (00:00:07.666) matched 10 / 11
    Re-rip Frame: 174047 (00:00:08.826) matched 10 / 15
    Re-rip Frame: 174048 (00:00:08.840) matched 10 / 16
    Re-rip Frame: 174065 (00:00:09.066) matched 10 / 12
    Re-rip Frame: 174066 (00:00:09.080) matched 10 / 12
    Re-rip Frame: 174083 (00:00:09.306) matched 10 / 12
    Re-rip Frame: 174118 (00:00:09.773) matched 10 / 12
    Re-rip Frame: 174119 (00:00:09.786) matched 10 / 12
    Re-rip Frame: 174136 (00:00:10.013) matched 10 / 12
    Re-rip Frame: 174137 (00:00:10.026) matched 10 / 12
    Re-rip Frame: 174154 (00:00:10.253) matched 10 / 16
    Re-rip Frame: 174155 (00:00:10.266) matched 10 / 11
    Re-rip Frame: 174171 (00:00:10.480) matched 10 / 12
    Re-rip Frame: 174172 (00:00:10.493) matched 10 / 14
    Re-rip Frame: 174189 (00:00:10.720) matched 10 / 12
    Re-rip Frame: 174190 (00:00:10.733) matched 10 / 12
    Re-rip Frame: 174207 (00:00:10.960) matched 10 / 18
    Re-rip Frame: 174208 (00:00:10.973) matched 10 / 13
    Re-rip Frame: 174224 (00:00:11.186) matched 10 / 12
    Re-rip Frame: 174225 (00:00:11.200) matched 10 / 12
    Re-rip Frame: 174242 (00:00:11.426) matched 10 / 12
    Re-rip Frame: 174243 (00:00:11.440) matched 10 / 12
    Re-rip Frame: 174260 (00:00:11.666) matched 10 / 12
    Re-rip Frame: 174261 (00:00:11.680) matched 10 / 12
    Re-rip Frame: 174278 (00:00:11.906) matched 10 / 12
    Re-rip Frame: 174295 (00:00:12.133) matched 10 / 12
    Re-rip Frame: 174296 (00:00:12.146) matched 10 / 12
    Re-rip Frame: 174313 (00:00:12.373) matched 10 / 12
    Re-rip Frame: 174314 (00:00:12.386) matched 10 / 13
    Re-rip Frame: 174331 (00:00:12.613) matched 10 / 12
    Re-rip Frame: 174332 (00:00:12.626) matched 10 / 12
    Re-rip Frame: 174348 (00:00:12.840) matched 10 / 12
    Re-rip Frame: 174349 (00:00:12.853) matched 10 / 12
    Re-rip Frame: 174366 (00:00:13.080) matched 10 / 12
    Re-rip Frame: 174367 (00:00:13.093) matched 10 / 12
    Re-rip Frame: 174384 (00:00:13.320) matched 10 / 11
    Re-rip Frame: 177421 (00:00:53.813) matched 10 / 12
    Re-rip Frame: 177474 (00:00:54.520) matched 10 / 11
    Re-rip Frame: 177475 (00:00:54.533) matched 10 / 11
    Re-rip Frame: 177510 (00:00:55.000) matched 10 / 11
    Re-rip Frame: 177511 (00:00:55.013) matched 10 / 11
    Re-rip Frame: 177546 (00:00:55.480) matched 10 / 12
    Re-rip Frame: 177670 (00:00:57.133) matched 10 / 11
    Re-rip Frame: 177671 (00:00:57.146) matched 10 / 11
    Re-rip Frame: 177920 (00:01:00.466) matched 10 / 11

--------------

1 Tracks Ripped Securely (Warning: sectors had to be re-ripped) (AccurateRip: Different Pressing?)
The first rip was performed using C2 pointers and was verified as accurate with AccurateRip.  The second rip of the same track was done without C2 pointers and was deemed "Secure" though it could not be verified as accurate and since we know AR can verify the track, we can conclude that the result was an inaccurate rip.

Cdparanoia options in Rubyrip

Reply #14 –
Hi,

I just ripped my first CD on Ubuntu using RubyRipper. As it's a copy protected CD (Linkin Park - Meteora), and I don't know if it's alright what this nice tool did, I just wanted to ask you

PS: I removed the -Z switch!

That's the log file:

Code: [Select]
This log is created by Rubyripper, version 0.4.2
Website: http://code.google.com/p/rubyripper

Cdrom player used to rip:
TSSTcorp CD/DVDW SH-S183A SB03
Cdrom offset used: 6

Ripper used: cdparanoia ()
Matches required for all chunks: 2
Matches required for erronous chunks: 2

Codec(s) used:
-mp3    -> -V 2 --vbr-new
(LAME 32bits version 3.97 (http://www.mp3dev.org/))

CDDB INFO

Artist    = Linkin Park
Album    = Meteora
Year    = 2003
Genre    = Crossover
Tracks    = 13

01 - Foreword
02 - Don't Stay
03 - Somewhere I Belong
04 - Lying From You
05 - Hit The Floor
06 - Easier To Run
07 - Faint
08 - Figure 09
09 - Breaking The Habit
10 - From The Inside
11 - Nobody's Listening
12 - Session
13 - Numb

STATUS

Starting to rip track 1, trial 1#
Starting to rip track 1, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: b8d295dbe604d608383ab443382c1e5d

Starting to rip track 2, trial 1#
Starting to rip track 2, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: fb9f10a8299c90c6b87e1d91c89bc9aa

Starting to rip track 3, trial 1#
Starting to rip track 3, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 4393466fd4798bc5057fce9d3c8913e0

Starting to rip track 4, trial 1#
Starting to rip track 4, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 78166e71cc2052c4539e39e7a2cb2d0f

Starting to rip track 5, trial 1#
Starting to rip track 5, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 00a83bee31cb44c4881b924e116daf5f

Starting to rip track 6, trial 1#
Starting to rip track 6, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 39313a5279edeca572f1a6bc30d6de09

Starting to rip track 7, trial 1#
Starting to rip track 7, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 4eb0bb2ca57956827432f2df30cb0c00

Starting to rip track 8, trial 1#
Starting to rip track 8, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 4df323a104f3511a2a9b62944de1a14f

Starting to rip track 9, trial 1#
Starting to rip track 9, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: ee338d14cb30db9783ffbd511626a62f

Starting to rip track 10, trial 1#
Starting to rip track 10, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 4f5c73ed8efabc3504b269387116bc66

Starting to rip track 11, trial 1#
Starting to rip track 11, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 3178b87100572a843e11993ee727e3e7

Starting to rip track 12, trial 1#
Starting to rip track 12, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: bf7e88f14365172c0d1891d4cc6d4406

Starting to rip track 13, trial 1#
Starting to rip track 13, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: 9cabac59ef083a29360d0d252a4e869f


Thx