AccurateRip: wie funktioniert es wirklich?! (Seite 1) - Einlesen und Brennen von Audio-CDs - AudioHQ

Sie sind nicht angemeldet. Bitte melden Sie sich an oder registrieren Sie sich.


AudioHQ » Einlesen und Brennen von Audio-CDs » AccurateRip: wie funktioniert es wirklich?!

Seiten 1

Sie müssen sich anmelden oder registrieren, um eine Antwort zu verfassen

RSS Thema Feed

Beiträge [ 12 ]



Thema: AccurateRip: wie funktioniert es wirklich?!

Folgende Problematik habe ich bereits in einem anderen Forum angesprochen, bislang aber ohne Erfolg... also lass ich Euch Profis mal ran...

Wie funktioniert der AccurateRip Abgleich genau?! Den eigentlichen Abgleich raffe ich, es werden per Track Checksums gebildet und abgeglichen; aber das meine ich nicht wirklich, sondern vielmehr wie eine CD erkannt wird; also beim Einlegen kann ich in EAC doch rechts unten in der Ecke gleich sehen ob diese CD in der AccurateRip-Datenbank vorhanden ist oder nicht; das heißt doch dass die CD-Identifizierung unabhängig von den Checksums gemacht wird. Nur Welche Technik wird hier angewandt?! Werden dazu Metadaten wie "Künstler" & "Albumnamen" dafür rangezogen, oder werden vielleicht die CD-ID (ID anhand der aus dem TOC gebildeten Prüfsummen) dazu verwendet?! Oder gibt es etwa eine anderen Weg an den ich gar nicht denke?! Wie gesagt, über die Checksums kann die ja eigentlich nicht identifiziert werden...

Aufgefallen ist mir dieser "Problematik" durch die verschieden Meldungen "Es könnte sich um eine andere Pressung ... handeln" & "Keiner der Tracks in der AccurateRib Datenbank enthalten"... Im Endeffekt sind beide Meldungen der Hinweis dass der Checksum-Abgleich nicht erfolgreich war, auf der einen Seite weil diese nicht mit denen in der Datenbank überein stimmten, auf der anderen Seite weil wohl kein Datenbank-Eintrag zum Abgleich gefunden wurde. Klar ist eigentlich der Fall mit der anderen Pressung: hier ist es wirklich eine andere Pressung oder eben ein "faules Ei".

Der andere Fall ist allerdings wieder etwas fragwürdiger: heißt das nun dass diese Checksum-Kombination generell nicht in der Datenbank ist, oder kann es auch der Fall sein dass hier lediglich kein Eintrag ausgewählt werden konnte und somit der Abgleich versagte, diese Checksum-Kombination aber durchaus in der Datenbank vorhanden sein kann?! Ist letzteres der Fall, ist die Eingangsfrage wieder interessant: Wie wird die CD identifiziert, und wie kann ich hier ggf drauf einwirken?!


Zusätzlich interessiert mich aber auch in wie fern verschiedene Pressungen ebenfalls in der AccurateRip-Datenbank vorhanden sein können?! Sind unterschiedliche Pressungen grundsätzlich ausgeschlossen?! Oder sind auch verschiedene Pressungen möglich?!


Wäre toll wenn Ihr bei mir etwas mehr Licht ins Dunkel bringen könntet... Danke schon mal dafür!

2 bearbeitet von Spunky (Original: 2010-06-12 23:10)

Re: AccurateRip: wie funktioniert es wirklich?!

Jede CD hat eine ID, aber wie die genau heißt, bin ich leider überfragt. Anhand dieser ID erkennt EAC um welche CD es sich handelt und zeigt dann bereits bekannte Metadaten an und ob diese CD in der Accurate Database zur Verfügung steht.

Die CD wird nicht anhand von Checksummen der Tracks und schon gar nicht anhand von Metadaten erkannt.

Der Hinweis "es könnte sich um eine andere Pressung handeln" erscheint immer dann, wenn im Auslesevorgang kein Fehler erkannt wurde, die Checksumme aber nicht mit der der Accurate-Database übereinstimmt. Das heißt aber nicht, dass kein Fehler aufgetreten ist. Ein typischer Fall wäre, wenn man eine CD im Burst-Modus ausliest, wo EAC ja keinerlei Prüfung oder Mehrfach-Auslesung vornimmt. Auch wenn ein Fehler aufgetreten ist meldet EAC somit - kein Fehler aufgetreten - und es erfolgt ein Vergleich mit der Accurate-Database. Hier werden die unterschiedlichen Checksummen bemerkt und es kommt zu der Meldung "es könnte sich um eine andere Pressung handeln".

Woran erkennt man nun, ob es sich tatsächlich um eine andere Pressung handelt?

Das kannst Du anhand Deines Auslesevorganges erkennen. Wenn Du mit Test und Copy im Secure-Mode ausliest, es hat keinerlei Fehler gegeben, die CRC stimmen alle und EAC zeigt Dir bei allen Tracks an, dass diese nicht mit der Accurate-Datenbase übereinstimmt, dann hast Du eine andere Pressung im Laufwerk. Doch nehmen wir mal an, es wurden alle Tracks richtig gelesen, bis auf einen. Accurate meldet alles ok, bis auf einen Track. Dann wird man diesen einen Track i.d.R. nochmal rippen. Erkennt EAC nun keinen Lesefehler und die CRC stimmt mit Accurate nicht überein, dann kommt es leider auch zu der Meldung "es könnte sich um eine andere Pressung handeln", aber es ist natürlich keine andere Pressung, denn die anderen Tracks haben ja gestimmt.

Also Hirn einschalten, dann kann man relativ leicht erkennen, wann es sich tatsächlich um eine andere Pressung handelt und wann nicht.

Hoffe meine Antwort hat Dir geholfen
Spunky

3 bearbeitet von DanielOcean (Original: 2010-06-13 09:03)

Re: AccurateRip: wie funktioniert es wirklich?!

Hallo Spunky,

vielen Danke erstmal für deine ausführliche Antwort... nur leider - so glaube ich - haben wir wohl aneinander vorbei geredet bzw. sind deiner Behauptungen zum Teil falsch...

Also Hirn einschalten, dann kann man relativ leicht erkennen, wann es sich tatsächlich um eine andere Pressung handelt und wann nicht.

Jo, versuch ich eigentlich immer... in diesem Fall wohl noch ein bisschen mehr... ;) Spaß beiseite, bin ja froh dass sich zumindest mal jemand zu diesem Thema äußert, auch wenn es mir in diesem Fall nicht wirklich weiterhilft... aber vielleicht kommen wir ja noch drauf wie es wirklich funktioniert...

Mir geht es nicht um die grundsätzliche Arbeitsweise von AccurateRip... Wenn die Meldung "Es könnte sich um einer andere Pressung..." erscheint, ist mir durchaus bewusst dass die CD als solche erkannt wurde und dazu in der AccurateRip-Datenbank der passende Eintrag ausgewählt wurde, aber eben die Checksummen nicht mit denen in der Datenbank übereinstimmen. Du liegst allerdings falsch dass die o.g. Meldung auch erscheint wenn lediglich ein oder mehrer Tracks als "nicht akkurat" identifiziert werden konnten, lediglich wenn ALLE Tracks dieser CD nicht als akkurat ermittelt wurden, dann erscheint diese Meldung! Somit ist es auch Quatsch wenn du sagst dass bei nur einem Track als "nicht akkurat" es sich grundsätzlich nicht um einer andere Pressung handeln kann weil alles anderen ja gestimmt hätten; ich habe zB einige CD's bei denen wirklich nur wegen eines Tracks es sich um eine andere Pressung handeln kann! Allerdings erscheint dann die Meldung mir der Pressung NICHT, sondern lediglich der eine Song wird immer wieder - auch nach dem x-ten Ausleseversuch - als "nicht akkurat" gemeldet!

Grundsätzlich sei gesagt dass ich NUR und PUR im Secure Mode mit richtig kalibriertem Offset und AccurateRip-DB-Abgleich rippe... somit fallen deine Spekulationen bzgl. des Burst-Mode ebenfalls raus... für mich geht es in erster Linie um eine 1:1 Archivierung, nicht um eine halbgare Sicherung...

Was ich mit meinem Post allerdings wissen wollte ist eben die die CD vor dem Einlesen vom AccurateRip-Modul erkannt wird; ich spreche hier ganz klar und eindeutig nur un pur vom AccurateRip-Teil, EAC selbst checkt die CD via freeDB und besorgt sich so die Metadaten!
Meine Frage ist nun mit welchem Eintrag die AccurateRip-Datenbank durchforstet wird um mit VOR dem Einlesen mitteilen zu können dass diese CD in der AccurateRip-Datenbank vorhanden ist oder eben nicht. Es war die Rede von der Disk-ID, welche aus dem TOC erstellt wird; nur ist die Frage ob diese ID beim Einlesen erstellt wird, oder ob diese ID ein fester Bestandteil der CD ist, also sich bereits irgendwo befindet.
Im ersten Fall ist die ID natürlich nicht wirklich zu beeinflussen, außer eben durch die Tracks selbst; letzterer Fall allerdings wirft natürlich die Frage nach der Plausibilität dieser ID auf und lässt somit wohl die Möglichkeit offen diese anzupassen.

Gehen wir mal davon aus dass die ID ein fester Bestandteil der CD ist und zB bei einer Kopie verfälscht, verändert oder irgendwie anders manipuliert wurde... so lässt dies natürlich die Vermutung zu dass dadurch die CD in der AccurateRip-Datenbank gar nicht erst abgeglichen werden kann weil eben der Schlüssel Namens ID kein Pendant in der AccurateRib-Datenbank gefunden hat und somit die Meldung "keiner der Tracks in der Datenbank vorhanden" erscheinen wird... wobei eigentlich ja richtiger wäre "Kein Track konnte als akkurat verifiziert werden. Es könnte sich um eine andere Pressung als von der in der Datenbank vorhandenen handeln." Richtig?!

Gehen wir mal davon aus dass die ID jedesmal anhand der TOC neu erstellt wird und somit nicht auf der CD vorhanden ist... Nun, dann lässt diese Variante ja die Vermutung zu dass lediglich bei gleicher TOC ein Abgleich überhaupt möglich ist. Ich frage mich allerdings warum solche CD's dann zwar in FreeDB gefunden werden, ein entsprechender Eintrag in der AccurateRip-Datenbank allerdings nicht auftaucht obwohl aber dennoch davon auszugehen ist dass diese CD einen Eintrag in selbiger Datenbank beinhalten müsste...

Mir geht es grundsätzlich einfach nur darum wie die AR-Datenbank funktioniert... und zwar nicht im positiven Fall, denn dieser scheint ja recht eindeutig zu sein, sondern eben in diesem negativen Fall ebenso sehr wie in dem Fall dass beim Einlegen entsprechende CD gar nicht erst in AR gefunden werden kann...

4 bearbeitet von start78 (Original: 2010-06-13 09:42)

Re: AccurateRip: wie funktioniert es wirklich?!

Es ist relativ simpel, eine CD ziemlich eindeutig zu identifizieren:
Die Anzahl der Tracks und deren jeweilige Länge (auf den Frame genau) genügt. Ich hatte bei meiner Sammlung von ca. 500CDs nur einen einzigen Fall, bei dem die freedb-Datenbank zwei völlig unterschiedliche Alben vorschlug. Das mag eine vereinfachte Erklärung sein, mir genügt sie jedoch vollkommen.

Es wäre dumm, wenn AccurateRip eine andere Methode verwendet (bitte nötigt mich nicht zu einer Begründung dieser Aussage).

Auch die Kopie einer CD sollte die gleiche ID haben. Ansonsten wären massive Fehler beim Kopiervorgang aufgetreten.

Und bei unterschiedlichen Pressungen unterscheidet sich nicht zwangsläufig alle Tracks. Es können grundsätzlich auch nur einzelne Tracks in ihrer Checksumme von denen einer anderen Pressung abweichen. Warum nicht?

Nach allem, was ich gelesen habe, müssen übrigens mindestens fünf übereinstimmende Eintragungen in der AR-DB vorhanden sein, bevor ein Abgleich der entsprechenden Disk vorgenommen wird.

Nebenbei:
Ich persönlich werte AccurateRip nicht als Ergänzung zum Secure Ripping Mode, sondern als Alternative (eigene Meinung ohne Anspruch auf universelle Weisheit). Sprich: entweder Secure Mode oder Burst+AccurateRip.

Warum soll ich mich jedesmal verrückt machen lassen, wenn AccurateRip die Möglichkeit eines Auslesefehlers in den Raum stellt? Mir genügt es, wenn mein eigener PC mir sagt, daß alles zu 100% fehlerfrei ausgelesen wurde.

AccurateRip in Kombination mit dem Burst Mode könnte natürlich deutlich schneller rippen, allerdings immer mit der Möglichkeit verbunden, daß ich eine CD bei fehlgeschlagener AccurateRip-Verifizierung nochmal im Secure Mode rippen müsste. Und da meine derzeitige Konfiguration sogar schneller rippt als encodiert (LAME mp3+FLAC dauern eben), kann mir ein eventueller Geschwindigkeitsvorteil durch den Burst Mode herzlich egal sein.

Raubkopieren ist nicht der ideologische Kampf gegen das böse System,
sondern egoistische, arrogante, knausrige Scheiße.

5 bearbeitet von Meiner Einer (Original: 2010-06-13 10:35)

Re: AccurateRip: wie funktioniert es wirklich?!

Ein möglicher Grund, das manchmal einzelne Tracks innerhalb einer CD nicht als accurat verifiziert werden, könnte sein, das der Sampleoffset Deines Laufwerkes nicht korrekt eingestellt ist.

Wenn Du etwas Zeit und Lust hast, kannst Du es selbst mal gegenprüfen.

Die Erklärung dazu:

Meist fangen Titel zuerst mit einer kleinen Pause (digital Null) an und enden ebenso. Da Digital Null am Ende und Anfang nicht in die Berechnung einfließt, sondern nur die tatsächlichen Nutzdaten, bekommst Du auch bei einem evtl. Leseversatz korrekte Vergleichsdaten.

Nun ist es aber nicht immer so. Mitunter enden Titel auch mit einem nicht vollständig auf Null ausgeblendeten Werten (meist Rauschen).
Noch extremer wird es bei Konzeptalben, die quasi "durchlaufen". Der Ripp als solches wird trotzdem einwandfrei sein, da ja jedes einzelne Sample innerhalb der CD erfasst wird. Nur die Track bzw. Indexe sind ja leicht verschoben und würden somit keine Übereinstimmung mit der Accurate DB bringen.

Das heißt, zuerst solltest Du sichergehen, das die Offsetkorrektur für Dein LW richtig ermittelt ist.
Dann kannst diese Werte zu Testzwecken mal von Hand verändern, ebenso Dir mal solche Tracks in einem Wave-Editor anschauen, ob wirklich Anfang und Ende von Null abweichende Werte enthält.

Mehr ist das nicht...
Übrigens kann aus genau diesem Grund auch ein Wert in der DB "falsch" sein. Zumindest solche mit einer Zuversicht von 1 oder 2.

Re: AccurateRip: wie funktioniert es wirklich?!

start78 schrieb:

Es ist relativ simpel, eine CD ziemlich eindeutig zu identifizieren:
Die Anzahl der Tracks und deren jeweilige Länge (auf den Frame genau) genügt... Es wäre dumm, wenn AccurateRip eine andere Methode verwendet (bitte nötigt mich nicht zu einer Begründung dieser Aussage).

OK, diese Aussage finde ich schon mal recht wichtig und (hoffentlich) auch richtig... Die Begründung wäre aber dennoch nett ;) Damit meist du also die TOC, aus der die Disk-ID entsteht... Ich gehe also davon aus dass diese ID jedesmal gebildet wird und sich (abgesehen von der TOC) nicht auf der CD als fester Parameter... würde ja eigentlich auch Sinn machen...

start78 schrieb:

Nach allem, was ich gelesen habe, müssen übrigens mindestens fünf übereinstimmende Eintragungen in der AR-DB vorhanden sein, bevor ein Abgleich der entsprechenden Disk vorgenommen wird.

Da kann ich dir allerdings aus eigener Erfahrung widersprechen! Der erste Eintrag einer bestimmten Disk-ID ist gleich die erste Zuversicht. Kommt nun ein zweiter Eintrag dazu, bekommt dieser (bei identischem Ergebnis) die "Zuversicht 1" gemeldet, erst wenn dieser zweite User seine ermittelten Checksummen übermittelt, bekommt der Nächste (also dritte User) bei wiederum identischem Ergebnis die "Zuversicht 2" gemeldet; übermittelt der zweite User seine Daten nicht, so bekommt der Dritte ebenfalls lediglich die "Zuversicht 1" gemeldet...

start78 schrieb:

Ich persönlich werte AccurateRip nicht als Ergänzung zum Secure Ripping Mode, sondern als Alternative (eigene Meinung ohne Anspruch auf universelle Weisheit). Sprich: entweder Secure Mode oder Burst+AccurateRip.

Nun, ich sehe es wirklich als Ergänzung, stimmt eines von beiden nicht, so nehm ich den Rip genauer unter die Lupe... und dann entscheide ich ob die CD ok ist oder eben nochmal gerippt werden muss... AccurateRip und SecureMode ist für mich quasi die automatische Absolution...



Meiner Einer schrieb:

Ein möglicher Grund, das manchmal einzelne Tracks innerhalb einer CD nicht als accurat verifiziert werden, könnte sein, das der Sampleoffset Deines Laufwerkes nicht korrekt eingestellt ist... Das heißt, zuerst solltest Du sichergehen, das die Offsetkorrektur für Dein LW richtig ermittelt ist.

Nun, da hast du wohl meinen Beitrag nur überflogen... habe mehrfach erwähnt dass ich wert auf einen korrekt eingestellten Offset lege... Ich habe auch mehrfach betont und dies auch hoffentlich durch die Überschrift zum Ausdruck gebracht dass es mir hier um den Teilbereich "AccurateRip" geht, nicht um andere Bereich in EAC, welche ich vollkommen nachvollziehen kann; nochmal, es ist lediglich der Bereich "AccurateRip" der für mich Fragen offen lässt... Dennoch ergibt sich auf deinem Beitrag nochmal eine Frage die sicher auch nicht uninteressant ist:

Meiner Einer schrieb:

Übrigens kann aus genau diesem Grund auch ein Wert in der DB "falsch" sein. Zumindest solche mit einer Zuversicht von 1 oder 2.

Da hast du absolut Recht! Und so entsteht auch gleich schon wieder eine neue Frage: Wenn der erste, meinetwegen auch zweite oder dritte Eintrage pro CD in der AccurateRip-Datenbank mit NICHT-korrekt eingestelltem Offset und zufälligerweise dennoch gleichen Checksummen festgehalten wird, so ist dieser doch erstmal als der quasi Korrekte eingetragen; was passiert nun wenn also nach diese bestehenden "Zuversicht 3", sagen wir mal die nächsten sechs Einträge mit richtig eingestelltem Offset und identischen Checksummen vorgenommen werden; werden dann diese sechs Einträge nach und nach als "nicht akkurat" abgelehnt, oder werden diese im Hintergrund parallel gespeichert und bei einem möglichen "Tabellenführer-Ablösung" (in diesem Fall also nach dem vierten Rip mit korrektem Offset) als das neue tatsächlich korrekte Album geführt?!

Re: AccurateRip: wie funktioniert es wirklich?!

DanielOcean schrieb:

Nun, da hast du wohl meinen Beitrag nur überflogen...

Habe ich das?

Meiner Einer schrieb:

das der Sampleoffset Deines Laufwerkes nicht korrekt eingestellt ist.

und

Meiner Einer schrieb:

Das heißt, zuerst solltest Du sichergehen, das die Offsetkorrektur für Dein LW richtig ermittelt ist.

Nirgendwo habe ich angezweifelt, das Du den Offset nicht ermittelt hast. Im Gegenteil, es hätte mich bei Deiner Fragestellung eher verwundert, wenn Du es nicht getan hättest.

Genau wie Du selbst die Arbeitsweise von Accurate Rip hinterfragst bzw. deren Werte möglicherweise "anzweifelst" - wer garantiert Dir, das die Offsetwerte korrekt ermittelt/eingetragen wurden? Sogar in EAC selber steht, das Du die Daten trotzdem übermitteln sollst, auch wenn Du nicht sicher bist, das sie stimmen...
----

DanielOcean schrieb:

Und so entsteht auch gleich schon wieder eine neue Frage...

Du wirfst jetzt tatsächlich eine interessante Frage auf...
Denn gewisse LW-Typen sind sehr stark verbreitet. Und ich kann mir auch recht gut vorstellen, das viele Leute ihre CDs ohne diese Offsetkorrektur rippen. Von daher sind falsche Einträge in der Accurate-DB durchaus möglich.

Die weitere Frage wäre jetzt tatsächlich: werden andere Werte zugelassen, wenn sie irgendwann mal überwiegen? Werden auch mehrere Werte zugelassen?

Denn ein Rippen ohne oder mit falschen Offset ist ja nicht grundsätzlich falsch, die eigentlichen Nutzdaten sind ja trotzdem richtig. Und so lange man die komplette CD rippt, spielt das nicht mal bei Konzept-CDs (überlaufende Titel) eine Rolle.


Ich denke mal, das beste wäre, sich mit dem Programmierer in Verbindung zu setzen. Er könnte Dir am besten erläutern, was er sich wie gedacht hat. Zumal Programmierer über Feedback, Ideen, Anregen, Bugreports oder Verbesserungen meistens dankbar sind.

Übrigens...
Bei der Gelegenheit hatte ich auch schon mal einen Fall, wo Test- und Lese-CRC OK waren, der Titel aber als einzigster auf der CD nicht als accurat identifiziert wurde.

Ich habe ihn dann hinterher nochmal (einzeln) testen und einlesen lassen. Und siehe da: Ich hatte andere CRC-Werte, die aber in sich wieder identisch, also OK waren und Accurate hat dann auch OK "gesagt".

Wie ist sowas möglich?

8 bearbeitet von DanielOcean (Original: 2010-06-14 14:02)

Re: AccurateRip: wie funktioniert es wirklich?!

Meiner Einer schrieb:
DanielOcean schrieb:

Nun, da hast du wohl meinen Beitrag nur überflogen...

Habe ich das?

Eine Vermutung... und doch kam es eben genau so rüber... schreibst ja dass der Grund sein könnte dass mein Offset nicht korrekt eingestellt ist, wohin gegen ich oben deutlich erwähnte dass ich den Offset ermittelt habe.
Natürlich wäre es auch eine Überlegung wert ob diese Ermittlung tatsächlich korrekt wäre, aber dann wäre es ja wohl eher ein recht simpler Einstellungsfehler und ich sollte so kaum korrekte Ergebnisse bekommen...

Meiner Einer schrieb:

Nirgendwo habe ich angezweifelt, das Du den Offset nicht ermittelt hast. Im Gegenteil, es hätte mich bei Deiner Fragestellung eher verwundert, wenn Du es nicht getan hättest.

Naja, du greifst aber einen Aspekt auf den ich doch eigentlich ausgeschlossen habe, und dadurch sieht es so aus dass du eben den Beitrag nur überflogen hast; warum sprichst du etwas an das eigentlich nicht die Ursache sein kann?

Is aber auch ganz und gar egal... mich hats eben nur gewundert und auch auch irritiert dass du diesen Punkt ansprichst... Wichtig ist doch dass sich für mich eben durch deinen Beitrag eine weitere Frage ergeben hat...

Meiner Einer schrieb:

Du wirfst jetzt tatsächlich eine interessante Frage auf...
Denn gewisse LW-Typen sind sehr stark verbreitet. Und ich kann mir auch recht gut vorstellen, das viele Leute ihre CDs ohne diese Offsetkorrektur rippen. Von daher sind falsche Einträge in der Accurate-DB durchaus möglich.

Prinzipiell ist so der Assistent in der ProBeta5-Version zu begrüßen, der nochmal auf diese Problematik hinweist; dennoch hast du bestimmt recht dass einige ihren Offset sicherlich nicht eingestellt haben.

Meiner Einer schrieb:

Die weitere Frage wäre jetzt tatsächlich: werden andere Werte zugelassen, wenn sie irgendwann mal überwiegen? Werden auch mehrere Werte zugelassen?

Nun, ich hoffe das andere Werte im Hintergrund gespeichert werden und nicht einfach nur abgewiesen werden, sodass eben im Fall des Führungswechsels der neue Wert als korrekt aufgeführt wird. Ich kann mir allerdings nicht vorstellen dass mehrere Werte zugelassen werden: Dagegen sprich ganz klar die Meldung über die mögliche andere Pressung; würden mehrer Werte zugelassen, gäbe es diese Meldung nicht. Weiterhin sprich dagegen dass so kein Wert mehr als "falsch" deklariert werden würde, sondern lediglich als "anders" und dadurch wäre diese Datenbank wieder nur Wischiwaschi und nicht konkret: Jeder Wert würde quasi in die Datenbank wandern und somit auch zig falsche Werte.
Einzig der größte Wert ist in der Datenbank relevant; stellt sich eben nur die Frage ob eben andere Werte im Hintergrund katalogisiert werden, oder eben nicht; würden diese katalogisiert und ein Wert übersteigt den bisher als korrekt geführten Wert, dann ist halt die Frage wie dann damit umgegangen wird.
Wahrscheinlicher ist allerdings dass diese Werte nicht hinterlegt werden und lediglich der erste richtige Wert in die Datenbank Einzug erhält, bzw. wohlmöglich die erste Bestätigung dieses Wertes.

Meiner Einer schrieb:

Denn ein Rippen ohne oder mit falschen Offset ist ja nicht grundsätzlich falsch, die eigentlichen Nutzdaten sind ja trotzdem richtig. Und so lange man die komplette CD rippt, spielt das nicht mal bei Konzept-CDs (überlaufende Titel) eine Rolle.

Jein... die Nutzdaten zum Abspielen sind sicher korrekt und auch über jeden Zweifel erhaben. Bei einer 1:1 Reproduzierbarkeit des Originals sieht dies natürlich anders aus; auch wenn dies sicher kleinlich ist, so ist dies eben so nicht mehr möglich bzw. kann so nicht mehr 100% sichergestellt werden.
Grundsätzlich glaube ich allerdings noch nicht mal dass dies so ein großes Problem wäre, aber es ist nun mal so dass diese Abgleichmöglichkeit eben nur so sinnvoll möglich ist und so eine Archivierung ohne Überprüfung erfolgen kann, denn ein Secure Mode bei korrektem Offset mit AR-Abgleich und den dazu passenden positiven Ergebnis lässt durchaus eine "blinde" Archivierung zu...
Wie gesagt, ein kleinliches Argument dass die Daten "nicht richtig" sind, aber lediglich der Abgleichmöglichkeit geschuldet. Meines Wissen nach ist es aber wohl nicht machbar eine Abgleichmöglichkeit zu schaffen und dabei einen möglichen Offset davon unabhängig zu machen... Wenn doch, wäre dies durchaus eine Möglichkeit dieser Problematik aus dem Weg zu gehen.

Meiner Einer schrieb:

Ich denke mal, das beste wäre, sich mit dem Programmierer in Verbindung zu setzen. Er könnte Dir am besten erläutern, was er sich wie gedacht hat. Zumal Programmierer über Feedback, Ideen, Anregen, Bugreports oder Verbesserungen meistens dankbar sind.

Na das wäre mal eine Überlegung wert... hoffe nur ich bekomm das in Englisch dann auch so hin ihm das zu erklären was ich meine ;)

Meiner Einer schrieb:

Übrigens...
Bei der Gelegenheit hatte ich auch schon mal einen Fall, wo Test- und Lese-CRC OK waren, der Titel aber als einzigster auf der CD nicht als accurat identifiziert wurde.

Ich habe ihn dann hinterher nochmal (einzeln) testen und einlesen lassen. Und siehe da: Ich hatte andere CRC-Werte, die aber in sich wieder identisch, also OK waren und Accurate hat dann auch OK "gesagt".

Wie ist sowas möglich?

Die CRC-Werte sind doch die Werte des Secure-Mode., richtig?! Somit haben diese nichts mit der AR-Datenbank zu tun, also nicht die CRC-CHecksummen mit den AR-Checksummen verwechseln, das sind zwei total unterschiedliche Werte.
Klingt für mich nach der Möglichkeit dass ggf dein Laufwerk puffert, du den entsprechenden Haken unter "EAC -> Laufwerkseinstellungen -> Auslesemethode -> Sichere Modi -> Laufwerk puffert Audiodaten" nicht gesetzt hast und somit EAC dein Laufwert NICHT dazu zwingt auf die Pufferung (Zwischenspeichern) zu verzichten; oder anders gesagt:

Der Haken bei "EAC -> Laufwerkseinstellungen -> Auslesemethode -> Sichere Modi -> Laufwerk puffert Audiodaten" bewirkt, dass EAC das Laufwerk dazu zwingt die Pufferung zu Umgehen, also dass das Laufwerk quasi gezwungen wird nicht auf den Pufferspeicher zuzugreifen, sodass jedes mal neu gelesen werden muss. Dies ist notwendig beim Secure-Mode, denn hier wird bekanntlich immer zweimal gelesen; ist das Laufwerk in der Lage zu Puffern und ist der o.g. Haken nicht gesetzt, so liest das Laufwerk den Track tatsächlich nur einmal und bedient sich beim zweiten Secure-Mode-Einlesen aus dem Speicher, das hat dann zu Folge dass die Vorteile des Secure-Mode umgangen werden, es wird also quasi nur einmal eingelesen.

Wenn das Laufwerk also puffert und der Haken nicht gesetzt ist, entstehen fast automatisch zweimal die selben CRC-Werte; das heißt aber noch nicht dass dadurch etwas doppelt gelesen wurde, denn die Daten des zweiten Einlesevorgangs stammen aus dem Speicher.

ABER:
Es ist bei mir auch schon ein paar mal vorgekommen, dass bei echtem Secure Mode (also ohne Pufferung), beim selben Lied von der selben CD bei zwei verschiedenen Auslesevorgängen zwei unterschiedliche CRC-Werte geliefert und auch bestätigt wurden; einmal gelang dabei der AR-Abgleich, einmal nicht! Wie dies zu erklären ist dass der Secure-Mode sich zweimal überlisten lies und dabei auch noch die selben CRC's lieferte, weiß ich natürlich auch nicht...

Re: AccurateRip: wie funktioniert es wirklich?!

Eine Vermutung... und doch kam es eben genau so rüber... schreibst ja dass der Grund sein könnte dass mein Offset nicht korrekt eingestellt ist, wohin gegen ich oben deutlich erwähnte dass ich den Offset ermittelt habe.

Wenn das wirklich so rübergekommen ist, dann entschuldige bitte.
Ich bin davon ausgegangen, das Du den Offset zwar hast ermitteln lassen, was aber nicht heißt, das er stimmen muß.
Mit anderen Worten: Aus eigener Erfahrung weiß ich, das man keine mögliche Fehlerquelle ausschließen sollte. Schon gar nicht dann, wenn es "absolut richtig" ist..
OK, ich denke/hoffe, das ist geklärt.

-----

Zur Datenbank: Gehen wir mal von dem Fall aus, das für eine CD eine ansehnliche Zahl von "Zuversicht X" vorliegt. Jetzt kommt besagte "andere Pressung" ins Spiel. Wenn dort ebenfalls irgendwann mal eine Reihe von erfolgreichen Lesevorgängen vorliegt, dann sollte dieser Wert ebenso gültig sein - aber eben bezogen auf die andere Pressung.
Das heißt, aus Sicht des Programmierers würde ich es zulassen, auch 2 Werte in der DB zu haben. Beim zweiten Wert vielleicht dann mit der zusätzlichen Meldung für den Anwender: "Zuversicht XX, bezogen auf alternative Pressung".
Nur als Beispiel...
Allerdings müßte man dann tatsächlich mal Kontakt aufnehmen.

Denn alle anderen Werte, die durch fehlerhaftes Einlesen entstehen, liegen ja im allgemeinen nur ein Mal vor - Unwahrscheinlich, das viele User (vom besagten nicht ermittelten Offset mal abgesehen) immer die gleichen "falschen" Werte bekommen. Wobei es für die Accurate-DB möglich sein müßte, auch abzufragen, ob der Offset überhaupt ermittelt wurde. Ich denke nämlich, das zwischen den Programmierern von EAC und Accurate sowieso schon eine gewisse Kooperation bestehen müßte.

Jein... die Nutzdaten zum Abspielen sind sicher korrekt und auch über jeden Zweifel erhaben. Bei einer 1:1 Reproduzierbarkeit des Originals sieht dies natürlich anders aus; auch wenn dies sicher kleinlich ist, so ist dies eben so nicht mehr möglich bzw. kann so nicht mehr 100% sichergestellt werden.

So sehe ich das auch. Wenn man vorhat, sich wieder eine CD daraus zu brennen, so ist damit kein 1:1 möglich. Du hast durch den nicht korrigierten Offset einen Versatz in der TOC.

Da stellt sich gleich wieder die Frage: Wieso können die Hersteller der Laufwerke das nicht gleich von sich aus berücksichtigen/korrigieren? Vor allem, wenn man bedenkt, das zu Zeiten des "leidigen" Kopierschutzes von den Herstellern der Laufwerke alles mögliche unternommen wurde, um diesen Schutz quasi zu "ignorieren".
Zumal der Offset pro LW-Type ja wohl einen festen Wert hat.

Die CRC-Werte sind doch die Werte des Secure-Mode., richtig?! Somit haben diese nichts mit der AR-Datenbank zu tun, also nicht die CRC-CHecksummen mit den AR-Checksummen verwechseln, das sind zwei total unterschiedliche Werte.

Ja, die meinte ich. Ich lasse grundsätzlich immer mit "Teste & kopiere..." einlesen, so das beide Werte in EAC zusätzlich noch verglichen werden.
Die AR-DB verwendet tatsächlich andere Berechnungswerte, was aber keine Rolle spielt.

Klingt für mich nach der Möglichkeit dass ggf dein Laufwerk puffet

Nein, auf den Gedanken bin ich nämlich auch gekommen...

Überlegen wir mal:
Zuerst wird der Titel vollständig im Testmodus eingelesen. Dann noch einmal zum speichern. Die Titel sind auf der CD unkomprimiert in einem mit WAVE/AIFF vergleichbaren Format (Der Unterschied ist nur, das sie keinen Header haben und das ein Interleave von 6 verwendet wird - also jeweils 6 Samples Links, 6 Samples Rechts usw. Bei WAVE/AIFF ist das Interleave normalerweise 1 - also ein Sample Links, ein Sample Rechts usw., sofern Du nicht gewaltsam in einem Waveeditor was anderes einstellst).
Das heißt, ein Titel von z.B. 3 Minuten ist somit ca. 30 MB groß (Die Komprimierung nach FLAC findet erst nach dem Lesen auf dem Rechner selbst statt, hat also hierbei nix zu sagen).
Es werden also erst einmal 30 MB vollständig zum testen gelesen und dann diese 30 MB noch einmal zum Speichern. Wie groß war doch gleich noch mal der Pufferspeicher im Laufwerk?  ;)

Der Pufferspeicher ist nur dann ein Problem, wenn durch Leseprobleme, Kratzer usw. bestimmte Stellen in der CD mehrfach gelesen werden müssen.

Ich kann also auch nicht erklären, was da passiert ist...

10

Re: AccurateRip: wie funktioniert es wirklich?!

Hallo,

DanielOcean,13.06.2010, 10:03 schrieb:

Du liegst allerdings falsch dass die o.g. Meldung auch erscheint wenn lediglich ein oder mehrer Tracks als "nicht akkurat" identifiziert werden konnten, lediglich wenn ALLE Tracks dieser CD nicht als akkurat ermittelt wurden, dann erscheint diese Meldung! Somit ist es auch Quatsch wenn du sagst dass bei nur einem Track als "nicht akkurat" es sich grundsätzlich nicht um einer andere Pressung handeln kann weil alles anderen ja gestimmt hätten;

Das wollte ich jetzt nicht so stehen lassen, denn hier hast Du mich missverstanden. Wenn ein Track nicht als akkurat bestätigt wird, dann wird man diesen Track i.d.R. ja nochmal rippen ... aber doch nur den einen und nicht wieder alle. D.h. der zweite Kopiervorgang besteht nur aus einem einzigen Track. Und wenn EAC hier keinen Fehler bemerkt, dann kommt bei mir definitiv die Meldung mit der anderen Pressung, was ja auch logisch ist, denn es stimmen ja "alle" Tracks des zweiten Kopiervorgangs nicht mit AR überein.


DanielOcean,13.06.2010, 10:03 schrieb:

ich habe zB einige CD's bei denen wirklich nur wegen eines Tracks es sich um eine andere Pressung handeln kann! Allerdings erscheint dann die Meldung mir der Pressung NICHT, sondern lediglich der eine Song wird immer wieder - auch nach dem x-ten Ausleseversuch - als "nicht akkurat" gemeldet!

Diesen Fall hatte ich auch schon ein/zweimal und ich habe das auf Kratzer geschoben, die in meinem Fall ein anderes Ergebnis verursacht haben. Das sowohl Test als auch Copy das gleiche "falsche" Ergebnis lieferten hat mit in den paar wenigen Fällen nicht so sehr verwundert, da ich mir durchaus Kratzer vorstellen kann, die den Laserstrahl sehr definiert ablenken und so einen reproduzierbaren Fehler verursachen. So wie ich die Sache verstanden habe, unterscheiden sich andere Pressungen immer in mehreren bzw. allen Tracks und nicht nur in einem.

Spunky

11 bearbeitet von DanielOcean (Original: 2010-06-16 07:52)

Re: AccurateRip: wie funktioniert es wirklich?!

Eines vorweg:
Ich finde es toll wie wir hier diskutieren und uns der Problematik scheinbar Schritt für Schritt nähern - dennoch denke ich dass ich um einen Austausch mit dem Entwickler nicht herum komme um auch die letzten Fragen zu klären. Aber es macht Spaß hier immer neue Aspekte und Sichtweisen zu untersuchen.


Meiner Einer schrieb:

OK, ich denke/hoffe, das ist geklärt.

Is es! Gut dass wir drüber gesprochen haben ;) Für andere Leser sicher ein guter Einwand auch hier ggf eine Fehlerquelle zu vermuten un ggf den Offset nochmal zu korrigieren, am besten mit einem weiteren unabhängigen Tool.


Meiner Einer schrieb:

Zur Datenbank: Gehen wir mal von dem Fall aus, das für eine CD eine ansehnliche Zahl von "Zuversicht X" vorliegt. Jetzt kommt besagte "andere Pressung" ins Spiel. Wenn dort ebenfalls irgendwann mal eine Reihe von erfolgreichen Lesevorgängen vorliegt, dann sollte dieser Wert ebenso gültig sein - aber eben bezogen auf die andere Pressung.
Das heißt, aus Sicht des Programmierers würde ich es zulassen, auch 2 Werte in der DB zu haben. Beim zweiten Wert vielleicht dann mit der zusätzlichen Meldung für den Anwender: "Zuversicht XX, bezogen auf alternative Pressung".
Nur als Beispiel...
Allerdings müßte man dann tatsächlich mal Kontakt aufnehmen.

Nun, da werden wir nicht von alleine hinter kommen, denn wir wissen ja nicht was mit den Daten passiert; ich geht nun erstmal vom worst case aus und denke dass nur ein Wert hinterlegt wird pro ID und alle abweichenden abgelent und nicht gespeichert werden... aber ich bin schon dabei eine Mail zu formulieren... nur halt in Englisch und da bin ich nicht so schnell ;)


Meiner Einer schrieb:

Denn alle anderen Werte, die durch fehlerhaftes Einlesen entstehen, liegen ja im allgemeinen nur ein Mal vor - Unwahrscheinlich, das viele User (vom besagten nicht ermittelten Offset mal abgesehen) immer die gleichen "falschen" Werte bekommen. Wobei es für die Accurate-DB möglich sein müßte, auch abzufragen, ob der Offset überhaupt ermittelt wurde. Ich denke nämlich, das zwischen den Programmierern von EAC und Accurate sowieso schon eine gewisse Kooperation bestehen müßte.

Ja aber genau da liegt doch schon der eine Hund begraben: Wie schafft man es den falschen-Offset-Wert auszuschließen - momentan wohl nicht, also wohl nur mit entsprechender Zusammenarbeit der Tools; eine Abfrageroutine wäre wirklich die beste Lösung! Ich werde es in meiner Mail erwähnen.


Meiner Einer schrieb:

So sehe ich das auch. Wenn man vorhat, sich wieder eine CD daraus zu brennen, so ist damit kein 1:1 möglich. Du hast durch den nicht korrigierten Offset einen Versatz in der TOC.

Richtig, aber eben für ein penibles Archivieren sollte man doch schon auf den Offset achten... wenn man es weiß ;) Ich glaub das Offset-Problem scheitert nur am Nicht-Wissen (und sicher auch zum Teil an inkonsequenten/ignoranten Rippern).


Meiner Einer schrieb:

Da stellt sich gleich wieder die Frage: Wieso können die Hersteller der Laufwerke das nicht gleich von sich aus berücksichtigen/korrigieren? Vor allem, wenn man bedenkt, das zu Zeiten des "leidigen" Kopierschutzes von den Herstellern der Laufwerke alles mögliche unternommen wurde, um diesen Schutz quasi zu "ignorieren". Zumal der Offset pro LW-Type ja wohl einen festen Wert hat.

Na, diese Frage habe ich mir auch schon mal gestellt. Warum zB Fernseher-Hersteller ihre Geräte nicht mit korrekten Parametern ausliefern und somit (eigentlich) eine Kalibrierung durch den Besitzer notwendig, liegt ja an der Serien-Streuung; nur dies tritt ja bei Laufwerken nicht auf das ein Modell ja stets den selben Offset hat... Somit sollte dieses Problem ja abzustellen sein, scheitert aber wohl am mangelnden Interesse - scheint ja nur in diesem/unseren sehr speziellen Fall eine Relevanz zu bestehen.


Meiner Einer schrieb:

Ja, die meinte ich. Ich lasse grundsätzlich immer mit "Teste & kopiere..." einlesen, so das beide Werte in EAC zusätzlich noch verglichen werden. Die AR-DB verwendet tatsächlich andere Berechnungswerte, was aber keine Rolle spielt.

Na, ich denke hier sollten wir auch differenzieren dass es wohl auf der einen Seite den peniblen Ripper gibt - ich nenne ihn mal den Hardcore-Archivierer - der mit teste & kopiere arbeitet, den richtigen Offset verwendet und am liebsten zusätzlich noch den korrekten AR-Abgleich braucht um mit seinem Ergebnis wirklich zufrieden zu sein, und auf der anderen Seite den einfachen Nutzer, der zwar auf lossless wert legt aber (noch) nicht an einer korrekten 1:1-Archivierung mit Feedback; Lediglich den Erstgenannten interessiert diese Diskussion überhaupt, den anderen juckt das wohl nicht die Bohne; somit gehe ich hier bei der Runde nun einfach mal dreist davon aus dass wir uns eher zu den penibleren zählen und auch entsprechenden Aufwand betreiben beim Einlesen unserer Sammlungen, oder liege ich hier falsch?! ;)


Meiner Einer schrieb:

Nein, auf den Gedanken bin ich nämlich auch gekommen...

Dachte ich mir schon... die theoretische Möglichkeit wäre aber da gewesen, aber...:


Meiner Einer schrieb:

Überlegen wir mal:
Zuerst wird der Titel vollständig im Testmodus eingelesen. Dann noch einmal zum speichern. Die Titel sind auf der CD unkomprimiert in einem mit WAVE/AIFF vergleichbaren Format (Der Unterschied ist nur, das sie keinen Header haben und das ein Interleave von 6 verwendet wird - also jeweils 6 Samples Links, 6 Samples Rechts usw. Bei WAVE/AIFF ist das Interleave normalerweise 1 - also ein Sample Links, ein Sample Rechts usw., sofern Du nicht gewaltsam in einem Waveeditor was anderes einstellst).
Das heißt, ein Titel von z.B. 3 Minuten ist somit ca. 30 MB groß (Die Komprimierung nach FLAC findet erst nach dem Lesen auf dem Rechner selbst statt, hat also hierbei nix zu sagen).
Es werden also erst einmal 30 MB vollständig zum testen gelesen und dann diese 30 MB noch einmal zum Speichern. Wie groß war doch gleich noch mal der Pufferspeicher im Laufwerk?

... deine Erklärung klingt für mich absolut einleuchtend, habe ich so noch gar nicht betrachtet. So gesehen würde sich diese Problematik erst ergeben wenn der Puffer also größer wäre wie ein Track; wie groß ist denn ein Puffer in einem Laufwerk, was sind hier schon hohe Werte?!

Apropos: Das mit den Header/Intereave/Samples hab ich jetzt nicht gerafft was das ist...  Also der Unterschied zwischen den auf der DC befindlichen Daten und den Formaten WAVE/AIFF... Magst mich hier etwas mehr aufklären?!


Meiner Einer schrieb:

Der Pufferspeicher ist nur dann ein Problem, wenn durch Leseprobleme, Kratzer usw. bestimmte Stellen in der CD mehrfach gelesen werden müssen.

OK, so gesehen hat der Puffer bzw. die Puffersperre von EAC also doch einen Sinn, denn nach o.g. Problematik hab ich schon fast die Frage im Hinterkopf zusammengebastelt wozu denn dann so ein Aufheben um den Puffer gemacht wird. Aber die Antwort hast du ja logisch geliefert bevor das Anschließende Fragezeichen im Hirn gesetzt wurde ;)

12 bearbeitet von DanielOcean (Original: 2010-06-16 07:57)

Re: AccurateRip: wie funktioniert es wirklich?!

Spunky schrieb:

Das wollte ich jetzt nicht so stehen lassen, denn hier hast Du mich missverstanden. Wenn ein Track nicht als akkurat bestätigt wird, dann wird man diesen Track i.d.R. ja nochmal rippen ... aber doch nur den einen und nicht wieder alle. D.h. der zweite Kopiervorgang besteht nur aus einem einzigen Track. Und wenn EAC hier keinen Fehler bemerkt, dann kommt bei mir definitiv die Meldung mit der anderen Pressung, was ja auch logisch ist, denn es stimmen ja "alle" Tracks des zweiten Kopiervorgangs nicht mit AR überein.

So gesehen hast du natürlich recht, und doch liegst du trotzdem falsch wenn man bedenkt dass doch grundsätzlich ein Album rippt wird; denn selbst wenn man nach einem nicht akkuraten Ergebnis lediglich einen Track rippt (im übrigen rippe ich beim ersten Fehlversuch dennoch das ganze Album nochmal - hat keinen speziellen Grund, hat sich bei mir einfach so "eingebürgert", erst beim dritten oder mehr Versuchen schnappe ich mir lediglich den einzelnen Track, und dann:) und diesen dann als akkurat gemeldet bekommt, korrigiert man doch sicher CUE und LOG entsprechend, sodass diese sich wiederum auf das ganze Album beziehen. Wenn nicht, ist das grundsätzlich nicht falsch und erhält wohl möglich ein Sammelsurium an .flac .cue & .log welche sich ja dann nur auf Teilbereiche des Albums beziehen, doch um eine 1:1-Kopie der ganzen CD bequem und richtig anfertigen zu können ist es doch wesentlich einfacher die beiden Dateien CUE und LOG entsprechend anzupassen.
So gesehen hast du also recht dass der einzelne Track beim zweiten Vorgang quasi als Album gewertet wird und bei nicht-korrektem AR-Abgleich die Meldung mit der Pressung erhält, doch ein Album bleib ein Album, und nur hier kann man letztendlich von einer Pressung sprechen. ;) Ich weiß, sehr kleinliche Sichtweise, aber dennoch richtig und in der hier angesprochenen genaueren Betrachtung um die genaue Arbeitsweise der AccurateRip-Datenbank die einzig penible und zulässige Herangehensweise.


Spunky schrieb:

Diesen Fall hatte ich auch schon ein/zweimal und ich habe das auf Kratzer geschoben, die in meinem Fall ein anderes Ergebnis verursacht haben. Das sowohl Test als auch Copy das gleiche "falsche" Ergebnis lieferten hat mit in den paar wenigen Fällen nicht so sehr verwundert, da ich mir durchaus Kratzer vorstellen kann, die den Laserstrahl sehr definiert ablenken und so einen reproduzierbaren Fehler verursachen. So wie ich die Sache verstanden habe, unterscheiden sich andere Pressungen immer in mehreren bzw. allen Tracks und nicht nur in einem.

Durchaus denkbar dass wirklich bestimmte Kratzer den Laser wirklich so definiert ablenken dass quasi immer das selbe Ergebnis dabei rauskommt. Ich habe aber noch eine weitere Theorie, denn meist fallen diese Ein-Track-nicht-akkurat-Meldungen auf den ersten Track der CD und so gehe ich fast fest davon aus dass der AR-Datenbank-Eintrag wohl mit falschem Offset fixiert wurde (wenn man nun mal davon ausgeht dass tatsächlich nur ein Eintrag, also der erste gespeichert wird und keine weiteren zugelassen werden und auch nicht im Hintergrund gespeichert werden).

Beiträge [ 12 ]

Seiten 1

Sie müssen sich anmelden oder registrieren, um eine Antwort zu verfassen

AudioHQ » Einlesen und Brennen von Audio-CDs » AccurateRip: wie funktioniert es wirklich?!

Ähnliche Themen