Problem ripping last track on a disc

[GoogleCodeExporter]

Just want to say that other than this one hiccup, this tool works great. 
Thanks much for the effort put into it so far.

What steps will reproduce the problem?
1. Put in a disc with multiple audio tracks
  set to rip with suggested offset for device
  all chunks:2/erroneous chunks:2/max trials:5
  cdparanoia options: (none)
  eject cd when finished (on); other options off
  codecs - Lame mp3: -V 0 (others off)
  no playlist
  no volume standardization
  freedb defaults

2. Select any combination of tracks to rip that includes the last track

3. Ripping works as expected until the last track, which gives the error
message below.  The log never gets past the initial trial, e.g.:

STATUS

Starting to rip track 18, trial #1

Again, everything works fine until the last track.

What is the expected output? What do you see instead?

Expect to see wav file in temp directory that is then used to create mp3
via lame.  Instead I see an error message that says:

"Cdparanoia doesn't output wav files.  Check your settings please."

1) What version of rubyripper are you using? On what operating system?
0.5.4 on Ubuntu 8.10

2) Are you using the gtk2 or the commandline interface?
gtk2

3) Is the problem gone with the default settings? If so, please attach your
settings file ($HOME/.rubyripper/settings).
Don't think so, but will attach settings just in case.

Please provide any additional information below.

Original issue reported on code.google.com by expatexi...@gmail.com on 26 Jan 2009 at 10:14

Attachments:

• settings

[GoogleCodeExporter]

What is the result after you feed cdparanoia (with the same disc) in a terminal:
-> cdparanoia -0 -472 18

I suspect cdparanoia will take forever here as well. If so, there are two 
options I
see here:
1) Your drive offset is wrong
2) Cdparanoia has a bug

However, it might also be related to the fact that rubyripper doesn't use 
cdparanoia
in track modus, but in sector modus. I can give you the exact command if I have 
the
output of => cdparanoia -Q

Original comment by rubyripp...@gmail.com on 27 Jan 2009 at 10:27

• Changed state: Accepted

[GoogleCodeExporter]

Wow, thanks for getting back to me so quickly.

Here is the output of
-> cdparanoia -O -472 -18

bruce@office:~$ cdparanoia -O -472 18
cdparanoia III release 10.0 (June 10, 2008)

Ripping from sector  295792 (track 18 [0:00.00])
      to sector  310823 (track 18 [3:20.31])

outputting to cdda.wav

 (== PROGRESS == [                          +  +| 310823 00 ] == :^D * ==)   

Done.

It looks like it did output a .wav file:

bruce@office:~$ ls -al cdda.wav
-rw-r--r-- 1 bruce bruce 35355308 2009-01-27 20:25 cdda.wav

Here is the output of
=> cdparanoia -Q

bruce@office:~$ cdparanoia -Q
cdparanoia III release 10.0 (June 10, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    14819 [03:17.44]        0 [00:00.00]    no   no  2
  2.    17936 [03:59.11]    14819 [03:17.44]    no   no  2
  3.    24794 [05:30.44]    32755 [07:16.55]    no   no  2
  4.    18779 [04:10.29]    57549 [12:47.24]    no   no  2
  5.    16972 [03:46.22]    76328 [16:57.53]    no   no  2
  6.    20766 [04:36.66]    93300 [20:44.00]    no   no  2
  7.    15025 [03:20.25]   114066 [25:20.66]    no   no  2
  8.    18757 [04:10.07]   129091 [28:41.16]    no   no  2
  9.    21662 [04:48.62]   147848 [32:51.23]    no   no  2
 10.    16809 [03:44.09]   169510 [37:40.10]    no   no  2
 11.    16820 [03:44.20]   186319 [41:24.19]    no   no  2
 12.    12409 [02:45.34]   203139 [45:08.39]    no   no  2
 13.    17141 [03:48.41]   215548 [47:53.73]    no   no  2
 14.    14401 [03:12.01]   232689 [51:42.39]    no   no  2
 15.    19989 [04:26.39]   247090 [54:54.40]    no   no  2
 16.    15541 [03:27.16]   267079 [59:21.04]    no   no  2
 17.    13173 [02:55.48]   282620 [62:48.20]    no   no  2
 18.    15032 [03:20.32]   295793 [65:43.68]    no   no  2
TOTAL  310825 [69:04.25]    (audio only)

Do I need to add something to the cdparanoia settings in rubyripper?  Currently 
I
have the cd offset configured in the top part of the secure ripping preferences 
tab,
but I left the pass cdparanoia options text box blank.

Original comment by expatexi...@gmail.com on 28 Jan 2009 at 1:59

[GoogleCodeExporter]

I find this somewhat strange results. As you can see the last sector of track 18
should be the length (15032 sectors) + the start (295793 sectors) = 310825 
sectors.

When looking at the output of just asking for track 18, the start sector is 
295792
and up to 310823.

I'll investigate this further once I have more time. 

Meanwhile:
* please confirm there are no problems ripping track 18 with rubyripper using an
offset of zero.
* please give the output of manual cdparanoia without the -O switch (just 
cdparanoia 18)

Original comment by rubyripp...@gmail.com on 28 Jan 2009 at 5:22

[GoogleCodeExporter]

Sorry, I didn't realize I had introduced the problem by using the offset 
setting. 
There indeed were no problems using an offset of 0.  I attached the log.  
Should I
just leave the offset at 0 and call it a day?

I did double check the setting reported for my cdrom, Toshiba SD-M1612, and 
-472 is
what is listed, per 372 users.  Maybe I have different firmware than most?

Here is the output of
-> cdparanoia 18

bruce@office:~$ cdparanoia 18
cdparanoia III release 10.0 (June 10, 2008)

Ripping from sector  295793 (track 18 [0:00.00])
      to sector  310824 (track 18 [3:20.31])

outputting to cdda.wav

 (== PROGRESS == [                              | 310824 00 ] == :^D * ==)   

Done.

Thanks for your help.

Original comment by expatexi...@gmail.com on 28 Jan 2009 at 6:34

Attachments:

• ripping.log

[GoogleCodeExporter]

Don't get me wrong. The offset may well be right. In fact it's unlikely to 
differ
from those other users.

However, cdparanoia is acting in an unexpected manner to cope with the offset 
thing.
In my humble opinion it shouldn't change the sectors it should rip when using an
offset. The offset should be taken care for, after the sectors are given.

So how on earth is is possible that with a negative offset of 472 the sectors 
are
changed with minus 1? That's the question.

Original comment by rubyripp...@gmail.com on 28 Jan 2009 at 9:06

[GoogleCodeExporter]

Idea:
What is the output when you query the disc with: cdparanoia -O -475 -Q

Perhaps this changes the table of contents info.

Original comment by rubyripp...@gmail.com on 31 Jan 2009 at 10:57

[GoogleCodeExporter]

Here is the output:

bruce@office:~$ cdparanoia -O -475 -Q
cdparanoia III release 10.0 (June 10, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    14819 [03:17.44]        0 [00:00.00]    no   no  2
  2.    17936 [03:59.11]    14819 [03:17.44]    no   no  2
  3.    24794 [05:30.44]    32755 [07:16.55]    no   no  2
  4.    18779 [04:10.29]    57549 [12:47.24]    no   no  2
  5.    16972 [03:46.22]    76328 [16:57.53]    no   no  2
  6.    20766 [04:36.66]    93300 [20:44.00]    no   no  2
  7.    15025 [03:20.25]   114066 [25:20.66]    no   no  2
  8.    18757 [04:10.07]   129091 [28:41.16]    no   no  2
  9.    21662 [04:48.62]   147848 [32:51.23]    no   no  2
 10.    16809 [03:44.09]   169510 [37:40.10]    no   no  2
 11.    16820 [03:44.20]   186319 [41:24.19]    no   no  2
 12.    12409 [02:45.34]   203139 [45:08.39]    no   no  2
 13.    17141 [03:48.41]   215548 [47:53.73]    no   no  2
 14.    14401 [03:12.01]   232689 [51:42.39]    no   no  2
 15.    19989 [04:26.39]   247090 [54:54.40]    no   no  2
 16.    15541 [03:27.16]   267079 [59:21.04]    no   no  2
 17.    13173 [02:55.48]   282620 [62:48.20]    no   no  2
 18.    15032 [03:20.32]   295793 [65:43.68]    no   no  2
TOTAL  310825 [69:04.25]    (audio only)

I didn't diff it, but with a quick look it seems to be the same as
-> cdparanoia -Q

Original comment by expatexi...@gmail.com on 31 Jan 2009 at 2:01

[GoogleCodeExporter]

Just wanted to let you know that I have the same problem as well using a Toshiba
SD-M1712 dvdrom drive, which happens to use the same offset of -472.  This 
doesn't
happen when I use the other dvd drive that I have on my system (which uses a
different offset).

Original comment by jhoang...@gmail.com on 2 Feb 2009 at 11:29

[GoogleCodeExporter]

It's probably just a crazy idea, but what happens when you set an offset of 
-471?
Does it still hang on the last track in Rubyripper?

Original comment by rubyripp...@gmail.com on 3 Feb 2009 at 10:09

[GoogleCodeExporter]

jhoang -- Thanks for the input... interesting that the problem also happens with
another Toshiba drive from the same series.  Earlier this week I did finally 
realize
that I can just as well use my Pioneer dvd-rw; it works fine with the offset 
listed
for it.

rubyripperdev -- Thanks for the suggestion.  I tried with -471 and -450 but got 
the
same output.  I can use my other dvd drive to rip, but am happy to provide more 
test
information as long as you want to pursue a solution.

Original comment by expatexi...@gmail.com on 4 Feb 2009 at 2:04

[GoogleCodeExporter]

If the output changes with different drives than I tend to think cdparanoia 
doesn't
handle that specific drive too well. Not a bug rubyripper can do something 
about.

Original comment by rubyripp...@gmail.com on 23 May 2009 at 1:10

• Changed state: WontFix