First track sometimes stutters at the beginning

GoogleCodeExporter commented 8 years ago

Using rubyripper 0.5.7-1~getdeb1 (info from dpkg) on Ubuntu 10.4 (32-bit)
through the gtk interface.

On *some* discs, I've found that the first track is ripped with the first
few seconds, those first few seconds again, a garbled fraction of a second,
and then everything else is normal. The other tracks rip normally.

My CD drive is a DVD/RW combo: TSSTCorp SH-S223C. Ripping log is attached
(everything is normal). This happens whether I specify the drive offset
(+697, as listed by http://www.accuraterip.com/driveoffsets.htm ) or leave
it at 0.

Any thoughts? I can attach the actual rip (or just the mangled part at the
beginning) in raw WAVE or MP3.

This doesn't seem to happen with all discs, but so far, I haven't found a
pattern. My data points are that "Doubt" by Jesus Jones and "Ramones" by
the Ramones both seem to have this problem, but "Son of a Son of a Sailor"
by Jimmy Buffet does not.

Original issue reported on code.google.com by m.sakre...@gmail.com on 30 May 2010 at 6:54

Attachments:

ripping.log

GoogleCodeExporter commented 8 years ago

I think you skipped this important question:
5) Does the problem happen with different discs? If not, please attach
the output of cdparanoia -Q.

Original comment by boukewou...@gmail.com on 30 May 2010 at 9:22

GoogleCodeExporter commented 8 years ago

I thought ripping.log was the output of cdparanoia. I did not see any other log 
config.  
I'll take another look later in case it's obvious (on a different machine now), 
but if 
it's not, can you tell me how to produce the cdparanoia log?

Original comment by m.sakre...@gmail.com on 31 May 2010 at 4:55

GoogleCodeExporter commented 8 years ago

It's not a log, it's a scan of the table of contents of a disc.

1) Open up a terminal
2) Type "cdparanoia -Q"
3) Press Enter

I suspect the discs have a little hidden part before track 1. Sometimes this is 
just 
noise, which may be perceived as stutter.

Original comment by boukewou...@gmail.com on 31 May 2010 at 6:10

GoogleCodeExporter commented 8 years ago

Thanks. Here it is:

maciek@albatross:~$ cdparanoia -Q
cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.     9695 [02:09.20]       37 [00:00.37]    no   no  2
  2.    16188 [03:35.63]     9732 [02:09.57]    no   no  2
  3.    14460 [03:12.60]    25920 [05:45.45]    no   no  2
  4.    15015 [03:20.15]    40380 [08:58.30]    no   no  2
  5.    14215 [03:09.40]    55395 [12:18.45]    no   no  2
  6.    15122 [03:21.47]    69610 [15:28.10]    no   no  2
  7.    14208 [03:09.33]    84732 [18:49.57]    no   no  2
  8.    16245 [03:36.45]    98940 [21:59.15]    no   no  2
  9.    17407 [03:52.07]   115185 [25:35.60]    no   no  2
 10.    13025 [02:53.50]   132592 [29:27.67]    no   no  2
 11.    17320 [03:50.70]   145617 [32:21.42]    no   no  2
 12.    21808 [04:50.58]   162937 [36:12.37]    no   no  2
TOTAL  184708 [41:02.58]    (audio only)

This is "Doubt", mentioned above. If I'm reading this correctly, there is no 
such
hidden part here.

Also, it's not just stutter. The ripped file very clearly starts the first few
seconds of the song, re-starts those first few seconds, stutters very briefly, 
and
continues normally for the rest of the disc. This same pattern seems to show up 
in
all affected discs, but other discs are fine.

Original comment by m.sakre...@gmail.com on 1 Jun 2010 at 3:08

GoogleCodeExporter commented 8 years ago

Now the important question is, is it reproducable? Will the same disc produce 
stutter 
everytime? I guess it will, since the tracks are compared at least once.

I do suspect it may be a defect with your cdrom drive. Which is only triggered 
when 
trying to rip the hidden part. (Notice that the cd above starts with sector 37 
instead of zero.) As a workaround you might try to disable ripping the hidden 
part.

If you want to simulate the call to cdparanoia from rubyripper use:
cdparanoia -Z [.0]-[.9695] -d /dev/cdrom -O 697 out.wav 2>&1

Original comment by boukewou...@gmail.com on 1 Jun 2010 at 8:30

GoogleCodeExporter commented 8 years ago

Yep, consistently reproducible (well, with a sample size of two separate rips 
for one
disc, so four track rips if you count the comparison rip).

I'll take a look tonight, and I'll also try to see what other rippers do with 
the disc.

Thanks for your help.

Original comment by m.sakre...@gmail.com on 1 Jun 2010 at 8:42

GoogleCodeExporter commented 8 years ago

Hmm. Interesting:

maciek@albatross:~$ cdparanoia -Z [.0]-[.9695] -d /dev/cdrom -O 697 out.wav 2>&1
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector       0 (track  0 [0:00.00])
      to sector    9695 (track  1 [2:08.57])

outputting to out.wav

scsi_read error: sector=0 length=1 retry=0
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=1
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=2
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=3
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=4
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=5
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=6
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=7
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=8
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=27 retry=0
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=13 retry=1
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=6 retry=2
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=3 retry=3
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=4
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=5
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=6
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=7
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=0 length=1 retry=8
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
 (== PROGRESS == [>                             | ...... 00 ] == :-0 . ==)  
scsi_read error: sector=27 length=27 retry=0
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=13 retry=1
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=6 retry=2
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=3 retry=3
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=1 retry=4
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=1 retry=5
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=1 retry=6
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=1 retry=7
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
scsi_read error: sector=27 length=1 retry=8
                 Sense key: 5 ASC: 64 ASCQ: 0
                 Transport error: Illegal SCSI request (rejected by target)
                 System error: Invalid argument
 (== PROGRESS == [e                             | 009695 00 ] == :^D * ==)   

Done.

maciek@albatross:~$ see out.wav 

...and it plays fine.

So I do get a whole bunch of errors (is this the disparity between the offset 
and the
[.0] span start for cdparanoia?), but to me, the track sounds fine. The stutter 
I get
from rubyripper is definitely *not* there. I tried re-ripping and the rubyripper
stutter is still there. I even tried re-ripping without encoding to mp3 to 
verify
it's not an encoding problem, and I get the same thing.

Original comment by m.sakre...@gmail.com on 2 Jun 2010 at 6:13

GoogleCodeExporter commented 8 years ago

Tried against HEAD, and I get the same result. Now an expected file size check 
fails
on the first rip, but further attempts seem to succeed (although, oddly, with 
the
same unexpected file size):

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

Cdrom player used to rip:
TSSTcorp CDDVDW SH-S223C SB01
Cdrom offset used: 697

Ripper used: cdparanoia 
Matches required for all chunks: 2
Matches required for erroneous chunks: 2

Codec(s) used:
-wav

CDDB INFO

Artist  = Jesus Jones
Album   = Doubt
Year    = 1991
Genre   = Rock
Tracks  = 12 (1 selected)

01 - Trust Me

STATUS

Starting to rip track 1, trial #1 (291 seconds)
Filesize is not correct! Trying another time
Starting to rip track 1, trial #1 (512 seconds)
Starting to rip track 1, trial #2 (512 seconds)
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 sum: c601eff02806261a1490768f4cfaed61

RIPPING SUMMARY

All chunks were tried to match at least 2 times.
None of the tracks gave any problems

Original comment by m.sakre...@gmail.com on 3 Jun 2010 at 2:01

GoogleCodeExporter commented 8 years ago

Scratch that "same unexpected files size" comment--I'm not sure where I thought 
that
was coming from.

Though for what it's worth, I had started rubyripper from a terminal and I 
noticed
some possibly-relevant std{out,err}:

/home/maciek/Desktop/Jesus Jones/Doubt
01-Trust Me.wav
02-Who Where Why.wav
03-International Bright Young Thing.wav
04-I'm Burning.wav
05-Right Here, Right Now.wav
06-Nothing To Hold Me.wav
07-Real, Real, Real.wav
08-Welcome Back Victoria.wav
09-Are You Satisfied.wav
10-Two and Two.wav
11-Stripped.wav
12-Blissed.wav
status = true
Ripping track 1
Expected filesize for track 1       is 22889708 bytes.
Free disk space is 168542244 MB
Minutes ripping is 0.000486133333333333.
cdparanoia [.0]-[.9731] -d /dev/cdrom -O 697 "/home/maciek/Desktop/Jesus
Jones/temp_sr0/track1_1.wav" 2>&1
Some sectors are missing for track 1 : 22889664 sector(s)
Filesize should be : 22889708
Expected filesize for track 1       is 22889708 bytes.
Free disk space is 168541644 MB
Minutes ripping is 4.85324851666667.
cdparanoia [.0]-[.9731] -d /dev/cdrom -O 697 "/home/maciek/Desktop/Jesus
Jones/temp_sr0/track1_1.wav" 2>&1
Minutes ripping is 13.3907214333333.
cdparanoia [.0]-[.9731] -d /dev/cdrom -O 697 "/home/maciek/Desktop/Jesus
Jones/temp_sr0/track1_2.wav" 2>&1
Adding track 1 (wav) to the queue..
Removing track 1 (wav) from the queue..
Inside the finished function

Original comment by m.sakre...@gmail.com on 3 Jun 2010 at 2:05

GoogleCodeExporter commented 8 years ago

I see that the command rubyripper is sending is in fact a little different than 
I 
thought:

cdparanoia [.0]-[.9731] -d /dev/cdrom -O 697 out.wav 2>&1

When done manually, will this still not reproduce the error? Rubyripper doesn't 
do 
anything special to the audio when there is a match.

Original comment by boukewou...@gmail.com on 4 Jun 2010 at 7:06

GoogleCodeExporter commented 8 years ago

Ah, good catch. I didn't notice that. And yep, that repros it with just 
cdparanoia
(although I can't quite figure out why), so it looks like rubyripper is not 
driving
it properly.

Original comment by m.sakre...@gmail.com on 5 Jun 2010 at 4:23

GoogleCodeExporter commented 8 years ago

It's this:

        elsif @startSector[1] != 0 # prepend the audio because it's not marked as a hidden
track
            @lengthSector[1] = @lengthSector[1] + @startSector[1]
            @startSector[1] = 0
        end

no? combined with:

        # for the last track tell cdparanoia to rip till end to prevent problems on some drives
        if track != "image" && track != @settings['cd'].audiotracks
            command += "[.#{@settings['cd'].getLengthSector(track) - 1}]"
        end

Basically, this tells cdparanoia to prepend the hidden audio onto the first 
track,
since it's too short to get its own track, right? I think rubyripper's 
reasoning here
is reasonable.

However, for some reason, this seems to confuse cdparanoia since there are 
problems
ripping those initial sectors.

I think the span [.0]-[.09695] isn't quite right either, because that would 
miss the
last 37 sectors, no? I don't know enough about ripping to be able to guess why
cdparanoia (or my CD drive, I suppose) doesn't like what seems to be the correct
span, but perhaps there should be another setting, similar to 
minLengthHiddenTrack,
that indicates a discard threshold for hidden audio.

E.g., let's call it minLengthAppendHiddenTrack. This setting must always be 
less than
minLengthHiddenTrack. If the hidden track is less than 
minLengthAppendHiddenTrack,
it's ignored completely. If it's between minLengthAppendHiddenTrack and
minLengthHiddenTrack, it's appended to the following track. If it's more than
minLengthHiddenTrack, it's ripped into its own track. I think that would solve 
my
problem, but I'm not sure if it makes sense in general.

Perhaps the right fix here is to try to get this solved at the cdparanoia level,
although since the last commits are six months old, I'm not sure how viable 
that is.
Especially since it might be just me with a wonky CD drive...

Original comment by m.sakre...@gmail.com on 5 Jun 2010 at 6:23

GoogleCodeExporter commented 8 years ago

What happens if you uncheck "rip the hidden audio part" in the preferences?

Original comment by boukewou...@gmail.com on 7 Jun 2010 at 7:07

GoogleCodeExporter commented 8 years ago

I guess I find out that I should read preferences more carefully. I'll try it 
when I
get home.

Original comment by m.sakre...@gmail.com on 7 Jun 2010 at 7:12

GoogleCodeExporter commented 8 years ago

I actually had to look into the source code about the working of the setting. 
So I 
decided to add a visual hint while at it:
http://github.com/rubyripperdev/rubyripper/commit/6b050f60482a25b8ac6472c27f5068
306d47
106b

Original comment by boukewou...@gmail.com on 7 Jun 2010 at 7:18

GoogleCodeExporter commented 8 years ago

Well that was fun:

Ripping track 1
Expected filesize for track 1       is 22889708 bytes.
Free disk space is 168450240 MB
Minutes ripping is 0.000406116666666667.
cdparanoia [.0]-[.9731] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track1_1.wav" 2>&1
Minutes ripping is 8.5337622.
cdparanoia [.0]-[.9731] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track1_2.wav" 2>&1
Adding track 1 (mp3) to the queue..
/home/maciek/aux-git/rubyripper/rr_lib.rb:2381:in `mp3': undefined method 
`force_encoding' for "":String (NoMethodError)
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2283:in `doMp3'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2180:in `encodeTrack'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2142:in `startEncoding'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2141:in `initialize'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2141:in `new'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2141:in `startEncoding'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2134:in `each'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2134:in `startEncoding'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2126:in `addTrack'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:1826:in `ripTrack'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:1796:in `ripTracks'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:1792:in `each'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:1792:in `ripTracks'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:1786:in `initialize'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2478:in `new'
    from /home/maciek/aux-git/rubyripper/rr_lib.rb:2478:in `startRip'
    from bin/bin/rrip_gui:305:in `do_rip'
    from bin/bin/rrip_gui:296:in `initialize'
    from bin/bin/rrip_gui:296:in `new'
    from bin/bin/rrip_gui:296:in `do_rip'
    from bin/bin/rrip_gui:288:in `start_rip'
    from bin/bin/rrip_gui:90
    from bin/bin/rrip_gui:1484:in `call'
    from bin/bin/rrip_gui:1484:in `main'
    from bin/bin/rrip_gui:1484

Original comment by m.sakre...@gmail.com on 8 Jun 2010 at 2:04

GoogleCodeExporter commented 8 years ago

Ok, pulled and I no longer get the crash:

Expected filesize for track 1       is 22802684 bytes.
Free disk space is 168433736 MB
Minutes ripping is 0.000376383333333333.
cdparanoia [.37]-[.9694] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track1_1.wav" 2>&1
Minutes ripping is 1.18836843333333.
cdparanoia [.37]-[.9694] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track1_2.wav" 2>&1
Adding track 1 (mp3) to the queue..
command = lame -V 2 --id3v2-only --tl "Doubt" --ty "1991" --tg "Rock" --tv 
TXXX=DISCID="88099f0c" --ta "Jesus Jones" --tt "Trust Me" --tn 1/12 
"/home/maciek/mp3/temp_sr0/track1_1.wav" "/home/maciek/mp3/Jesus Jones (1991) 
Doubt/01 - Trust Me.mp3" 2>&1
Removing track 1 (mp3) from the queue..
Inside the finished function

However, based on this, it seems like the span is being calculated incorrectly, 
no? If the length of the track is 9695 sectors, and it starts at [.37], then 
[.37]-[.9694] would cut off sectors from the end, right?

Original comment by m.sakre...@gmail.com on 8 Jun 2010 at 2:29

GoogleCodeExporter commented 8 years ago

By the way, the last rip does *sound* right (but there's a couple of seconds of 
silence at the end anyway).

Original comment by m.sakre...@gmail.com on 8 Jun 2010 at 2:52

GoogleCodeExporter commented 8 years ago

I think you're comment at 17 is right. To be sure, please show what the output 
of ripping track 2 is.

Original comment by boukewou...@gmail.com on 9 Jun 2010 at 5:30

Changed state: Accepted

GoogleCodeExporter commented 8 years ago

I get the following:

Ripping track 1
Expected filesize for track 1       is 22802684 bytes.
Free disk space is 168456424 MB
Minutes ripping is 0.000374466666666667.
cdparanoia [.37]-[.9694] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track1_1.wav" 2>&1
Minutes ripping is 1.20294195.
cdparanoia [.37]-[.9694] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track1_2.wav" 2>&1
Adding track 1 (mp3) to the queue..
Ripping track 2
Expected filesize for track 2       is 38074220 bytes.
command = lame -V 2 --id3v2-only --tl "Doubt" --ty "1991" --tg "Rock" --tv 
TXXX=DISCID="88099f0c" --ta "Jesus Jones" --tt "Trust Me" --tn 1/12 
"/home/maciek/mp3/temp_sr0/track1_1.wav" "/home/maciek/mp3/Jesus Jones (1991) 
Doubt/01 - Trust Me.mp3" 2>&1
Free disk space is 168433492 MB
Minutes ripping is 5.20237485.
cdparanoia [.9732]-[.16187] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track2_1.wav" 2>&1
Removing track 1 (mp3) from the queue..
Minutes ripping is 6.22009038333333.
cdparanoia [.9732]-[.16187] -d /dev/cdrom -O 697 
"/home/maciek/mp3/temp_sr0/track2_2.wav" 2>&1
Adding track 2 (mp3) to the queue..
command = lame -V 2 --id3v2-only --tl "Doubt" --ty "1991" --tg "Rock" --tv 
TXXX=DISCID="88099f0c" --ta "Jesus Jones" --tt "Who? Where? Why?" --tn 2/12 
"/home/maciek/mp3/temp_sr0/track2_1.wav" "/home/maciek/mp3/Jesus Jones (1991) 
Doubt/02 - Who Where Why.mp3" 2>&1
Removing track 2 (mp3) from the queue..
Inside the finished function

That doesn't look right, but the track 2 rip sounds fine. Trying this manually 
through cdparanoia, I see:

maciek@albatross:~/aux-git/rubyripper$ cdparanoia [.9732]-[.16187] -d 
/dev/cdrom -O 697 out.wav 2>&1
cdparanoia III release 10.2 (September 11, 2008)

Ripping from sector    9732 (track  1 [2:09.19])
      to sector   25919 (track  2 [3:35.61])

Which would explain it. For some reason, cdparanoia seems to be ignoring the 
span argument, and deciding on its own.

Original comment by m.sakre...@gmail.com on 10 Jun 2010 at 3:51

GoogleCodeExporter commented 8 years ago

The cdparanoia command is always confusing me. It actually works as:
[.startsector] - [.lenght sectors to rip].

So for track 1, you should interpret the command as:
ripping from sector 37 to (9694 + 37)

For track 2, you should interpret the command as:
ripping from sector 9732 to (16187 + 9732)

It would seem one would miss a sector, but I've tested that this isn't so. I 
say, case closed.

Original comment by boukewou...@gmail.com on 17 Jun 2010 at 8:02

Changed state: Fixed

GoogleCodeExporter commented 8 years ago

I've created an automated script using cdparanoia, and I just removed any 
track00 wavs before going on to flac'ing and tagging them.

However, it was messing up my script on _some_ CDs consistently:)

It is solved. I just wanted to add I also have a TSSTCorp scsi device.

Original comment by sigg3...@gmail.com on 22 Oct 2014 at 10:15

rlishtaba / rubyripper

First track sometimes stutters at the beginning #425