[gelöst] abcde - Cuesheet als .txt?

[Houbey]

Hallo Debianer!

Ich habe mich nun die letzten Tage im Internet umgesehen und nach einem neuen Programm umgeschaut, was bei mir Rubyripper ersetzt. Ich habe sehr vieles über abcde gelesen und viele empfehlen diesen Programm. Ich habe bereits die abcde.conf in mein ~/.abcde.conf kopiert und nach meinen Vorstellen ein wenig angepasst. Soweit ist das alles in Ordnung.

Ich lasse mir immer eine .log, .m3u und eine .cue erstellen beim Rippen einer CD. Das war zumindest bei Rubyripper immer so. Nun muss ich noch irgendwie rausfinden, ob abcde auch .log Dateien erstellen kann. Aber mein eigentliches Problem was mir aufgefallen ist, ist es normal das abcde eine cue erstellt mit der Endung .txt? Kann man das nicht auch umstellen das direkt eine .cue erstellt wird? Als .txt bringt einem die cue doch normal gar nichts oder irre ich mich da?

[malzeit]

...Als .txt bringt einem die cue doch normal gar nichts oder irre ich mich da?

Moin,

ohne abcde jetzt zu kennen; dem Inhalt einer Datei ist es egal wie sie endet... Dateinamenendungen sind nur wichtig für die Programmverknüpfung.

Gruß

[Houbey]

Hallo malzeit,

dankeschön für deine Antwort. Das habe ich gar nicht gewusst. Ich bin immer davon ausgegangen das man einen cuesheet (.cue) deswegen anlegen lässt, um die cd damit zu brennen. Was ja den Vorteil hat, das es keine Unterschiede oder dergleichen mit den Tracks gibt oder?

Ich hatte testweise nochmal eine cd mit folgenden Befehl ausgelesen und gerippt:

Code: Alles auswählen

abcde -1

Hier wurde dann die CD in eine Datei gerippt. Das abcde eine .cue und .m3u erstellen soll ist in der ~/.abcde.conf eingetragen. Ich habe nun gemerkt, daß wenn ich die Tracks einzeln erstellen lasse, also jeder Track einzeln zum anklicken, dann erstellt abcde automatisch eine cue mit .txt Endung sowie eine .m3u Datei. Erstelle ich die CD aber als eine einzige Datei.flac (in meinem Fall), dann wird eine cue mit .cue Endung erstellt, aber die .m3u wird nicht erstellt.

Woran könnte da das Problem liegen?

[charno]

Kannst du mal den Inhalt der .cue und der .txt-datei vergleichen? Falls der Inhalt ähnlich ist, dann wird der Unterschied wohl nur im Dateinamen liegen.

Eine Playlist von einer Datei ist etwas sinnlos, vermutlich wird deshlab keine erzeugt wenn du die ganze CD in eine Datei rippst.

[Houbey]

Hallo charno,

das hatte ich mir bereits gedacht und ich hatte die beiden varianten verglichen. Es steht bei beiden das selbe drinne. Da du geschrieben hattest das es sinnlos wäre eine .m3u zu erstellen bei einem Rip als eine Datei, frage ich mich jetzt wieso eigentlich? Mit der playlist kann man ja eigentlich diese mit dem Player öffnen und dann in der Wiedergabenliste zu den jeweiligen Tracks springen oder nicht?

[smutbert]

Eher nicht, mir wäre es zumindest neu, dass man mit m3u-Playlists eine Stelle in einer Datei anspringen kann.

[Houbey]

Hallo smutbert,

also über den VLC Player geht das. Hatte ich noch getestet vorhin. Sowie man dann aber in der Wiedergabenliste auf den jeweiligen Track klickt, verändert sich der Name in den Datei.flac Name. Aber dennoch geht das andere Lied los. Was ist denn dann der Sinn das man eine .cue erstellen lässt und oder die CD in eine Datei rippt? Muss es da doch Vor- und Nachteile geben oder?

Ach und bevor ich es vergesse... abcde unterstützt wohl auch kein AccurateRip oder? Ich hatte da ein Perl-Script gefunden was ich getestet habe >>> http://www.hydrogenaud.io/forums/index. ... opic=62522 und das funktioniert zwar zum nachträglichen prüfen aber es zeigt meist immer nur an das es entweder nichts in der Datenbank gefunden wurde oder Rip not accurate.

[smutbert]

Muss es da doch Vor- und Nachteile geben oder?

Das hatten wir ja schon im Thread "Lossless Formate (WAV und FLAC wirklich verlustfrei?)". Zumindest sind vor dem ersten Track versteckte Stücke, die verloren gehen, imho der einzige Grund, der für eine einzelne Datei spricht.

Ansonsten verliert man auch mit einem Cuesheet und einzelnen flac-Dateien nichts und selbst mit einzelnen flac-Dateien ohne Cuesheet verliert man höchstens Pausen zwischen den Tracks und das auch nur auf sehr exotischen CDs. Ich bevorzuge allein schon wegen der Tags einzelne flac-Dateien und das Befürfnis Cuesheets (oder eine Playlists pro CD) anzulegen hatte ich noch nie, deswegen habe ich das beim Rippen auch noch nie erstellt.


Die Cuesheets geben einem halt die Gewissheit, dass - vorausgesetzt es wurde korrekt gerippt - man die CD mit Hilfe des Cuesheets wieder 1:1 so brennen kann wie sie beim Rippen war, inklusive aller Merkwürdigkeiten. Genau dafür, also zum Brennen von CDs wurden Cuesheets ja auch entwickelt.

[Houbey]

Hallo smutbert,

da abcde kein AccurateRip verwendet, kann ich natürlich nicht sicher sein ob es alles fehlerfrei gerippt wurde. Aber ich konnte nun auch nichts feststellen, daß cdparanoia Probleme hatte beim auslesen meiner CDs. Müsste dann doch zum einen Fehlermeldungen zeigen bzw sehr lange brauchen oder muss man das erst konfigurieren das cdparanoia das tut?

Eine playlist wird nach der abcde.conf Datei mit erstellt die ich hier gefunden habe >>> andrews-corner.org/abcde

Finde ich auch sehr praktisch. Naja gut, das wird sonst gleich OT daher wieder zurück zum Thema. Wie oben schon beschrieben, habe ich mir eine cue erstellen wollen die aber nur als .txt gespeichert wird, wenn ich jeden Track einzeln rippen lasse. Wieso ist das so? Wenn ich abcde sage er soll die CD nur als eine Datei rippen, dann erstellt er auch einen .cue komischerweise.

Ich habe mir mal die md5sum angesehen von der .txt Datei was ja die cue darstellen soll und kopiert. Dann habe ich die .txt Datei geöffnet und mit dem selben Namen und mit der Endung .cue gespeichert. So, die md5sum war die gleiche. Bedeutet das, wenn ich diese CD eines Tages wieder brennen möchte, kann ich den Inhalt der vermeintlichen cue als .txt einfach neu mit der Endung .cue speichern und dann in ein Brennprogramm einfügen oder geht das gar nicht mehr?

Tut mir leid für den langen Text.

[smutbert]

Malzeit hat ja schon geschrieben, dass die Dateieendungen keine Rolle spielen, ob abcde die Dateinamen der Cuesheets nun auf .cue oder .txt enden lässt ist vollkommen egal. Cuesheets sind einfach Textdateien, die beschreiben wie der Inhalt einer CD zu brennen ist (Wikipedia-Artikel über Cuesheets) und deren Dateiname üblicher- aber keinesfalls zwingenderweise auf .cue endet.

Was immer du also mit den Cuesheets anstellen willst, du kannst sie als .txt-belassen vorausgesetzt das (Brenn?)Programm versteift sich nicht darauf, dass die Dateien auf .cue enden müssen, in dem Fall benennst du die Dateien eben einfach um. Die md5sum ändert sich dadurch natürlich nicht, weil der Dateiinhalt unangetastet bleibt.


AccurateRip verwende ich (bis jetzt) nicht, auch wenn mir die Idee dahinter gefällt. Mir hat es genügt mein Laufwerk mit »cdparanoia -A« zu testen.

[Houbey]

Hallo smutbert,

vielen Dank für deine Antwort. Ja das wusste ich leider nicht, das die Dateiendung unwichtig ist. Also bei mir (Debian 8 mit Xfce) ist xfburn installiert. Dieses Programm kann nur ISO-Images brennen und keinerlei .bin, .cue oder sonstige Dateien. Ich wollte dir cue deshalb behalten falls ich es mal irgendwann brennen möchte für jemanden. So kann dann ein Brennprogramm das genauso brennen wie in der cue.

Gibt es unter Linux gar kein Brennprogramm was auch .cue Dateien brennen kann? Ich glaube brasero hat auch öfters Probleme damit. Und KDE Programme wollte ich nicht nutzen unter Xfce. Aber wie dem auch sei, danke für eure Infos und Hilfe. Da du geschrieben hattest, das es egal sei, ob es eine .txt oder .cue Endung hat, heißt das dann etwa das man dann auch die .txt Datei einfügen muss wenn man das Album mittels cue brennen möchte?

Ich habe mein Laufwerk mit cdparanoia -A auch getestet und es kam am Ende der analyse ein OK raus. Hat etwas gedauert die Abfrage aber scheint alles ok zu sein. Kann man eigentlich eine flac Datei intern abfragen ob es beim rippen Fehler gab? Z.B. das die Datei intern abgespielt wird im schnelldurchlauf und auf Sprünge oder kratzen reagiert?

AccurateRip ist eine interessante Sache aber leider funktionieren kaum CDs von mir. Und leider kann man auch seine geriptte CD nicht in die Datenbank aufnehmen. Wer sagt mir denn das EAC fehlerfrei ist und selber keine Fehler beim rippen gemacht hat und die Daten in der Datenbank falsch sind?

[schwedenmann]

Hallo


Ich habe jetzt die letzten 2 Tage mal morituri gestestet, aber so doll ist das ja auch nicht, es verwendet ja cdparanoia ud wie man die accuratechecksum berechnet hab e ich bis jetzt auch nicht rausgekriegt. Zum anderen kann man die accuratripdatabase ja nicht einsehen und bei meineroriginalcd fürs Testen (2 Stück) war eine nicht in der database, also wäre accuraterip wohl Glücksache.

Das Einzige was ich bei googen jetzt verändert habe, ist in abcde bei den paranoia Optionen -o6zx zu setzen.

Wobei jetzt 6 der offset für mein DVD-ROM ist.

mfg
schwedenmann

[Houbey]

Hallo schwedenmann,

ich habe auch mehr Probleme bei morituri gehabt was die Abfrage der AccurateRip Datenbank betrifft. Darum ist es für mich kein Ersatz, da es ja schon blöd ist wenn die meisten CDs die ich hier habe, nicht gefunden werden. Ich habe in den abcde.conf in meinem Homeverzeichnis bei den cdparanoia Optionen für meinen Offset folgendes eingetragen:

Code: Alles auswählen

CDPARANOIAOPTS="-O 6"

So habe ich es im Internet bei jemand anderen gesehen und so übernommen. Mein Laufwerk hat ebenfalls einen Offset von +6.

EDIT vom 20.11.2021
Ich würde auch gerne meine abcde.conf Datei, welche für FLAC eingerichtet ist, für andere zur Verfügung stellen, habe da ein paar kleine Änderungen nach meinen Vorstellungen vorgenommen. MP3 habe ich bis heute die Taggingfunktion nicht zum laufen bekommen. Vielleicht kann die ja jemand gebrauchen. >>> 41544

Wichtig: Achtet nur darauf, das ihr euch unter CDPARANOIAOPTS eure Offset Nummer eintragt. Bei meinem Laufwerk ist es +6. Den richtigen CD Drive Offset für euer Laufwerk könnt ihr euch aus dieser Liste raussuchen: Klick mich!

[smutbert]

Kann man eigentlich eine flac Datei intern abfragen ob es beim rippen Fehler gab?

Fehler, die vom Rippen kommen, kann man höchstens hören. Für den Encoder ist der Datenstrom, der vom Ripper kommt ja das Quellmaterial - die Fehler, die dort bereits drin sind, die aber den Audiodatenstrom in keiner Form ungültig werden lassen, weil die Laufwerke ja über eine Fehlerkorrektur verfügen und wenn die überfordert ist, dann die Daten interpolieren — die Fehler kann der Encoder weder erkennen noch sonst irgend etwas dagegen tun.

Es gibt nur wenige Laufwerke mit denen man die (korrigierten und unkorrigierten/interpolierten) Fehler überhaupt überprüfen kann. Von aktuellen kenne ich keines, aber die älteren Plextor-Laufwerke waren aus dem Grund sehr beliebt. Da konnte man getrennt oder während dem Rippen die Fehler überwachen. Das unter Debian dafür verfügbare Tool qpxtool habe ich aber nie ausprobiert.
(Wie man aus der Beschreibung erkennt ist das aber auch eher dafür gemacht die Qualität selbst gebrannter Medien zu überprüfen, ob oder was es da an eher aufs Rippen ausgelegte Tools, auch für Windows, gibt, weiß ich überhaupt nicht.)

Und leider kann man auch seine geriptte CD nicht in die Datenbank aufnehmen. Wer sagt mir denn das EAC fehlerfrei ist und selber keine Fehler beim rippen gemacht hat und die Daten in der Datenbank falsch sind?

Niemand sagt das, aber wenn eine CD bereits einmal identisch, dh mit genau derselben Prüfsumme gerippt wurde, ist es vermutlich um vieles wahrscheinlicher, dass beide Male fehlerfrei gerippt wurde, als dass zwei Mal derselbe Fehler gemacht wurde, und das vermutlich mit einem anderen Exemplar der CD und auf anderer Hardware.
Solange aber alles darauf hindeutet, dass meine Hardware richtig rippt und ich im Ergebnis keine Fehler höre, ist es mir tendentiell eher egal ob nun auch die Prüfsumme stimmt oder ob vielleicht ein Bit gekippt ist oä beim Abspielen einer Audio CD hat mich die Frage ja auch noch nie beschäftigt…

[…] ist xfburn installiert. Dieses Programm kann nur IIS-Images brennen und keinerlei .bin, .cue oder sonstige Dateien.

IIS kenne ich nicht und .bin enthält üblicherweise analog zu .iso einfach die nackten Daten, nur dass .bin meines Wissens vor allem für einzelne Tracks genutzt wird und nicht für komplette CD/DVD-Images, aber auch hier gilt Namen sind Schall und Rauch — im Endeffekt wird .bin für sehr viele verschiedene Dateien genutzt, die binäre Daten enthalten…

Für Cuesheets gibt es afaik hauptsächlich Kommandozeilentools (obwohl ich eigentlich glaube, dass brasero und k3b damit umgehen könnnen). Mit cdrdao und wav-Dateien kann man zB so brennen

Code: Alles auswählen

$ cdrdao write Cuesheet.cue

(cdrdao kann flac wohl nicht dekodieren, daher müsstest du das vorher machen und das cue-sheet mit einem Texteditor entsprechend anpassen)
Wie man darüber hinaus mit Hilfe von cue2toc, cuetools und zusätzlich shntool mit Cuesheets umgeht, findest du am besten mit Hilfe der Dokumentation der Tools und der vielen Anleitungen im Netz heraus. Die wenigen Male, die ich bis jetzt etwas mit Cuesheets gemacht habe, habe ich auch jedes Mal zuerst suchen müssen, wie man das am geschicktesten anstellt.

[Houbey]

IIS kenne ich nicht

Kein Problem smutbert, ich hatte ISO gemeint. Habe mich da verschrieben und gerade mal geändert den Fehler. Wenn ich mal eien CD brennen werde, was eher selten der Fall ist, dann werde ich mich mal umsehen. Ich kann die .txt Datei ja öffnen und mit dem selben Namen als .cue speichern, sollte ja keien Probleme geben. Verändere ja vom Inhalt nicht, wie du schon geschrieben hattest, das sich deswegen auch die md5sum nicht ändert.

Bin gerade dabei die ganzen Alben nach und nach anzuhören. Bis auf das alte Aufnahmen aus den 70er und 80er manchmal selber komischen Klang haben ist bis jetzt nichts aufgefallen an Störungen und Sprüngen. Vielleicht ist ja alles in Ordnung.

[Houbey]

Hallo Debianer!

Dieser Beitrag ist nun fast 6 Jahre alt, ich habe heute meine neue .conf Datei von abcde aktualisiert hochgeladen. Wer noch eine haben möchte, schaut bitte in meine Antwort hier vorbei.