1 bearbeitet von Lego (Original: 2007-09-21 03:41)

Thema: RubyRipper

Hallo,

ich wollte kurz die CD-Ripper-Software RubyRipper. vorstellen. Das Programm greift auf Cdparanoia zurück, benutzt aber nicht dessen Fehlerkorrektur sondern ein eigenes Verfahren, dass auf dem Vergleich von Hash-Werten basiert (ähnlich EAC oder foobar2000).

http://b-woudstra.speedlinq.nl/screenshots/0.4.1/Preferences1.png

mehr Screenshots

Liste mit Features von der Homepage (übersetzt):

    * Eine GTK2 Benutzeroberfläche
    * Kommandozeilenoberfläche verfügbar
    * Hochentwickelte Fehlerkorrekturmechanismen
    * CDDB Information unterstützung
    * Informationen können nach dem Empfang von CDDB bearbeitet werden
    * Die Unterstützten Codecs sind: FLAC, Vorbis, MP3, and Wav
    * Mehrere Codecs können in einem Lauf verwendet werden
    * Offset unterstützung
    * Detailierte Logdatei erstellung
    * Eine detailierte Übersicht über schwierig zu korrigierende Stellen
    * Erstellt m3u Playlists

Eine Installationsanleitung ist in der Readme enthalten. Im Prinzip muss man ein paar zusätzliche Abhängigkeiten von Hand installieren (Ruby, Codecs etc.) und dann mit Administratorrechten den Befehl "make install" im entpackten Verzeichnis ausführen (unter Ubuntu "sudo make install"). Danach kann das Programm mit dem Befehl "rrip_gui" bzw. "rrip_cli" (für die Commandline Version) gestartet werden.

2 bearbeitet von Lego (Original: 2007-09-21 19:16)

Re: RubyRipper

Vielen Dank für den Bericht hier.

Ich will Linux nutzen und das ist auf jeden Fall für mich eine frohe Botschaft!
Ich habe jedoch nicht die nötige Fachkenntnis um festzustellen ob dieses Programm taugt und rege deshalb an offiziell zu erklären ob man diesen Ripper für Linux empfehlen kann.

lG Jonny

3

Re: RubyRipper

Ich kann das Programm nur empfehlen. Für Linux gibt es sonst nichts vergleichbares. Wenn es eine Windows Portierung gäbe, würde ich es sogar eher als EAC benutzen. Ich finde es einfacher zu konfigurieren, übersichtlicher in der Benutzung und es unterstützt die Verwendung von mehreren Codecs in einem Lauf.

Das Secure Ripping Verfahren ist relativ simpel aber effektiv.

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. A possibility still exists that with randomn results the same result will be wrong.

If the full 1,000 bytes are erronous, than a false repair seems to be highly unlikely since there are 1000 \times 256 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 1,000 bytes give random information. This would still mean 3 \times 256 possibilities within each of these bytes, really 2 bits could be a problem. This reduces the possibilities to 3 \times 2 \times 2 = 12 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.

Quote aus dem Hydrogenaudio.org Wiki

4

Re: RubyRipper

Hallo,

seit Version 0.4.3 spricht Rubyripper außer Englisch auch Deutsch und Niederländisch.

Gruß,
Morfeus

5 bearbeitet von Aki (Original: 2007-09-30 16:57)

Re: RubyRipper

SUPER!

Gibt's denn auch irgendwo eine für normalsterbliche Nicht-Linux-Bastler verständliche Installationsanleitung unter Ubuntu?

6 bearbeitet von Lego (Original: 2007-09-30 17:11)

Re: RubyRipper

Aki,30.09.2007, 16:57 schrieb:

SUPER!

Gibt's denn auch irgendwo eine für normalsterbliche Nicht-Linux-Bastler verständlich Installationsanleitung unter Ubuntu?

Hallo,

ist eigentlich ganz einfach:

- Terminal öffnen
- "svn checkout http://rubyripper.googlecode.com/svn/trunk/rubyripper eingeben
- der Sourcecode wird nun heruntergeladen und innerhalb des aktuellen Verzeichnisses (sollte das Home-Verzeichnis sein) wird automatisch das Verzeichnis "rubyripper" angelegt
- "cd rubyripper" eingeben
- "sudo make install" eingeben
- falls es hier Fehlermeldungen über nicht erfüllte Abhängigkeiten gibt, müssen diese nachinstalliert werden
- wenn dem nicht so ist dann wars das auch schon, Rubyripper sollte im Menu unter Anwendungen -> Unterhaltungsmedien erscheinen

Wenn's Probleme geben sollte einfach hier posten, ich helfe dann...

Gruß,
Morfeus

7 bearbeitet von DAU (Original: 2007-10-19 14:12)

Re: RubyRipper

Hm, eigentlich war es nur Zufall, dass meine Freude über die Existenz eines laut Ankündigung endlich unter Linux nativ laufenden Secure-Rippers etwas getrübt wurde. Dabei hätte mich der Sachverhalt, dass bei Rubyripper Dank des Befehls -Z auf einige Korrekturmechanismen von cdparanoia verzichtet wird, doch ein wenig hellhörig werden lassen sollen. (weiterlesen: What is cdparanoia?) Aber alles der Reihe nach.


Vorgeschichte.

Nach der Lektüre der Vorstellung durch "ilikedirt" besorgte ich mir mit Hilfe von Linux App Finder die halbwegs aktuelle Version 0.4.1 aus dem RareWares-Repository. Die Installation des Debian-Paketes unter Ubuntu 7.04 (Feisty Fawn) gelang ohne Probleme.

Da ich mir einige Zeit zuvor das Musik-Magazin Groove Nr. 108 u.a. auch wegen der beiliegenden CD 17 gekauft hatte, welche einen vom Istanbuler DJ Onur Özer mit LPs erstellten Minimal-Mix über den CD-Player ohne Probleme zum besten gab, benutzte ich letztere für einen Test-Rip mit meinem LG GSA-4040B (Firmware A301), das keinen Cache besitzt. (weiterlesen: [Vergleich] EAC (Windows) vs. cdparanoia (Linux), Oder:sollte trotzdem EAC benutzt werden?) Etwaige Kratzer auf der CD-Oberfläche hatte ich bis dahin noch gar nicht wahrgenommen.
Nach dem abgeschlossenen Auslesevorgang teilte mir Rubyripper mit, dass zwar Fehler aufgetreten seien, diese hätten aber erfolgreich korrigiert werden können. Ein Blick auf die angelegte Log-Datei bestätigte mir die Sache noch einmal im Detail. Aus irgendeinem Grund speicherte ich den Log-Text aber nicht. Bei der nachfolgenden Inspektion der CD nahm ich dann einige leicht ringförmig verlaufende Beschädigungen auf der Träger- bzw. Polycarbonat-Schicht wahr. Nichts Schlimmes also, ich hatte schon ganz andere CDs mit EAC erfolgreich gerippt. (Ein erklärendes Photo muss ich leider schuldig bleiben.)

Später lud ich die erstellten FLAC-Files mit Aqualung und liess die Musik während der Arbeit am PC im Hintergrund laufen. Dann die böse Überraschung: Bei Titel 11 waren deutlich Fehler, u.a. auch so genannte Glitches, zu vernehmen. Puh, wie dumm! Voller Ärger löschte ich die Dateien. Ein umfangreicherer Test musste her.


2. Durchgang.

Also die CD aus dem Regal geholt und mit Rubyripper erneut in's FLAC-Format ausgelesen.

https://www.audiohq.de/articles/Rubyripper/rubyripper-01a.png

Während des Rip-Vorganges teilte mir das Programm wieder mit, was ich ja inzwischen schon wusste.

https://www.audiohq.de/articles/Rubyripper/rubyripper-01b.png

Zum Schluss wurde der Sachverhalt dann noch einmal in Kurzform wiedergegeben.

https://www.audiohq.de/articles/Rubyripper/rubyripper-01c.png

Der Blick in die Log-Datei verriet auch hier mehr Details.

Starting to rip track 11, trial 1#
Starting to rip track 11, trial 2#
Analyzing files for mismatching chunks
2 chunk(s) didn't match 2 times.
Starting to rip track 11, trial 3#
Error(s) succesfully corrected, 2 matches found for each chunk :)
MD5 Digest is b9dcde7ba029c2b8d0a506f2b2fd7bbb

Starting to rip track 12, trial 1#
Starting to rip track 12, trial 2#
Analyzing files for mismatching chunks
Every chunk matched 2 times :)
MD5 Digest is e014adc8084766af7f58af818c193929


RIPPING SUMMARY

All chunks were tried to match at least 2 times.
Some track(s) needed correction,but could
be corrected within the maximum amount of trials

SUSPICION POSITION ANALYSIS

Since there are more than 150 chunks per second, after making the notion of the
suspicion position, the amount of initially mismatched chunks for that position is shown.

TRACK 11
    Suspicion position : 03:48 (1x) (CORRECTED at trial 3)
    Suspicion position : 03:56 (1x) (CORRECTED at trial 3)

Danach fuhr ich Ubuntu herunter, weil ich nun mit einem EAC-Referenz-Rip unter Windows XP (SP 2) fortfahren wollte. EAC mit den auf AudioHQ favorisierten Einstellungen meldete erwartungsgemäss keine Fehler.

Track 11

     Dateiname F:\EAC-rip\Various - 2007 - Groove CD 17\11_Brothers' Vibe - Manos Libre.wav



     Spitzenpegel 100.0 %

     Track Qualität 100.0 %

     Test CRC 6A6325A3

     Kopie CRC 6A6325A3

     Kopie OK


Sicht- und Hörproben. (<s>Download</s> der mit soundKonverter erstellten Lame-MP3-Samples (-V2), ca. 3 MB)

Hinterher hörte ich mir die von Rubyripper bemängelten Stellen genauer an. Um sicher zu gehen, liess ich den kompletten Titel durchlaufen. Dabei fielen mir in Echtzeit (laufende Min:Sec) 3 Stellen auf: Nr.1 bei 02.29, Nr.2 bei 03.22 und Nr.3 bei 03.56. Die vom Programm angegebene Stelle bei 03.48 jedoch war offensichtlich korrigiert worden, da ich dort, ob nun über Kopfhörer oder die Lautsprecher der Stereo-Anlage, nichts Negatives wahrnehmen konnte. Die beim ersten Rip zu hörenden Glitches traten hier interessanterweise nicht in Erscheinung.

Neugierig geworden schaute ich mir die Files daraufhin mit Audacity etwas näher an. Zumindestens die Position 02.29 liess sich auf diese Weise eindeutig auf einen "Knackser" beim Ausgangsmaterial zurückführen. Bei den anderen Stellen konnte ich, bis auf Nr.2 bei 03.22, erst einmal nur wahrnehmen, dass offensichtlich dezente Unterschiede zwischen den erstellten Audio-Files bestanden.

https://www.audiohq.de/articles/Rubyripper/rubyripper-01d.png
(Audacity verrät mit 5facher Vergrösserung teilweise Näheres...)

https://www.audiohq.de/articles/Rubyripper/rubyripper-01e.png
(Die beiden anderen Positionen mit 7facher Vergrösserung noch einmal im Detail...)

Dank Audacity war zumindestens die Position 02.29 m.E. abgeklärt.

Nachfolgend glich ich die 03.22'er- und die 03.56'er-Stelle mit dem EAC-Ergebnis ab. Hier reproduzierte das mit EAC erstellte File bei 03.22 den gleichen Fehler wie beim Ruby-Rip. Daher interpretierte ich diese Stelle ebenfalls als "Knackser", der jedoch im Audio-Editor optisch nicht auszumachen war. Die 03.56'er Position hingegen trat nur beim Rubyripper-Ergebnis unvorteilhaft in Erscheinung.

Aus reinem Interesse las ich dann den gleichen Track noch einmal mit Grip und CDex mit der kompletten paranoia-Einstellung aus, da beide über diese Möglichkeit verfügen. Der Vollständigkeit halber durfte sich dann auch noch foobar2000 mit der CD im empfohlenen Standard-Modus beschäftigen.

https://www.audiohq.de/articles/Rubyripper/rubyripper-01f.png
(Grip lächelt...)

https://www.audiohq.de/articles/Rubyripper/rubyripper-01g.png
(CDex sagt OK...)

"C:\Programme\foobar2000\flac 1.1.4\flac.exe" -s -8 - -o "11_Brothers' Vibe - Manos Libre.flac"

directory: F:\foobar-rip\Various - 2007 - Groove CD 17\

secure mode: CRC mismatch, retrying

reread #1, matches so far: 1780/1784

reread #2, matches so far: 1780/1784

secure mode: rereading successful

secure mode: CRC mismatch, retrying

reread #1, matches so far: 1765/1784

reread #2, matches so far: 1778/1784

reread #3, matches so far: 1781/1784

reread #4, matches so far: 1783/1784

secure mode: rereading successful

secure mode: CRC mismatch, retrying

reread #1, matches so far: 1759/1784

reread #2, matches so far: 1777/1784

reread #3, matches so far: 1777/1784

reread #4, matches so far: 1780/1784

reread #5, matches so far: 1782/1784

secure mode: rereading successful

secure mode: CRC mismatch, retrying

reread #1, matches so far: 1750/1784

reread #2, matches so far: 1753/1784

reread #3, matches so far: 1771/1784

reread #4, matches so far: 1779/1784

reread #5, matches so far: 1780/1784

reread #6, matches so far: 1780/1784

secure mode: rereading successful

(Und dies sagt foobar2000...)

Es sei zu den entsprechenden Hörergebnissen nur soviel gesagt: Auch hier wurden die 02.29'er und die 03.22'er Stelle wie beim EAC-Rip reproduziert. (Unter Berücksichtigung der User, die über keine Breitband-Anbindung an das WWW verfügen, habe ich den oben angegebenen Sample-Download nicht auch noch mit diesen Hörproben aufgebläht.) Wie beim EAC-File konnte ich dann aber auch bei der Position 03.56 keinen Fehler hören. Hierfür befinden sich 2 MP3-Dateien im Sample-Paket.
(Auf ein foobar2000-Beispiel habe ich übrigens wegen der bereits angesprochenen Gründe ebenfalls verzichtet, da das Ergebnis mit den anderen übereinstimmte.)

Misstrauisch geworden versuchte ich es nun mit einem einzelnem Rip des bewussten Tracks erneut mit Rubyripper. Der sich anschliessende Hörtest offenbarte mir zwischen der Position 03.37 bis 04.07 Unerfreuliches.

Also die ganze Geschichte noch einmal wiederholt. Das Ergebnis liess mich in Bezug auf die gerade benannten Positionen erst einmal aufatmen. Dennoch hörte ich mir danach den kompletten Titel an.

Nun ja, was soll ich sagen, zwischen den Positionen 01.40 bis 02.06 erwarteten mich dann wieder andere Rip-Fehler, weshalb ich auf weitere Tests verzichtete.


Fazit.

Wie am Anfang bereits gesagt: Ein schlichter Zufall verursachte das ganze Procedere, dessen Ergebnis mich von dem angegebenen Secure-Mode bisher nicht vollends überzeugt. Dennoch meine ich, dass hier ein Ansatz in die richtige Richtung verfolgt wird. Wenn in Zukunft vielleicht ein kompletter paranoia-Modus Hand in Hand mit einer entsprechenden Log-Ausgabe das nachträgliche Überprüfen der jeweils erstellten Dateien überflüssig machen sollte, würde ich das gut finden. Bis dahin werde ich aber unter Linux im Zusammenspiel mit einem adäquaten Laufwerk weiterhin Grip den Vorrang geben, auch wenn mir dort keine Log-Dateien zur Verfügung gestellt werden.

Gruss, DAU

P.S.: Dieser Beitrag sollte nicht als Nonplusultra gewertet werden. Korrekturen oder Mitteilungen über andere Erfahrungen sind jederzeit willkommen.

A Bill of Rights in Cyberspace

8 bearbeitet von Lego (Original: 2007-10-19 21:26)

Re: RubyRipper

.
http://www.teamlambchop.de/wp-content/plugins/lmbbox-smileys/smileys/ivy_grafiken/ivye/staun.gif

ich bin *very flabbergasted* von der Ausführlichkeit und "Ausprobiertiefe" Eurer Testberichte. So habe ich mir AudioHQ immer vorgestellt. B)

Weiter so.

Gruß
Jochen

Hier gehts zum [url=http://www.playauditorium.com/]Auditorium[/url] ...

9

Re: RubyRipper

Wie bekomme ich ruby-ripper unter Kubuntu Gutsy AMD64 zum Laufen?
Es wird immer die lib "ruby-gtk2" verlangt - nur kann ich die nirgends finden.

10

Re: RubyRipper

Morfeus, danke für deine Antwort und ein riesiges SORRY, dass ich das erst jetzt schreibe! War in den letzten Wochen ziemlich im stress und hatte keine Zeit mich mit dem Thema zu beschäftigen. Leider habe ich RubyRipper immer noch nicht zum laufen bekommen, aber wie es aussieht, ist es ja ohnehin fragwürdig, ob man das Programm überhaupt einsetzen sollte, wenn ich das hier lese.

11 bearbeitet von DAU (Original: 2009-10-06 01:27)

Re: RubyRipper

Rubyripper-Ergänzung.

Da Rubyripper inzwn. in der Version 0.5.7 zum Download angeboten wird, habe ich ihn aus reiner Neugier mal wieder ausprobiert. Das Ergebnis überraschte mich positiv.

Der Test erfolgte unter Ubuntu 9.04 ("Jaunty Jackalope") mit der bei getdeb erhältlichen Binary und dem LG-Brenner HL-DT-ST DVD-RAM GH22LP20 (Firmware 1.03).

Einrichtung.

Nach dem ersten Programm-Start schaute ich mir erst einmal die Einstellungen an.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02a.png

Beim Reiter Sicheres Auslesen überprüfte ich die Laufwerksangabe und die anderen Punkte. Wichtig war mir vor allem, dass nun der komplette Paranoia-Befehlssatz benutzt wird, solange man nichts anderes angibt. Auf eine Offset-Korrektur verzichtete ich, auch wenn sie in meinem Fall möglich gewesen wäre. Eine Cuesheet-Funktion fand ich ebenfalls vor.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02b.png

Unter Codecs veränderte ich die Einstellungen nach meinen Vorstellungen. Wenn man dort mehrere Audio-Formate aktiviert, erfolgt -ähnlich wie bei REACT- eine entsprechende Ausgabe. Mittels Standardlautstärkeabgleich hätte ich noch ReplayGain-Tags (Album- oder Track-Modus) setzen können.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02c.png

Danach kontrollierte ich kurz die Freedb-Einstellungen. Dort gefiel mir u.a., dass der Punkt Immer ersten Freedb Treffer verwenden auch deaktiviert werden kann.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02d.png

Zum Schluss passte ich noch bei Andere die Dateinamen-Schemata persönlichen Vorlieben an.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02e.png

Test.

Über Laufwerk öffnen lud ich dann die weiter oben bereits erwähnte Test-CD. Wegen vermeintlicher Inaktivität klickte ich kurze Zeit später auf Laufwerk abfragen, woraufhin der CD-Inhalt angezeigt wurde, dessen Angaben ich danach noch ein wenig veränderte.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02f.png

Ein Klick auf CD jetzt auslesen! startete den Rip-Vorgang.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02g.png

Hinterher teilte mir Rubyripper wieder mit, dass während des Auslesens Korrekturen vorgenommen wurden.

https://www.audiohq.de/articles/Rubyripper/rubyripper-02h.png

Mittels Logdatei öffnen konnte ich mir die Bemängelungen ansehen. Verzeichnis öffnen ermöglichte mir den sofortigen Zugang zur gerippten Datei, die ich mir umgehend anhörte.

Fazit.

Um es kurz zu machen: Diesmal waren für mich keine Fehler akustisch wahrnehmbar! Trotz meiner nun positiven Resonanz wäre es mir aber erst einmal lieb, wenn Interessierte die ganze Geschichte persönlich abgleichen könnten, denn auch weiterhin gilt: Dieser Bericht sollte b. a. W. nicht als Nonplusultra gewertet werden... ;)

A Bill of Rights in Cyberspace

12 bearbeitet von Sehfahrer (Original: 2014-04-06 12:56)

Re: RubyRipper

Hallo,

der Thread ist zwar schon etwas älter, aber da ich gerade durch Google auf Rubyripper gestoßen bin, sehr hilfreich für mich. Ich habe eine vielleicht sehr einfache Frage, ich denke, dabei wird sich nicht ein komplett neuer Thread "lohnen".

Wie lange dauert das Rippen einer CD normalerweise? Meine Installation (Ubuntu 12.04, aktuelle Software aus dem ppa von Brandon Snider installiert) läuft nun schon seit gut einer Stunde mit der Ankündigung "Starting to rip track 1, trial #1". Systemüberwachung sagt, dass cdparanoia mit zwischen 50 und 80 % CPU-Last bei der Arbeit ist.

Ist das normal?

Danke einstweilen für Eure Mühe :-)

13 bearbeitet von DAU (Original: 2014-04-09 02:07)

Re: RubyRipper

Hallo, Sehfahrer!

Laut dem Ubuntuusers-Wiki ist dieses Problem seit längerem bekannt.

Rubyripper arbeitet extrem langsam

Abgesehen von den Kopiervorgängen gibt es auch Fehlerberichte darüber, dass das Programm allgemein wesentlich schneller arbeitet, wenn es über die Kommandozeile bedient wird.

Als schneller arbeitende Alternative unter Linux ist eigenen Erfahrungen nach derzeit neben dem Kommandozeilenwerkzeug abcde nur Audex empfehlenswert.

Auf die Windows-Welt übertragen würde ich es folgendermaßen formulieren: Rubyripper versucht, seinem Vorbild EAC nahe zu kommen, während Audex CDex entspricht. Das ursächliche Problem ergibt sich bei beiden Programmen aus der Benutzung von cdparanoia, welches ‒ bisher ‒ trotz Übergehens des Laufwerkslesepuffers seit Version III.10.2 keine C2-Fehlerkorrektur und kein Leseoffset unterstützt. Rubyripper umgeht dieses Manko mit eigenen Routinen, was offensichtlich seine Zeit braucht.

Ob Deine Zeitangaben ›normal‹ sind, kann ich letztlich jedoch nicht zufriedenstellend beantworten.

Gruß

A Bill of Rights in Cyberspace