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

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ß

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 :-)

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

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

Weiter so.

Gruß
Jochen

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.

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

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

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

Gruß,
Morfeus

Das Secure Ripping Verfahren ist relativ simpel aber effektiv.

Quote aus dem Hydrogenaudio.org Wiki

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

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

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.