Possible chunk bug?

[GoogleCodeExporter]

Ordinarily this troublesome disc corrects easily, but when I pass some
different options it never finishes.  Also, one of the times it reported an
very high number (like 27162) of errors after the first comparison.  I feel
it was bogus since every other time it was less than 20.  Jitter can of
course cause that but there was no jitter reported int he ripping lines. 
Hmmm.  Anyway it only happened with different parameters than what I
usually use.

What version of rubyripper are you using? On what operating system? Are you
using the gtk2 or the commandline interface?
svn 90, Debian.

Please provide any additional information below.

This log is created by Rubyripper, version 0.4 beta
Website: http://code.google.com/p/rubyripper

Cdrom player used to rip:
_NEC DVD_RW ND-3550A 1.05
Cdrom offset used: 48

Ripper used: cdparanoia (-zX -S 1)
Matches required for all chunks: 3
Matches required for erronous chunks: 5

Codec(s) used:
-wav

CDDB INFO

Artist  = TYR
Album   = Eric The Red (re-release)
Year    = 2006
Genre   = Pagan Metal
Tracks  = 12

01 - The Edge
02 - Regin Smidur ... Regin Blacksmith
03 - Dreams
04 - The Wild Rover
05 - Styrisvolurin ... The Tiller
06 - Olavur Riddararos ... Olav Lillyleaf
07 - Rainbow Warrior
08 - Ramund Hin Unge ... The Young Raymond
09 - Alive
10 - Eric the Red
11 - God Of War (bonus track)
12 - Hail To The Hammer (bonus track)

STATUS

Starting to rip track 11, trial 1#
Starting to rip track 11, trial 2#
Starting to rip track 11, trial 3#
Analyzing files for mismatching chunks
14 chunk(s) didn't match 3 times.
Starting to rip track 11, trial 4#
Starting to rip track 11, trial 5#
Starting to rip track 11, trial 6#
8 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 7#
7 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 8#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 9#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 10#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 11#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 12#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 13#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 14#
5 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 15#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 16#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 17#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 18#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 19#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 20#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 21#
4 chunk(s) didn't match 5 times.
Starting to rip track 11, trial 22#

Original issue reported on code.google.com by mordbr...@gmail.com on 31 Mar 2007 at 11:41

[GoogleCodeExporter]

That rubyripper reports  a lot of differences after the first trials, I 
consider a 
cdparanoia bug. Apparently sometimes all bytes are shifted or something like 
that. 
However the filesize doesn't change. So there is nothing I can do about that. I 
could reset ripping the track if a lot of differences are found, if that's 
usefull.

The options you used for cdparanoia here are: never skip (-z), abort on skip 
(-X) 
and read speed at 1x (-S 1). Although I fail to see the improvement of -X when 
-z 
is already in use, with these settings cdparanoia will try real hard to get the 
audio info of the disc. 

Soms discs however, can't be repaired. You will find the same behaviour with 
Exact 
Audio Copy. That's why I put in an option to set a max of trials. The whole 
idea is 
that if a cd can't be corrected, cdparanoia returns random data. According to 
your 
post this pretty much happens.

Although rubyripper does not correct the track completely, after trial 8, I am 
pretty sure that you're not able to hear it. 1 chunk represents only a small 
amount 
of time, far less than a second.

All in all, I'm closing this isssue, as I don't believe it's a bug. If it were, 
we 
would have noticed so way before.

Original comment by rubyripp...@gmail.com on 4 Apr 2007 at 8:30

• Changed state: Fixed

[GoogleCodeExporter]

Did not know that about CD paranoia shifting bytes.  Thought it would throw up 
some
type of correction in the status bar if it did.  

-X is an old habit on my part; it really never aborts.  Yeah, it looks like a 
disc
that can't be repaired... however it must lay with cdparanoia; I guess it is 
possible
when -z isn't used it falsely reads repeatedly and considers the error fixed, 
while
when using -z it truly grabs random data.

On first look I thought one of the settings might have been confusing rr, but I
should learn that cdparanoia is usually to blame ;)

Original comment by mordbr...@gmail.com on 9 Apr 2007 at 1:08

[GoogleCodeExporter]

Well cdparanoia isn't always to blame offcourse ;) But in this particular case 
I 
think it is. Things like bad repairing should happen on at least a few discs to 
raise suspicion.

Original comment by rubyripp...@gmail.com on 9 Apr 2007 at 8:10