Tries to rip data track about rubyripper

[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 [email protected] 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 [email protected] 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 [email protected] 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 <[email protected]> and Xiph.Org

Report bugs to [email protected]
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 [email protected] on 8 Nov 2006 at 8:18

[GoogleCodeExporter]

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

Original comment by [email protected] 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 [email protected] on 9 Nov 2006 at 9:36

• Changed state: Fixed