Tries to rip data track

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load CD that contains data track
2.
3.

What is the expected output? What do you see instead?
with cdparanoia -vQ all tracks except data track are shown.  rr shows all
tracks including the data track

What version of the product are you using? On what operating system?
latest from svn on 20061102 on Debian

Please provide any additional information below.
I guess if somebody is trying to make a perfect backup (including cue
sheet) they'd want the data track ripped.  Otherwise ripping a data track
with cdparanoia does no good. At minimum rr should notify the user which,
if any, tracks are data and not audio.  From there the user can decide if
they want to rip it or not.  Possibly this could be done by comparing the
cddb lookup to the output of cdparanoia -vQ?

Original issue reported on code.google.com by mordbr...@gmail.com on 2 Nov 2006 at 10:12

[GoogleCodeExporter]

Rubyripper currently makes a check for a data track based on the freedb name of 
the
track. If it does find a data track, it will deselect it. 

I didn't know I could use cdparanoia for data track testing. That would be an
improvement indeed. I'll see what I can do.

Original comment by rubyripp...@gmail.com on 3 Nov 2006 at 5:37

• Changed state: Accepted

[GoogleCodeExporter]

I tend to prefer the least reliance on freedb as possible.  Often times data is
wrong, or in my case I don't think the disc found any matches.  When I do 
cdparanoia
-vQ it never shows the data track... in fact I've sometimes not noticed the 
disc has
one until later!  Now sorting the output of that cdparanoia command is another 
issue.
 It seems so inflexible.  Maybe they will improve that now that development has
picked up on it again.

Original comment by mordbr...@gmail.com on 6 Nov 2006 at 7:06

[GoogleCodeExporter]

Well, I have already done some experiments with getting info from cdparanoia 
output. You can find it in the (not yet used) Cuesheet class. The amount of 
tracks 
shouldn't be that difficult to get from it.

The question is, should Rubyripper rely on cdparanoia cd scanning by default? 
This 
would slow down the initial disc scanning. Perhaps I should offer it as an 
option 
in the GUI. One might argue that some intelligence from the user can be 
expected 
with cd's that contain data tracks.

Your opinions please.

Original comment by rubyripp...@gmail.com on 7 Nov 2006 at 11:51

[GoogleCodeExporter]

In my experience looking up with freedb is no quicker than a cdparanoia -vQ.  Of
course maybe it's my connection or freedb is not fully optimized who knows.  My 
real
concern is that anytime something breaks with freedb lookup rubyrip is pretty 
useless
(at least for that disc).  An option to turn not use freedb at all would be 
optimal IMO.

As far as data tracks go I guess intelligence can be expected.  That does not 
always
help.  Started ripping a disc tonight.  About midway through I remembered it 
had a
data track.  Came back and unchecked the data track.  Yet I still got this:

outputting to /Sjø/rr/track16_2.wav

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

Done.

cdparanoia III release 10pre0 (August 29, 2006)
(C) 2006 Monty <monty@xiph.org> and Xiph.Org

Report bugs to paranoia@xiph.org
http://www.xiph.org/paranoia/

Selected span contains non audio tracks.  Aborting.

./rr_lib.rb:345:in `size': No such file or directory - /Sjø/rr/track17_1.wav
(Errno::ENOENT)
        from ./rr_lib.rb:345:in `main'
        from ./rr_lib.rb:342:in `times'
        from ./rr_lib.rb:342:in `main'
        from ./rr_lib.rb:334:in `initialize'
        from ./rr_lib.rb:720:in `new'
        from ./rr_lib.rb:720:in `ripper'
        from ./rr_lib.rb:719:in `each'
        from ./rr_lib.rb:719:in `ripper'
         ... 6 levels...
        from ./rubyripper_gtk2.rb:8:in `to_proc'
        from ./rubyripper_gtk2.rb:351:in `call'
        from ./rubyripper_gtk2.rb:351:in `main'
        from ./rubyripper_gtk2.rb:351

So I really think hoping for intelligence isn't the best for this.  User could 
forget
there is a data track or it may not be noted by freedb.  Or it could be 
unchecked
like in my case.

In my vision (where freedb can be disabled) cdparanoia would do the initial 
scan. 
Then, if the user has freedb option enabled it can get the track information 
from
that.  There are a lot of other issues (getting initial artist / album if freedb
isn't enabled) but I think that would be the best solution.  What do you think?

Original comment by mordbr...@gmail.com on 8 Nov 2006 at 8:18

[GoogleCodeExporter]

Agreed. I'll guess I move my lazy a** then to implement this ;) .

Original comment by rubyripp...@gmail.com on 8 Nov 2006 at 5:42

[GoogleCodeExporter]

Ok, it did take me some time. But there you have it. Update to revision 14 and 
report here how nice this works :D

Original comment by rubyripp...@gmail.com on 9 Nov 2006 at 9:36

• Changed state: Fixed