Negative drive offset triggers infinite rereads; missing byte-to-sector conversion

[GoogleCodeExporter]

1) Please describe the steps to reproduce the situation:
a. Use a CD drive like my LG Electronics - CD-ROM GCR-8523B with offset -24
b. Try ripping the last track on some music CD's

2) What is the expected output? What do you see instead?
I expect it to work. Instead, ruby crashes with these complaints:
============
/usr/local/lib/site_ruby/1.8/rr_lib.rb:1928:in `>': comparison of String with 0 
failed (ArgumentError)
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1928:in `testFileSize'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1903:in `doNewTrial'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1870:in `main'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1870:in `times'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1870:in `main'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1830:in `ripTrack'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1802:in `ripTracks'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1798:in `each'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1798:in `ripTracks'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:1792:in `initialize'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:2535:in `new'
        from /usr/local/lib/site_ruby/1.8/rr_lib.rb:2535:in `startRip'
        from /usr/bin/rrip_gui:305:in `do_rip'
        from /usr/bin/rrip_gui:296:in `initialize'
        from /usr/bin/rrip_gui:296:in `new'
        from /usr/bin/rrip_gui:296:in `do_rip'
        from /usr/bin/rrip_gui:1372:in `initialize'
        from /usr/bin/rrip_gui:1485:in `call'
        from /usr/bin/rrip_gui:1485:in `main'
        from /usr/bin/rrip_gui:1485
============
I fix this by adding a type conversion as follows to line 1928 in the file
  /usr/local/lib/site_ruby/1.8/rr_lib.rb
as follows:
  OLD:  elsif @settings['offset'] > 0 && (track == "image" || track == @settings['cd'].audiotracks)
  NEW:  elsif @settings['offset'].to_i > 0 && (track == "image" || track == @settings['cd'].audiotracks)

In my example, the offset is negative, so I land in the code block where
"Some sectors are missing". But the number of missing *bytes* is shown
instead of the number of missing *sectors*: line 1934 says
  puts "Some sectors are missing for track #{track} : #{sizeDiff} sector(s)"
but in fact the number of missing sectors should be #{sizeDiff / 2352},
like on line 1927.

And after all this, my value of sizeDiff is exactly 2352, so the temporary file
gets deleted and the program goes back and tries to read it again. It tried many
times before I stopped it manually.

3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?

This is rubyripper 0.6.1 running on Ruby 1.9.1 in Ubuntu 11.10.

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.

I thought 0.6.1 was the "latest & greatest". Whoever reads this can check
for themselves by referring to the precise line numbers quoted above.

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.

This does not happen with all discs. I have seen in 2 cases of 5 tried
so far. One problem case (details below) has details shown at
http://musicbrainz.org/release/4115e2d2-27e8-4a7c-b43e-47b1381409ae

On my own machine, the requested report is as follows:

cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    18070 [04:00.70]        0 [00:00.00]    no   no  2
  2.    13670 [03:02.20]    18070 [04:00.70]    no   no  2
  3.    19145 [04:15.20]    31740 [07:03.15]    no   no  2
  4.    23405 [05:12.05]    50885 [11:18.35]    no   no  2
  5.    24872 [05:31.47]    74290 [16:30.40]    no   no  2
  6.    22580 [05:01.05]    99162 [22:02.12]    no   no  2
  7.    15368 [03:24.68]   121742 [27:03.17]    no   no  2
  8.    13242 [02:56.42]   137110 [30:28.10]    no   no  2
  9.    16915 [03:45.40]   150352 [33:24.52]    no   no  2
 10.    20155 [04:28.55]   167267 [37:10.17]    no   no  2
 11.    25735 [05:43.10]   187422 [41:38.72]    no   no  2
TOTAL  213157 [47:22.07]    (audio only)

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?

I'd like to be able to rip the disc indicated above, and others. 
Having the program crash instead of ripping, or enter an infinite
loop instead of completing the last track, reduces throughput
dramatically. I could go back to "abcde", but the dream of a 
bit-for-bit perfect rip appeals to my sense of idealism.

Please provide any additional information below. The more useful
information provided, the sooner the issue will be fixed.

Original issue reported on code.google.com by philip.l...@gmail.com on 31 Oct 2011 at 6:22

• Blocking: #556

[GoogleCodeExporter]

Sorry, I made a typo above. I'm using ruby 1.9.1, and the version number 
appears in the path to the rubyrip library I was looking at. The correct file 
path is
   /usr/local/lib/site_ruby/1.9.1/rr_lib.rb

Original comment by philip.l...@gmail.com on 31 Oct 2011 at 6:24

[GoogleCodeExporter]

Original comment by boukewou...@gmail.com on 9 Jan 2013 at 10:51

• Now blocking: #556