Difference between revisions of "Rubyripper"
Frodoontop (Talk | contribs) (→Screenshots: Added some links to a few screenshots) |
m (→Correction mechanism: \times) |
||
| Line 29: | Line 29: | ||
The main underlying Philosophy is that an erronous read of an underlying ripper will produce random results. This seems so far to be correct. However, with random results also a chance exists that the same result will still be the wrong result. | The main underlying Philosophy is that an erronous read of an underlying ripper will produce random results. This seems so far to be correct. However, with random results also a chance exists that the same result will still be the wrong result. | ||
<br><br> | <br><br> | ||
| − | If the full 1,000 bytes are erronous, than a false repair seems to be highly unlikely since there are <math>1000 | + | If the full 1,000 bytes are erronous, than a false repair seems to be highly unlikely since there are <math>1000 \times 256</math> possibilities in theory. (As a byte consists of 8 bits, 2<sup>8</sup>=256). This would need an infinite amount of trials to match. The main principle however is, the more trials that are needed, consequently the higher a chance of a false repair. |
<br><br> | <br><br> | ||
| − | Suppose only 3 bytes in a sample of 1000 bytes give random information. This would still mean <math>3 | + | Suppose only 3 bytes in a sample of 1000 bytes give random information. This would still mean <math>3 \times 256</math> possibilities within each of these bytes, really 2 bits could be a problem. This reduces the possibilities to <math>3 \times 2 \times 2 = 12</math> possibilies. So, a false repair still seems to be possible. One has to wonder though: can 3 bytes actually be heard in a wav file that produces 180.000 bytes per second? |
<br><br> | <br><br> | ||
In conclusion: Rubyripper won't guarantee a consequent ''MD5-sum'' on tracks that needed correction. However it will repair any files so that it's impossible to succesfully blind-test with the original. The log file will report any position that needed more than 3 trials, so you can check the position yourself. | In conclusion: Rubyripper won't guarantee a consequent ''MD5-sum'' on tracks that needed correction. However it will repair any files so that it's impossible to succesfully blind-test with the original. The log file will report any position that needed more than 3 trials, so you can check the position yourself. | ||
Revision as of 06:37, 6 August 2006
Contents
Introduction
What is Rubyripper? Rubyripper is a digital audio extraction algorithm that uses cdparanoia or cdda2wav in a sophisticated way to make sure that a CD rip is done succesfully and accurately. It is very similiar to and inspired by EAC. Rubyripper is written in the ruby programming language.
It's currently available for Linux (partial BSD support). OS X will most likely be supported in the near future. The source (same as executable) is published under the GPL license.
- UPDATE: New version 0.2 was released on 4 August 2006.
- UPDATE: New version 0.1.1 was released on 12 February 2006.
- UPDATE: New version 0.1.0 was released on 5 November 2005.
Features
- A GTK2 user interface
- Sophisticated error correction mechanism
- Also a command line interface (CLI) available
- CDDB-info is fetched via the ruby-freedb module
- Info can be edited after fetching
- The codecs supported are FLAC, Vorbis, MP3, and Wav
- Multiple codecs can be used in one run
- Direct offset support
- Detailed logfile creation
- An overview of hard-to-correct positions
- Create m3u playlists
Correction mechanism
Rubyripper correction mechanism goes beyond that of cdparanoia. Every track gets ripped at least twice and is byte compared with the Ruby cmp feature. If any differences are found, each of the 1,000 bytes of the two files is compared. The next trial run looks to see if differing positions or a match can be found. (1,000 bytes is about 0.006 seconds)
The main underlying Philosophy is that an erronous read of an underlying ripper will produce random results. This seems so far to be correct. However, with random results also a chance exists that the same result will still be the wrong result.
If the full 1,000 bytes are erronous, than a false repair seems to be highly unlikely since there are 
possibilities in theory. (As a byte consists of 8 bits, 28=256). This would need an infinite amount of trials to match. The main principle however is, the more trials that are needed, consequently the higher a chance of a false repair.
Suppose only 3 bytes in a sample of 1000 bytes give random information. This would still mean 
possibilities within each of these bytes, really 2 bits could be a problem. This reduces the possibilities to 
possibilies. So, a false repair still seems to be possible. One has to wonder though: can 3 bytes actually be heard in a wav file that produces 180.000 bytes per second?
In conclusion: Rubyripper won't guarantee a consequent MD5-sum on tracks that needed correction. However it will repair any files so that it's impossible to succesfully blind-test with the original. The log file will report any position that needed more than 3 trials, so you can check the position yourself.
Installation
Make sure to have ruby-freedb, ruby-libglade2 and cdparanoia or cdda2wav installed as a minimum. You can optionally choose for Lame, Vorbis or FLAC, depending on the codec you wish to use.
Then download Rubyripper: http://rubyforge.org/frs/?group_id=1284&release_id=6293
Documentation of some of the ripping logic used can be found at: (somewhat dated)
http://rubyforge.org/docman/view.php/1284/310/Rubyripper's%20ripping%20logic.pdf
Currently there isn't an official installer available. Usage from a terminal or console:
cd <download_dir> (Go to the directory where you saved the downloaded archive)tar xfj <filename_download> (Unpack the archive)cd rubyripper-<version> (Move into the just unpacked directory)chmod +x *.rb (Make all .rb files executable)./rubyripper_gtk.rb (Launch gtk2 user interface)./rubyripper_cli.rb (Launch command line user interface)
If Rubyripper doesn't start make sure the dependencies are ok. When launched from a terminal rubyripper should now tell which dependency it's missing.
Screenshots
The theme used in the screenshots is GTK-Qt-theme.
Suggestions for next version
- Try to rip only parts that contain errors to save time
- Erronous parts should be matched more than once
- OS X support. As the only developer I need some help, for I don't have a Mac. A Mac user could help to get the cli-version working. A ruby programmer could help to make the Gui for OS X. I'll be glad to add support for this task.
- Let the user choose which freedb hit he/she will use
Known Bugs
- If the first trial of a track has a different size than the second track, it assumes that the size of the first track is right. We don't know that for sure.
External links
- Rubyripper the official Rubyforge website
- Hydrogenaudio forum thread the first public release of Rubyripper
