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

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

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.

Habe ich das?

und

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

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?

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.

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.

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.

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

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.

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.

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

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.

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

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.

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?! ;)

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

... 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?!

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