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.

Quote aus dem Hydrogenaudio.org Wiki

SUPER!

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

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.

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

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

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

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.

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.

(Audacity verrät mit 5facher Vergrösserung teilweise Näheres...)

(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.

(Grip lächelt...)

(CDex sagt OK...)

(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.

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.

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.

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.

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.

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

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

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.

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

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

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... ;)