Excessive time between ripping tracks

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Rip CD
2.  rr finishes the 2nd trial of a track... then 10-15 minutes later goes
on to the next track.

Please use labels and text to provide additional information.
Drive and CPU are inactive... not sure what is the cause of the delay.

Happening with rr git Mon Aug 24 20:32:07 2009 +0200 
12ed4b76c8f1a98043b063b5cd6b33f9b09260d5

Original issue reported on code.google.com by mordbr...@gmail.com on 27 Aug 2009 at 3:02

[GoogleCodeExporter]

Thanks, kimtiede, you solved my problem! I'm glad to have my Rubyripper back 
for now. Hopefully there'll be less involved way to make it work soon.

Original comment by thuerrsc...@gmail.com on 2 Oct 2010 at 2:06

[GoogleCodeExporter]

Instructions from kintiede, Comment 48, Worked for me.
Thanks, RubyRipper is fast again from the GUI.

Original comment by michael....@gmail.com on 26 Oct 2010 at 7:39

[GoogleCodeExporter]

I have the same issue with rubyripper
I tried the method described, (comment 48 + 50), but still, I have problems

this is the error I'm having when I try to execute rubyripper (either the cli 
or the gtk2.0):

.rvm/gems/ruby-1.9.1-p378/gems/locale-2.0.5/lib/locale.rb:239:in 
`collect_candidates': undefined method `size' for nil:NilClass (NoMethodError)
        from /home/delbianc/.rvm/gems/ruby-1.9.1-p378/gems/locale-2.0.5/lib/locale.rb:222:in `candidates'
        from /home/delbianc/.rvm/gems/ruby-1.9.1-p378/gems/gettext-2.1.0/lib/gettext/runtime/textdomain_manager.rb:78:in `each_textdomains'
        from /home/delbianc/.rvm/gems/ruby-1.9.1-p378/gems/gettext-2.1.0/lib/gettext/runtime/textdomain_manager.rb:102:in `translate_singluar_message'
        from /home/delbianc/.rvm/gems/ruby-1.9.1-p378/gems/gettext-2.1.0/lib/gettext.rb:128:in `gettext'
        from ./rubyripper_gtk2.rb:67:in `create_buttonbox'
        from ./rubyripper_gtk2.rb:50:in `initialize'
        from ./rubyripper_gtk2.rb:1484:in `new'
        from ./rubyripper_gtk2.rb:1484:in `<main>'

any idea of what kind of problem it could be?
(ruby-1.9.1-p378, rubyripper-0.6.0)

thanks

Original comment by vieri.de...@gmail.com on 3 Nov 2010 at 1:02

[GoogleCodeExporter]

Tried the git repository yet?

Original comment by mordbr...@gmail.com on 3 Nov 2010 at 9:49

[GoogleCodeExporter]

So, what is the current status of this bug? Is it a ruby1.8 bug? Is it reported 
there?

It don't seem to be related to any bugs mentioned here. None of them does 
mention such big time overheads like this bug. However I do think it is in ruby 
or ruby-gnome2.

I filled up this report at ubuntu, for the matter:
https://bugs.launchpad.net/ubuntu/+source/ruby-gnome2/+bug/670743

Original comment by pedro.pe...@gmail.com on 4 Nov 2010 at 3:13

[GoogleCodeExporter]

I've tried using rubyripper from the git repository as well
but I'm experiencing the very same problems

Original comment by vieri.de...@gmail.com on 11 Nov 2010 at 3:17

[GoogleCodeExporter]

This issue is driving me REALLY, REALLY crazy!
Rubyripper is fine, really, but COMPARING 2 rips (wav) against each other is 
WAYYYYY to slow - AND does not use any CPU at all!

This issue seems to be at least 2 years old - is anybody actually caring for 
Rubyripper anymore??

I can definitely say it starts after the message "Analysiere Datei auf nicht 
übereinstimmende Teilstücke" (in German) - there is a loop in Ruby source 
where, simply put, the two wav rips are compared.
This takes longer than encoding the same wav as mp3 - and that simply is 
impossible! It is way easier to compare two byte arrays for equality than to 
encode audio to mp3!

Can anybody who knows Ruby pleeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeease FIX 
this???

If I on the latest Intel Core i7 with max 8 cores using hyperthreading am NOT 
able to rip a CD as one WAV file because of this, there's something deeply 
wrong!

Please FIX!!!!

Original comment by olaf.got...@gmail.com on 25 Jun 2011 at 3:51

[GoogleCodeExporter]

any traction here?

Original comment by robin.bl...@gmail.com on 13 Jul 2011 at 2:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

These directions with slight modifications worked for me on Ubuntu 11.04 amd64
http://code.google.com/p/rubyripper/issues/detail?id=348#c48

My steps looked like this (since the latest versions of ruby have a bug):

$ rvm install ruby-1.9.1-p378
$ rvm --default ruby-1.9.1-p378
$ gem install gettext
$ gem install gtk2

Original comment by cham...@gmail.com on 19 Jul 2011 at 5:49

[GoogleCodeExporter]

Thanks for the advice that Ruby is the cause for this bug!

Now that I installed Ruby 1.9.2 on my Ubuntu Natty I got a new problem: I 
cannot get the GUI to run anymore! Missing library ruby-gtk2!!!
This seems to be another problem...

Say - what the heck is wrong with this strange Ruby-World????????

I need to get the GUI running, the CLI is of NO help at all as my primary goal, 
to rip CDs in disc-at-once mode is NOT AVAILABLE in the CLI (or I cannot find 
it...)

Because I want DAO rips I was annoyed by the huge time it takes to compare 
chunks! With single tracks it was slow, but it worked... 

Now I am no step further... :-((((

Original comment by olaf.got...@gmail.com on 24 Jul 2011 at 6:02

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is a problem for me on Fedora 15. And the length that this has been a 
problem is pretty insane, especially considering the severity. I guess there is 
no more development on this project. Thank you for at least taking it this far. 
Since there are no alternatives in Linux I guess that leaves me waiting about 
an hour for each cd to rip. At least it works, slowly. I really hope its not a 
dead project.

Original comment by dino...@gmail.com on 28 Jul 2011 at 4:57

[GoogleCodeExporter]

Hellllooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!

Anybody interested in making many people happy here??
Please, what is the matter with rrip and/or ruby? Does it suck so much that 
nobody is able to simply help us in this ever-lasting bug???

ANY help is appreciated quite a lot!!

Original comment by olaf.got...@gmail.com on 2 Sep 2011 at 4:08

[GoogleCodeExporter]

The command line interface for RubyRipper is very good. I share your sentiment 
about (and frustration at) the long-lived nature of this problem but in the 
meantime, I just use rrip_cli from a terminal.

Open up a terminal, type rrip_cli and then follow the prompts it gives you. 
Ripping an entire audio CD is the default so you just need to press enter a few 
times. The bug only affects the GUI so this is fast and easy.

Original comment by adamnf...@gmail.com on 2 Sep 2011 at 4:12

[GoogleCodeExporter]

Well, I think you got me wrong here:

what I need is disc-at-once ripping, ONE file for the whole CD, no tracks.
Is THAT really the default for the cli version? I doubt it...

Can you help me to get to that switch that I only found on the gui so far??

BTW: thank you for the reply! :)

Original comment by olaf.got...@gmail.com on 2 Sep 2011 at 4:16

[GoogleCodeExporter]

You can also change your settings through the cli version and IIRC you can set 
that option.

Original comment by nickbr...@gmail.com on 2 Sep 2011 at 4:39

[GoogleCodeExporter]

Please, please, be more precise! I can't follow such vague explanations! (what 
is IIRC???)

I searched the whole thing, did not find anything even close to DAO. Exactly 
what numbers (the options in the cli version) do I have to go through to reach 
the DAO settings?? It should be really, really easy to tell me how to do it!

Thank you!!

Original comment by olaf.got...@gmail.com on 2 Sep 2011 at 4:42

[GoogleCodeExporter]

set image=true in path/to/rubyripper/settings

Original comment by robin.bl...@gmail.com on 2 Sep 2011 at 5:09

[GoogleCodeExporter]

No luck here with Ruby >= 1.9 and/or 0.6.0. But after a lot of trial and error,
I finally found a combination of the involved components to get at least 0.5.7
to work on my Debian Squeeze system. I used 0.5.7 on Lenny before, so now I have
the same functionality on Squeeze and I'm happy. ;)

sudo aptitude install curl bison build-essential zlib1g-dev libssl-dev 
libreadline5-dev libxml2-dev git-core
sudo aptitude install libgtk2.0-dev
bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

add to .bashrc:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM 
into a shell session *as a function*

rvm install ruby-1.8.7-p174
rvm --default ruby-1.8.7-p174
gem install gtk2
wget http://downloads.sourceforge.net/ruby-gnome2/ruby-gnome2-all-0.19.4.tar.gz
tar xfzv ruby-gnome2-all-0.19.4.tar.gz
cd ruby-gnome2-all-0.19.4/
ruby extconf.rb --ruby=`which ruby`
make
make install

Notes:

1. I tried the newest version of ruby-gnome2-all first (1.0.0 at the time of
writing), but it did not work.

2. I skipped the 'gem install gettext'. It installs, and I can execute rgettext.
But Rubyripper does not find it no matter what I do. I can live with an English
GUI.

Original comment by swedishc...@googlemail.com on 2 Sep 2011 at 7:16

[GoogleCodeExporter]

@robin: Where do I find the settings file??
I install rrip_cli to /usr/bin and of course there's no such file as 
/usr/bin/settings!!

And why is that switch only available in a settings file and not in the menus??

Original comment by olaf.got...@gmail.com on 3 Sep 2011 at 10:06

[GoogleCodeExporter]

In latest & greatest code all menu options are also available in the cli. 
However, there are other problems still to fix before this is usable. 
Previously the cli was sort of 2nd rate citizen.

If you have problems with the gui to rip, I recommend to set your settings in 
the gui. And use the cli for the actual ripping. Your settings of the gui will 
be respected by the cli.

Please only add new comments if it contributes to a possible solution. Each 
comment will be send to all people that marked this issue. And we don't want to 
spam everyone, now do we?

Original comment by boukewou...@gmail.com on 3 Sep 2011 at 10:25

[GoogleCodeExporter]

Hi,

The attached patch fixes the issue for me.  Based on the 0.6.0 released source.

Two important parts to the fix,
- use IO.sysread instead of File.read, not sure why, but this makes quite a 
difference
- in analyzeFiles(), first attempt to read and compare a large number of 
audiocd sectors at a time.  only drop back to one at a time if an error is 
detected.  this does increases memory usage.

There is also a small bugfix included in this patch... if more than two rips 
were being compared, then the error array could get messed up as the file 
positions were not updated correctly due to short-circuit && (i assume Ruby 
works the same was as C here???).

Could someone who has more experience with Ruby double check this please?  Not 
my usual language!

Some info on my setup just in case this patch doesn't fix things for other 
people,
$ ruby --version
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
$ uname -a
Linux hutcho-M17x 2.6.38-11-generic #50-Ubuntu SMP Mon Sep 12 21:17:25 UTC 2011 
x86_64 x86_64 x86_64 GNU/Linux

First time i've used Rubyripper, other than this annoyance, looks like a really 
good product.  Thankyou!

- Luke

Original comment by hutcho.l...@gmail.com on 1 Oct 2011 at 7:38

Attachments:

• patch

[GoogleCodeExporter]

Nice work there, never thought this was causing it :)

However I do not agree there is a problem with the '&&' part, the logic is:
-> for each file to compare with next
-> for each sector
-> if sector doesn't match with next file
-> for all files available store the bytes for this position
-> for next file to compare skip the reading for this position

Code is a bit messy to read as it is, so I am not surprised you missed it.

Is the splitting really necessary to larger chunks? That solution is not really 
nice. I've tried to change the logic to use FileUtils to compare the complete 
files. And only if not matched the sectors are compared. Maybe the change to 
IO.sysread is enough?

Please try this sample release to see if it fixes your problems.

Original comment by boukewou...@gmail.com on 1 Oct 2011 at 11:36

[GoogleCodeExporter]

Hi!

Sorry, i was a bit vague in my description of the other bug.  Fairly subtle,

The previous version of the loop was

(@reqMatchesAll - 1).times do |time|
    index = 0
    files.each{|file| file.pos = 44}
    while index + 44 < @settings['cd'].getFileSize(track)
        if !@errors.key?(index) && files[0].read(2352) != files[time + 1].read(2352)
            files.each{|file| file.pos = index + 44}
                @errors[index] = Array.new
                files.each{|file| @errors[index] << file.read(2352)}
            end
        index += 2352
    end
end

Say @reqMatchesAll is 3, there are two audiocd sectors per file, and there was 
a read error from the CD in the first sector of file 0.

After the first outer loop iteration, @errors[0] will be a copy of the first 
2352 bytes of each of the files.  All good so far...

On the second iteration of the outer loop, all the files seek back to 44.  
Because @errors has a key for 0, files 0 and 2 will not be read, so on the 
second iteration of the inner loop, the files are still seeked to 44, but index 
is now 2352.  This means that the bad data in the first sector of file 0 will 
be read again, and mismatch with the first sector of file 2.  So at the end, 
@errors[2352] has been incorrectly set to a copy of the first sector from each 
file, when there really should be no value for 2352.

OR... maybe theres something i'm just missunderstanding something in Ruby :)

Tried 0.6.1a, unfortunately it is back to very slow again.  Put a benchmark 
around the FileUtils.compare_file call,

    $ rrip_gui
    ....
     (== PROGRESS == [                              | 022351 00 ] == :^D * ==)

    Done.

          user     system      total        real
      4.420000   2.010000   6.430000 (520.641195)
    Adding track 1 (mp3) to the queue..

Seems the Ruby 1.8.7 implementation has the same problem in there as well :-(

Agree that my change was not as neat as it probably could have been.  
IO.sysread unforunately wasn't enough on its own, and didn't want to burn up to 
2x 870 MiB if the entire CD was being ripped in one go.  Was unaware of 
FileUtiles.compare_file, otherwise would have tried that.  Atm it is quite late 
in my timezone here, so if i try chaning the code now, i'll probably introduce 
a bug.  I can try to make it nicer without sacrificing any speed tomorrow.

Original comment by hutcho.l...@gmail.com on 1 Oct 2011 at 3:17

[GoogleCodeExporter]

This patch (apply to the 0.6.01a code), keeps the speed improvement and is a 
lot easier to follow than my first patch.  Makes a few additional calls to 
IO.sysseek, but the comparison is still "instantaneous" relative to the ripping 
and MD5.  What do you think?

Original comment by hutcho.l...@gmail.com on 2 Oct 2011 at 12:05

Attachments:

• patch

[GoogleCodeExporter]

Actually this one is better (just fixed up a comment which was no longer valid).

Original comment by hutcho.l...@gmail.com on 2 Oct 2011 at 12:09

Attachments:

• patch

[GoogleCodeExporter]

Can I have someone else to confirm this fixes the issue? If so, I'll make this 
the official 0.6.1, as many people have starred this one.

Original comment by boukewou...@gmail.com on 2 Oct 2011 at 9:42

[GoogleCodeExporter]

Could you please push an extra branch with this fix to the Git repository to 
make it easy to test for the Git users?

Original comment by pm.deb...@googlemail.com on 2 Oct 2011 at 10:18

[GoogleCodeExporter]

I already did. After cloning the git repository on Google code, you can use:
git checkout stable

Original comment by boukewou...@gmail.com on 2 Oct 2011 at 10:54

[GoogleCodeExporter]

Thank you.I still used the repository at GitHub and therefore did not get these 
updates. I will report back next week if the changes worked for me.

Original comment by pm.deb...@googlemail.com on 2 Oct 2011 at 11:08

[GoogleCodeExporter]

An important bug was fixed for this release, please give the new version a spin.

Original comment by boukewou...@gmail.com on 8 Oct 2011 at 10:36

[GoogleCodeExporter]

I hereby close this bug. A new 0.6.1 release can be found at the downloads.

Original comment by boukewou...@gmail.com on 13 Oct 2011 at 9:16

• Changed state: Fixed

[GoogleCodeExporter]

I guess I speak for many users when I say: thank you both very much for finally 
fixing this problem :) Just tried it with Ubuntu Natty, works like a charm!

Original comment by dietr...@gmail.com on 13 Oct 2011 at 9:49

[GoogleCodeExporter]

ditto: thanks for all the work and the fix for this long standing issue.

Il giorno gio, 13/10/2011 alle 21.50 +0000, rubyripper@googlecode.com ha
scritto: 

Original comment by in0g...@in-giro.org on 13 Oct 2011 at 11:28

[GoogleCodeExporter]

Thank you very much for this fix!

Original comment by nickbr...@gmail.com on 14 Oct 2011 at 12:34

[GoogleCodeExporter]

OK, I downloaded the patch. Now what do I do to install it?

Original comment by TeamMuti...@gmail.com on 29 Jan 2012 at 11:31

[GoogleCodeExporter]

At least on 64bit Precice Pangolin Ubuntu 12.04 this version seems to work:
http://www.ubuntuupdates.org/package/getdeb_apps/precise/apps/getdeb/rubyripper
(0.6.2-1~getdeb1), whereas the one from here for Lucid does not:
repository ppa:aheck/ppa

Original comment by vesa.iko...@gmail.com on 1 May 2012 at 1:41