Sie sind bereits Community-Mitglied? Dann loggen Sie sich hier ein!

Auto-Login
Passwort vergessen?


Gerippte CD-Dateien nachträglich mit Accurate Rip prüfen

+A -A
Autor
Beitrag
cr
Moderator
#1 erstellt: 22. Jul 2012, 00:09
Gibt es eine Möglichkeit, nachträglich die in einem Ordner abgelegten CD-Dateien mittels Accurate Rip auf Korrektheit zu prüfen? Oder scheitert dies an den verlorengegangenen Pausenlängen?
*Nightwolf*
Inventar
#2 erstellt: 22. Jul 2012, 09:57
Es gibt ein Plugin für Foobar. Ich glaube, es heißt "File Integrity Verifier". Damit sollte es gehen - rein theoretisch. Bei mir funktioniert das nur in den seltensten Fällen.
ahbed.
Hat sich gelöscht
#3 erstellt: 22. Jul 2012, 10:37
CUETools
j!more
Inventar
#4 erstellt: 22. Jul 2012, 11:53

*Nightwolf* schrieb:
Es gibt ein Plugin für Foobar. Ich glaube, es heißt "File Integrity Verifier". Damit sollte es gehen - rein theoretisch. Bei mir funktioniert das nur in den seltensten Fällen.


Bei mir prüft dieses Plugin nur, ob eine Datei einwandfrei dekodiert werden kann, nicht, ob sie dem Original entspricht. So sie gebildet wurden, gibt es zwar auch die Prüfsummen aus, aber da fehlt dann immer noch der Abgleich mit der Datenbank von Accorate Rip.
ahbed.
Hat sich gelöscht
#5 erstellt: 22. Jul 2012, 12:36
Vielleicht hast du eine alte Version?
http://www.foobar2000.org/components/view/foo_verifier

Es gibt die von dir beschriebene Funktionen "Verify Integrity", das funktioniert mit einzelnen oder beliebig vielen Dateien, sowie "Verify Album with AccurateRip", das funktioniert entsprechend nur mit korrekt gerippten, vollständigen Alben.
j!more
Inventar
#6 erstellt: 22. Jul 2012, 12:45
Danke für den Hinweis - ich schau mir das gleich mal an. Danke auch für den Hinweis auf cuetools, die ja mehr sind als cuetools.

Edit: Ah, man muss das Album markieren, dann klappt es auch mit accurate rip.

Hat hier jemand Erfahrung mit der Reparaturfunktion von cuetools? Ich habe hier eine CD mit einem ziemlich kaputten Track (um die 14.000 Sektoren) und bekomme die mit cuetools nicht repariert - allerdings kommt auch keine Fehlermeldung oder so was.


[Beitrag von j!more am 22. Jul 2012, 12:49 bearbeitet]
cr
Moderator
#7 erstellt: 22. Jul 2012, 22:58
Wenns wirklich wichtig ist: Jemanden mit einem Plextorlaufwerk und Plextools fragen. Ich konnte praktisch alle CDs soweit hinkriegen, dass man nichts davon merkt.
Ausnahme nur dann wenn der Brenner die Spur verliert. Dann kann man noch mit verschiedenen Brennern herumspielen, weil sie sich ja meist unterschiedlich verhalten, oder:

II. Mit einem lesefreudigen Philips-CDP über die Soundkarte. Das geht nach meiner Erfahrung oft noch besser als mit dem Brenner.

Interpolationen lassen sich aber idR in allen oben genannten Fällen nicht vermeiden, wenns wirklich übel aussieht.
*Nightwolf*
Inventar
#8 erstellt: 22. Jul 2012, 23:08
In welcher Form ist der Track denn defekt? Kratzer in der CD-Unterseite könntest du versuchen rauszupolieren, z.B. mit Zahnpaste (immer nur quer zur Leserichtung). Aber: Danach sieht die CD nichtmehr ganz taufrisch aus (etwas matt) und es kann auch nach hinten losgehen, also übernehme ich keine Garantie.
cr
Moderator
#9 erstellt: 22. Jul 2012, 23:10
Anmerkung dazu: Manche Videotheken können maschinell CDs/DVDs polieren (weil die Entlehner oft die DVDs komplett versauen....)
j!more
Inventar
#10 erstellt: 23. Jul 2012, 05:43
Danke für's Input.


*Nightwolf* schrieb:
In welcher Form ist der Track denn defekt?


Kratzer auf der bedruckten Seite , parallel zur Datenspur und damit wohl sehr schwer zu korrigieren. Da ist mit polieren leider nichts zu machen. Meine Hoffnung war (und ist), dass die Korrekturfunktion der cuetools helfen könnte. Die haben in der Datenbank CD-spezifische Dateien hinterlegt, die eine Wiederherstellung fehlerhafter Tracks erlauben sollen.
mightyhuhn
Inventar
#11 erstellt: 23. Jul 2012, 12:24
dafür gibt se "richtige" lösungen: sachen wie zahnpaster usw solte immer sein lassen.

solche geräte hier:
http://www.mercateo....ger-cleantrade-60101
cr
Moderator
#12 erstellt: 23. Jul 2012, 12:26
Wenns nur um einen Track geht, läßt sich der nicht woanders besorgen?
ahbed.
Hat sich gelöscht
#13 erstellt: 23. Jul 2012, 12:37
Ein Kratzer auf der bedruckten Seite lässt sich nicht durch Waschen, Polieren oder sonstwas reparieren, egal ob manuell oder maschinell. Da ist höchstwahrscheinlich die Datenschicht an der Stelle beschädigt, da lässt sich nicht viel machen, wenn die Fehlerkorrektur im CD Player versagt...
cr
Moderator
#14 erstellt: 23. Mai 2015, 20:05
Die AccurateRip Datenbank taugt leider bei Klassik gar nichts.
Von 30 Opern, die sicher korrekt gerippt sind, wurden nicht mal 10 erkannt, bzw. falsch erkannt (einer anderen CD mit denselben Tracklaufzeiten zugeordnet > Ergebnis logischerweise nicht akkurat)

Nicht in der Datenbank sind zB so bekannte Opern wie

Aida/Karajan
Parsifal/Solti
Traviata/Kleiber
von älteren weniger bekannten Aufnahmen ganz zu schweigen
nenkars
Hat sich gelöscht
#15 erstellt: 23. Mai 2015, 23:45
Zum Glück höre ich nicht sehr viel Klassik.

Aber im Ernst, was erwartest du? Die Datenbank existiert zwar seit Jahren, aber für lange Zeit war sie in der absoluten Nerd-Nische versteckt und kaum jemand hat CDs gerippt und die Ergebnisse abgeschickt. Ohne das persönlich zu meinen, aber genau du hast doch auch nie etwas zum Aufbau der Datenbank beigetragen, indem du an deinen Plextor Laufwerken mit Plextor Software festgehalten hast - jetzt hast du deine vermeintlich perfekten Rips, aber wunderst dich, dass du sie nicht mit AR verifizieren kannst. Woher sollten die anderen Ergebnisse denn kommen? Irgendwann müssen die User ja anfangen...

Das ist ungefähr so, wie sie darüber zu beschweren, dass man bei MusicBrainz oder Discogs keine Metadaten findet. Irgend jemand muss eben mal den Anfang machen und die Daten bereitstellen. Und der Vergleich hinkt, denn ich alleine kann bei MusicBrainz eine CD mit perfekten Daten eintragen, aber nur ein Kollektiv an Leuten kann oft genug die gleichen CDs rippen, um eine Signifikanz in der AR Datenbank aufzubauen. Und es tut sich schon sehr viel mehr, seitdem foobar ein ordentlicher Ripper ist, XLD für den Mac was taugt, und auch dBpa über einen erweiterten Benutzerkreis zu verfügen scheint. EAC stirbt aus, aber ich bin sicher, dass selbst über EAC noch viele AR Ergebnisse reinkommen...

In dem Sinne: Es ist nie zu spät und ich hoffe, deine zukünftigen Rips erfolgen mit einem Tool, das auch AR Ergebnisse sendet!


P.S.: Das mit den komplett falsch erkannten Discs erscheint mir etwas spanisch, weil die Tracklaufzeiten ja nicht nur grob auf Sekundenbasis, sondern zumindest auf einigen Samples aufbauen. Wenn da also CDs "verwechselt" werden, müssen sie schon praktisch identisch sein, und dass du ausgerechnet eine ganze Hand voll davon erwischt haben solltest, kommt mir sehr merkwürdig vor. Was hast du denn zum Scannen genutzt, CueTools?
cr
Moderator
#16 erstellt: 23. Mai 2015, 23:57
Je weniger Tracks, desto wahrscheinlicher wird die CD einer mit derselben Struktur zugeordnet, so unwahrscheinlich ist das nicht bei zig 10.000 CDs.
Das Ergebnis ist dann eben nach Checksumme: No Matches oder vermeintlich alle Tracks falsch gerippt.
Habe das mit einer solchen CD verifiziert. Sie ist richtig gerippt, aber es kommt "Nicht akkurat, auch unter Berücksichtigung des Offsets", und das für jeden Track (Text ist auf engl.).
Die, die wirklich vorhanden sind in der Datenbank sind alle korrekt gerippt und in der Regel ohne Offset (Offset kann durch unterschiedliche Pressungen entstehen, das ist nichts Besonderes).
Also, auf das Laufwerk kann ich mich verlassen, bei jeder Stichprobe mit angeblich nicht akkurater Auslesung, kommt raus, dass der Rip fehlerfrei ist.

Fazit: Da so wenige Klassik CDs in der Datenbank sind, ist gleich gescheiter, man rippt mit zuverlässigen Laufwerken und Software, und die Sache hat sich...
Schauen wir dann, was bei den 1000 Pop/Rock CDs rauskommt, wenn ich soweit bin, die Ordner zu prüfen

Es ist einfach unsymmetrisch:
Akkurates Ergebnis heißt, die CD ist korrekt gerippt
Nicht akkurates Ergebnis kann dagegen vieles heißen: Rippfehler, falsche CD zugeordnet, us.

Anders kann man auch nicht erklären, dss zB bei einem 4er Set (zB einer Oper) drei nicht in der Datenbank sind, und eine schon, aber nicht akkurat gerippt.


[Beitrag von cr am 24. Mai 2015, 00:00 bearbeitet]
nenkars
Hat sich gelöscht
#17 erstellt: 24. Mai 2015, 01:13

cr (Beitrag #16) schrieb:
Je weniger Tracks, desto wahrscheinlicher wird die CD einer mit derselben Struktur zugeordnet, so unwahrscheinlich ist das nicht bei zig 10.000 CDs.
Das Ergebnis ist dann eben nach Checksumme: No Matches oder vermeintlich alle Tracks falsch gerippt.
Habe das mit einer solchen CD verifiziert. Sie ist richtig gerippt, aber es kommt "Nicht akkurat, auch unter Berücksichtigung des Offsets", und das für jeden Track (Text ist auf engl.).

Das ist mir schon klar, aber da die CDs ja auf Sample Ebene betrachtet werden, sind die schon auch mit wenigen Tracks sehr schnell sehr eindeutig zuzuordnen. Da müsste mal jemand mit ordentlicher Statistik ran, um auszurechnen, wie da die Wahrscheinlichkeiten sind.


cr (Beitrag #16) schrieb:
Fazit: Da so wenige Klassik CDs in der Datenbank sind, ist gleich gescheiter, man rippt mit zuverlässigen Laufwerken und Software, und die Sache hat sich...

Ich habe auch schon so manche CD gerippt, die nicht in der AR Datenbank war, mit herkömmlichen Laufwerken und Software im Secure Mode, damit fühle ich mich ebenso sicher wie mit den guten, alten Plextors. Bisher wurde ich bei nachträglichen Checks auch noch nie enttäuscht. Das Fazit kann ich für dich persönlich nachvollziehen, da es dir um die eigene, perfekte Kopie geht. Mir bleibt dabei eben nur der Gedanke der Gemeinschaft auf der Strecke, da du mit PlexTools usw. nichts zur Datenbank beiträgst - und das ausgerechnet, wo du offenbar auf raren Schätzen sitzt, deren Prüfsummenin der Datenbank mehr als willkommen wären!


cr (Beitrag #16) schrieb:
Nicht akkurates Ergebnis kann dagegen vieles heißen: Rippfehler, falsche CD zugeordnet, us.

Wie gesagt, falsche CD zugeordnet ist schon extrem unwahrscheinlich. Es wurde lange und viel über die "Offset Accuracy" diskutiert, da Offsetkorrektur für das Funktionieren von AR natürlich eine gigantisch wichtige Rolle spielt. Und obwohl die noch nicht mal besonders hoch liegt, war AR schon immer extrem zuverlässig. Wenn du dir dann nochmal anschaust, wie überhaupt aus den Daten die Prüfsummen für die einzelnen Track errechnet werden, und wie die Kritik daran letztendlich in die Spezifikationen für das seit langem aktuelle ARv2 umgesetzt wurde (sehr lesenswert ein paar Grundlagen bei HA: http://wiki.hydrogenaud.io/index.php?title=AccurateRip), kannst du eigentlich nicht zu einem so simplen Fazit kommen. Irgendwas ist da bei dir im Busch!


cr (Beitrag #16) schrieb:
Anders kann man auch nicht erklären, dss zB bei einem 4er Set (zB einer Oper) drei nicht in der Datenbank sind, und eine schon, aber nicht akkurat gerippt.

Das würde ich eher auf unterschiedliche Pressungen schieben oder tatsächlich nicht akkurat gerippte Discs. Ist mir so auch noch nie untergekommen. Oder ist das ein Set, bei den die vierte Disc auch einzeln vertrieben wurde? Da machen manche Labels nämlich teilweise komische Sachen mit Mischmasch aus Boxsets, in denen Pressungen stecken, die tw. auch in anderen Konstellationen oder einzeln vertrieben werden.

Ich bin bei dem ganzen Thema kein Profi, da ich vor allem die technisch-mathematischen Hintergründe nicht wirklich verstehe und erklären könnte. Vielleicht liest ja jemand mit, der sich mal konkret ein paar deiner "Problemrips" anschauen würde, also insbesondere diejenigen, die angeblich völlig anderen Discs zugeordnet werden - denn das ist doch extrem unwahrscheinlich, so viel verstehe ich zumindest noch.

P.S.: Du hast immer noch nicht verraten, was du zum Prüfen nimmst! Und ob es sich bei den Ergebnissen um ARv1 oder v2 handelt, das wäre ggf. noch sehr interessant.


[Beitrag von nenkars am 24. Mai 2015, 01:15 bearbeitet]
cr
Moderator
#18 erstellt: 24. Mai 2015, 10:38
Opern-Sets können nicht einzeln vertrieben werden und dennoch hatte ich etliche Sets, wo angeblich jeweils eine einzige in der Datenbank war und sich nach Berechnung der Checksummen herausstellte: No Match oder Not Accurate (in jedem Track). Wie gesagt, ein paar so Exemplare habe ich dann noch kontrolliert, haben keine Rippfehler.
Wieso trage ich nicht zur Datenbank bei? Wenn ich vergleiche, werden meine Daten ja geliefert
shaboo
Stammgast
#19 erstellt: 24. Mai 2015, 11:37

cr (Beitrag #16) schrieb:
Fazit: Da so wenige Klassik CDs in der Datenbank sind, ist gleich gescheiter, man rippt mit zuverlässigen Laufwerken und Software, und die Sache hat sich...

Vernünftige Hardware und Software schadet natürlich nie, aber ich sehe wirklich nicht, worin das Problem dabei besteht, dass AR es auch denjenigen ermöglicht, die Qualität ihrer Rips zu überprüfen, deren Ausstattung diesbezüglich vielleicht suboptimal ist. Wenn es etwas gibt, was AR gezeigt hat, ist es eben genau, dass man - bei einer CD in akzeptablem Zustand - in 99,9 Prozent Fälle weder ein Plextor-Laufwerk noch Plextor-Tools noch sonst irgendwas Tolles braucht, um einen perfekten Rip zu bekommen.

Davon abgesehen sollte Dein Fazit auch eher lauten, mit Deinen - fraglos hochwertigen - Rips mit Datenbanken von AR und CT zu populieren. Wer das selber nicht tut, hat aus meiner Sicht absolut null Berechtigung, sich über deren Datenbestand (bei Klassik oder wo auch immer) zu beschweren.


cr (Beitrag #16) schrieb:

Es ist einfach unsymmetrisch:
Akkurates Ergebnis heißt, die CD ist korrekt gerippt. Nicht akkurates Ergebnis kann dagegen vieles heißen: Rippfehler, falsche CD zugeordnet, us.

Bei AR geht es in erster Linie darum, die Korrektheit eines Rips zu bestätigen und sonst nichts weiter, und das tut es sehr gut. Ist ein Rip nicht korrekt, kann AR natürlich die genaue Ursache dafür auch nicht aus dem Hut zaubern; mit ist nicht klar, was Du da erwartest. Klar kann es immer mal passieren, dass eine CD vielleicht doch nicht in der Datenbank ist, aber dieses Problem wäre auf lange Sicht schnell gelöst, wenn sich wirklich alle - auch die manchmal schon ziemlich elitär wirkenden Plextor-Ripper - am weiteren Aufbau der DB beteiligen würden, anstatt sich mit ihrer sagenumwobenen Hardware und der Überzeugung sowieso besser zu Rippen als der Rest der Welt ins stille Kämmerlein zurück zu ziehen (damit meine ich jetzt nicht unbedingt Dich, aber mir kam diese Einstellung schon öfter unter).

Ich habe in den vergangenen zwei Jahren ungefähr 2.500 CDs gerippt und davon fanden sich bestimmt 90% in der AR- und/oder der CT-Datenbank und ich hatte in keinem Falle eine falsche Zuordnung. In einer Hand voll Fälle habe ich dabei sogar die Reparaturfunktion von CUETools genutzt, die ich für einen absolut genialen Einfall halte.

Was ich allerdings auch begrüßen würde, wäre die selbstverständliche Verknüpfung der Audio-Checksummen mit anderen Metadaten, die die Leute beim Rippen einer CD angeben. Auf diese Art und Weise könnte man zu einem Rip nicht nur die Checksummen, sondern auch Album-Titel und -Interpret (vielleicht sogar Katalognummer oder EAN) anzeigen und so eventuelle Falschzuordnungen sofort entlarven.


[Beitrag von shaboo am 24. Mai 2015, 11:41 bearbeitet]
shaboo
Stammgast
#20 erstellt: 24. Mai 2015, 11:40

cr (Beitrag #18) schrieb:

Wieso trage ich nicht zur Datenbank bei? Wenn ich vergleiche, werden meine Daten ja geliefert

Nicht unbedingt. Etliche Programme lesen AR aus, dürfen dort aber keine Checksummen eintragen. (Liegt vermutlich an irgendwelchen Lizenzgebühren.) CUERipper beispielswiese liest und schreibt in die CTDB, übermittelt aber keine Daten an die ARDB, sondern liest nur von dort aus.
cr
Moderator
#21 erstellt: 24. Mai 2015, 12:12
Ich prüfe es mit Foobar, wenn die Daten nicht übernommen werden, tut es mir herzlich leid, aber ich kanns nicht ändern

Was immerhin erstaunlich ist: Die mit Audiobrenner (ohne Abtastratenwandler wie bei einigen frühen Geräten) erstellten CDRs sind bis auf einen Offset von 1/4 Frame (0,25/75 =1/300s; 588 bytes) akkurat. Hängt natürlich auch vom CDP ab, denn nicht alle geben korrekt aus.
Falls die 588 bei ACR wirklich Bytes und nicht Samples sind, sonst wäre es 1 Frame oder 1/75sek..


[Beitrag von cr am 24. Mai 2015, 12:25 bearbeitet]
nenkars
Hat sich gelöscht
#22 erstellt: 24. Mai 2015, 13:18
Es ist so, wie shaboo schrieb: Es wird natürlich nur dann auch an die Datenbank übermittelt und das Ergebnis als solches dort vermerkt, wenn es sich um einen neuen Rip handelt. Allerdings liegt das nicht an Lizenzgebühren o.Ä., sondern an ganz anderen, viel offensichtlicheren Gründen...

Denkt doch mal nach: Ansonsten rippt ein einziges mal irgendein Heinz mit seinem kaputten Laufwerk eine miese CD-R Kopie der neuesten Britney Spears CD, die verbreitet sich übers Netz, jeder checkt die dann mit AR und jedes mal würde das gleiche "korrekte" Ergebnis mitgeteilt (oder zumindest "ähnlich" falsche durch Virtual Drive rips, nochmals gebrannte CD-Rs, oder was man sonst noch so lustiges anstellen kann) - das würde die Idee sehr schnell ad absurdum führen. Die Datenbank lässt sich nur dann aufbauen, wenn die Daten auf einem möglichst großen Pool direkt ermittelter Daten basieren: Verschiedene Pressungen, Laufwerke, Programme und natürlich auch Settings!

Deshalb ist die CTDB auch nur eingeschränkt mit AR zu vergleichen, auch wenn sie durch die erweiterten Reparaturmöglichkeiten natürlich noch zusätzliche, interessante Aspekte liefert. Dort wird eben jeder Scan mitgeteilt, auch wenn es sich um die tausendste, identische Raubmordkopie handelt...

"Ändern" kannst du das, wenn du zukünftig gleich einen ordentlichen Ripper benutzt, der AR unterstützt. Nicht diese Windows 2000 Ära PlexTools Grütze. Prüfen mit foobar ist gut, mittlerweile macht das ja auch Offset-Vergleiche und berichtet übersichtlich darüber, das konnte eine Zeit lang nur CueTools, welches ich nach wie vor persönlich bevorzuge, weil ich mir auch gleich .accurip Dateien in ein separates Verzeichnis schreiben lassen kann.

Übrigens ein Hinweis am Rande, eigentlich gehört das in den foobar Sammelthread: Seit Anfang des Jahres wurde auch der "Binary Comparator" von foobar etwas aufgewertet, wenn man damit Dateien in foobar vergleicht. Viele Jahre war das ein simples Tool, was schon bei einem umgekippten Bit Alarm geschlagen hat. Das macht es immer noch, aber es berücksichtigt jetzt auch Offsets. Man kann damit also auch Dateien oder Rips komfortabel vergleichen, wenn man Datenbanken dabei völlig aus dem Spiel lässt.

Schade, dass man nicht die Zeit zurück drehen kann, um ARv2 oder etwas vergleichbares früher zu erfinden und gleich mit in jedes Ranz-Tool einzubauen, von iTunes über den WMP, Audiograbber und CDex, und sogar Goldöhrchen-Gelddruckmaschinen wie Amarra. Es profitieren am Ende alle davon, weil letztendlich geht es ja schlicht um das "perfekte" Kopieren bzw. Archivieren von Audio.
Wie gesagt, wir befinden uns da auch heute noch in einer Nische. Auf dem Mac hat man eigentlich nur mit XLD ein vergleichbares Tool zum Rippen und Konvertieren in der Hand. Bei freier Software und für Linux sieht es leider sehr, sehr mau aus. Da gibt es zwar vereinzelt Bibliotheken wie cdparanoia, die verwendet werden, aber so "Komplettpakete" gibt es kaum. morituri ist als Ripper ein interessantes Konzept, das unterstützt auch AR (wobei ich auch da nicht weiß, ob es nur vergleicht, oder auch Ergebnisse sendet), aber hat nicht einmal ein grafisches Interface. Wir jammern also schon auf verdammt hohem Niveau mit unseren Windows-Wehwehchen.
cr
Moderator
#23 erstellt: 24. Mai 2015, 14:00

Ansonsten rippt ein einziges mal irgendein Heinz mit seinem kaputten Laufwerk eine miese CD-R Kopie der neuesten Britney Spears CD, die verbreitet sich übers Netz, jeder checkt die dann mit AR und jedes mal würde das gleiche "korrekte" Ergebnis mitgeteilt


Wieso, die Wahrscheinlichkeit, dass wer anderer genau dieselben Fehler hat ist Null.
Wie soll zudem ACR erkennen, ob eine CDR oder ein Original die Basis ist? Zudem sind auch CDRs bitidentisch zum Original, wenn sie korrekt gebrannt wurde. Und was wäre mit OriginalCDs, die einen Fehler haben? Wie soll das ACR erkennen, wenn der Erste so was hochlädt?


Nicht diese Windows 2000 Ära PlexTools


Warum sollte ich, wenn der fehlerfrei rippt? Dass ich dann bei jeder 2, CD nochmals rippen muss, weil es keinen Eintrag gibt? Sicher nicht.


[Beitrag von cr am 24. Mai 2015, 14:04 bearbeitet]
cr
Moderator
#24 erstellt: 24. Mai 2015, 14:09
Aber um wieder einen anderen Aspekt zu betrachten:

Es überrascht mich, dass sehr verbreitete CDs, wie teils von Karajan, Harnoncourt, Pinnock nicht in der Datenbank sind, jedoch recht ausgefallene schon (zB Hungaroton mit völlig unbekannten Interpreten, die Symphonien von Arnold usw....)

Man hat fast den Eindruck, Karajan wurde nie gerippt (nur von nicht-technikaffinem Publikum gekauft?). Wäre das die Erklärung? Dasselbe für Opern? Opernhörer kopieren nicht und hören nicht via Festplatten?


[Beitrag von cr am 24. Mai 2015, 14:10 bearbeitet]
nenkars
Hat sich gelöscht
#25 erstellt: 24. Mai 2015, 14:42

cr (Beitrag #23) schrieb:
Wieso, die Wahrscheinlichkeit, dass wer anderer genau dieselben Fehler hat ist Null.

Du hast mich falsch verstanden, oder ich habe mich nicht deutlich genug ausgedrückt: Wenn du den gleichen Rip vergleichst, dann ist die Wahrscheinlichkeit, dass dieser die gleichen Fehler enthält oder nicht enthält genau 100% und nicht Null.
Es macht nur Sinn, frische, verschiedene Scan Ergebnisse in die Datenbank zu submitten. Wenn du immer wieder das gleiche Ergebnis des gleichen Rips hochlädst, dann verzerrst du doch nur das Bild, weil du die Anzahl der Samples vergrößerst, obwohl es sich eigentlich immer wieder nur um das eine, identische Sample handelt.


cr (Beitrag #23) schrieb:
Wie soll zudem ACR erkennen, ob eine CDR oder ein Original die Basis ist? Zudem sind auch CDRs bitidentisch zum Original, wenn sie korrekt gebrannt wurde.

Man kann natürlich perfekte Kopien herstellen. Aber es gibt üblicherweise eine bestimmte Anzahl an Pressungen, die sich in der Regel nur durch Offsets unterscheiden. Da AR eine Offset Korrektur eingebaut hat, kann man schon gewisse Rückschlüsse ziehen, wenn man einen Rip vergleicht, von dem man weiß, dass er mit korrektem Laufwerks Offset erstellt wurde, aber die Datenbank ausschließlich Ergebnisse hoher Signifikanz mit anderen Offsets zurück liefert...


cr (Beitrag #23) schrieb:
Und was wäre mit OriginalCDs, die einen Fehler haben? Wie soll das ACR erkennen, wenn der Erste so was hochlädt?

Gar nicht. Das geht über die Masse, letztendlich über die Signifikanz in der Statistik.


cr (Beitrag #23) schrieb:

Nicht diese Windows 2000 Ära PlexTools


Warum sollte ich, wenn der fehlerfrei rippt? Dass ich dann bei jeder 2, CD nochmals rippen muss, weil es keinen Eintrag gibt? Sicher nicht.

Weil einerseits andere Leute mit anderer Software und herkömmlichen Laufwerken schon genau so lange fehlerfrei rippen, und es andererseits schade ist, wenn sich eine bestimmte Benutzergruppe lokal abschottet, obwohl es dank Internet problemlos möglich wäre, über grenzen hinweg weltweite Datenbanken aufzubauen. Plextor ist ein asiatisches Unternehmen, aber haben deren Brenner (außer im professionellen Bereich!) außerhalb Deutschlands und Frankreichs wirklich eine große Rolle gespielt? Ich habe vor allem im amerikanischen und englischen Markt Plextor nie wirklich so wahrgenommen, wie z.B. hier im HiFi Forum unter den deutschen Spezis. Das meine ich nicht anklagend oder so, bitte nicht falsch verstehen, aber es ist schade, dass da eine solche Diskrepanz geherrscht hat. Jetzt ist es eben zu spät. es haben viele Leute PlexTools benutzt - was ja völlig in Ordnung ist, es war ja damals ein tolles Programm für Spezialfälle - nur jetzt wundert man sich, dass die früher skeptisch beäugte AR Datenbank nicht so vollständig ist, wie man sie vielleicht gerne hätte. Ich kann es mir auch nicht ganz erklären, außer, dass Deutsche selbst bei Software sehr skeptisch sind, schon wenn es um Programme geht, die eben mal kein eingedeutschtes User Interface bieten. Wie oft wird danach für foobar wirklich noch gefragt? Und jeder, der foobar halbwegs gewohnt ist, sollte einschätzen können, dass es für die Bedienung letztendlich überhaupt keinen Unterschied macht, ob man vom "Converter" oder "Umwandler" spricht.. Aber jetzt schweife ich ab, sorry.

Wie gesagt, mit Klassik habe ich selbst kaum Erfahrungen, deshalb fällt es mir schwer, irgendwelche Theorien aufzustellen, warum Karajan in der Datenbank vielleicht etwas zu kurz kam.
Kann sich ja noch ändern... Aber der Zug ist mittlerweile wahrscheinlich auch abgefahren. Die Zukunft der digitalen Musik liegt nicht in CDs. Man müsste mal an Zahlen kommen, wie es mit der AR Datenbank statistisch aussieht. Das größte Wachstum liegt sicher schon eine Weile zurück...
cr
Moderator
#26 erstellt: 24. Mai 2015, 14:47
Sorry, habe mich vertan


[Beitrag von cr am 24. Mai 2015, 15:46 bearbeitet]
cr
Moderator
#27 erstellt: 24. Mai 2015, 15:49
Die Beliebtheit von Plextor liegt daran, dass das SCSI-Laufwerk praktisch das erste war, das zuverlässig rippte.
Ferner waren sie die ersten, die interpolieren konnten, was dann wegen des dämlichen Kopierschutzes an Bedeutung gewann..... Man konnte einfach alles rippen, egal wie verhunzt die CD war.

Und nicht zuletzt das c1/c2 bzw. PIE, POE, PIF, POF-Analysetool


[Beitrag von cr am 24. Mai 2015, 15:50 bearbeitet]
nenkars
Hat sich gelöscht
#28 erstellt: 24. Mai 2015, 20:59
Will ich doch auch gar nicht bestreiten. Nur spielen die Laufwerke eben heute überhaupt keine Rolle mehr, nicht mal mehr in der Nische. Einerseits ist das vielleicht traurig, andererseits brechen eben auch andere Zeiten an...
cr
Moderator
#29 erstellt: 15. Jun 2015, 16:21
Ursachen, warum ein Album (=Ordner mit den Audiotracks einer CD in richtiger Reihenfolge oder Image mit Cuesheet) auf der Festplatte nachträglich nicht gefunden wird

1. Das Pregap des 1 Tracks fehlt (entfällt bei Image/Cuesheet)
2. Es ist eine CD-Extra (=CD mit Datensession) und dessen Länge fehlt
3. Es liegt ein Hidden Track vor (entfällt bei Image/Cuesheet)

Mehr als 50% der Ordner konnte ich bisher nicht verifizieren
a) nicht in der Datenbank auffindbar
b) es werden Prüfsummen gebildet, aber dann kommt: No Matches
c) die CD ist nicht akkurat (warum?: a) CDR, wo der Audiobrenner einen Abtastratenwandler hatte oder der CDP nicht bitidentisch ausgab, b) CD, aber andere Pressung, die nicht in der Datenbank ist)

Ferner gibt es 2 AR-Datenbanken, die ältere AR1 bezieht bei der Prüfsummenbildung nur 97% der Audio-Daten ein, was eigentlich heißt, dass ein angeblich akkurates Ergebnis noch lange nicht wirklich akkurat sein muss. Foobar verwendet leider die alte Datenbank AR1. Keine Ahnung, ob inzwischen die Prüfsummen für beide Datenbanken gerechnet werden oder nur mehr in die neue kommen, dann würden natürlich viele CDs mit Foobar nicht auffindbar sein.

Außer mit Foobar kann man (angeblich) nur noch mit CueTools nachträglich Ordner prüfen.
Weiß wer, ob man mit Cuetools auch CDs findet, die man mit Foobar nicht findet? Cuetools soll die neuere Datenbank verwenden und mit ein paar Tricks auch CDs auffindbar machen, die einen Datentrack hinten dran hatten....


[Beitrag von cr am 15. Jun 2015, 16:23 bearbeitet]
shaboo
Stammgast
#30 erstellt: 15. Jun 2015, 21:53

cr (Beitrag #29) schrieb:

Außer mit Foobar kann man (angeblich) nur noch mit CueTools nachträglich Ordner prüfen.
Weiß wer, ob man mit Cuetools auch CDs findet, die man mit Foobar nicht findet? Cuetools soll die neuere Datenbank verwenden und mit ein paar Tricks auch CDs auffindbar machen, die einen Datentrack hinten dran hatten....[/b]

Ich rippe und verifiziere seit Jahren nur mit CUERipper/CUETools (foobar nutze ich gerne zum Verwalten und zum Abspielen) und hatte da bislang nie Grund zur Klage: Von der ARDB werden sowohl v1 als auch v2 verwendet (und außerdem zusätzlich auch noch die CTDB); das Verifikationslog ist sehr ausführlich (ausführlicher als bei foobar) und Du brauchst für Data Tracks auch überhaupt keine Tricks. Wenn Du eine CD rippst, bei der der Data Track fehlt (weil Du sie ohne Data Track von der Original-CD gerippt und das Resultat auf eine CD-R gebrannt hast), merkt CUETools das sofort und gibt das auch entsprechend aus. (Diesbezüglich besitzt die CTDB Riesenvorteile gegenüber der ARDB.)

Ich habe beispielsweise vom 98er-Remaster des Iron Maiden-Debüts zwei CD-Rs. Die eine habe ich mit EAC (ohne Data Track) gerippt. Verifikation mit der CTDB ergibt hier:

[ CTDBID ] Status
---> [1117f7ea] (010/195) Accurately ripped
[f81c26ff] (163/195) CD-Extra data track length 19:38:68, Accurately ripped
[95002c3a] (016/195) CD-Extra data track length 19:40:68, Accurately ripped
[a1a2851e] (001/195) CD-Extra data track length 19:38:68, No match
[791fdc80] (002/195) CD-Extra data track length 19:42:68, Accurately ripped
[9de62b57] (001/195) CD-Extra data track length 19:38:66, Accurately ripped
[b24b6794] (001/195) No match
[348a00d5] (001/195) CD-Extra data track length 19:40:70, No match

Wie man sieht, akkurat gerippt, ohne Data Track, mit zehn Übereinstimmungen (aber auch mit zahlreichen Übereinstimmungen mit anderen Rips, die einen Data Track beinhalten, da die Audiodaten identisch sind).

Die andere habe ich direkt mit CloneCD angefertigt und dabei auch den Data Track mit kopiert. Verifikation mit CTDB ergibt hier:

[CUETools log; Date: 10.01.2014 16:53:10; Version: 2.1.5]
---> CD-Extra data track length 19:38:68.
[CTDB TOCID: qvXBZ4mBrhTbvmSOLdWSZjPFGpE-] found.
[ CTDBID ] Status
[1117f7ea] (011/197) Has no data track, Accurately ripped
---> [f81c26ff] (164/197) Accurately ripped
[95002c3a] (016/197) , Accurately ripped
[a1a2851e] (001/197) No match
[791fdc80] (002/197) , Accurately ripped
[9de62b57] (001/197) , Accurately ripped
[b24b6794] (001/197) Has no data track, No match
[348a00d5] (001/197) , No match

Akkurat gerippt, mit einem Data Track der Länge 19:38:68 und 164 Übereinstimmungen. (Die Accurately ripped-Zeilen, die mit einem Komma beginnen, zeigen Rips an, bei denen die Audiodaten übereinstimmen, deren Data Track-Längen aber variieren.)

Alles ganz unmagisch


[Beitrag von shaboo am 15. Jun 2015, 21:55 bearbeitet]
cr
Moderator
#31 erstellt: 15. Jun 2015, 22:48
Muss ich mal schauen, ob ich hier zusätzliche Verifikationen bekomme, wo bei Foobar nichts gefunden wird.
Je nach Genre habe ich nur 40 bis 60% Treffer (wobei ich nur von OriginalCDs und sicher einwandfrei erstellten CDRs ausgehe)
cr
Moderator
#32 erstellt: 16. Jun 2015, 01:53
Allerdings, soweit ich das jetzt sehe, geht es ohne Cuesheet oder Gesamtimage statt der einzelnen Tracks eh nicht...
shaboo
Stammgast
#33 erstellt: 16. Jun 2015, 06:18

cr (Beitrag #32) schrieb:
Allerdings, soweit ich das jetzt sehe, geht es ohne Cuesheet oder Gesamtimage statt der einzelnen Tracks eh nicht...

Ich habe auch schon mehrfach einfach nur die gerippten Tracks eines Albums verifiziert (d.h. ein File pro Track, ohne Hidden-Track-One-Audio, ohne Gesamtimage und ohne CUE-Sheet) und das hat anstandslos funktioniert. Voraussetzung ist halt nur, dass die Tracks non-compliant (d.h. mit Pausen angehangen an den vorhergehenden Track) gerippt wurden, aber das ist - so weit ich weiß - grundsätzlich Voraussetzung bei ARDB und CTDB, sofern man kein Image verwendet.


[Beitrag von shaboo am 16. Jun 2015, 11:51 bearbeitet]
cr
Moderator
#34 erstellt: 21. Jun 2015, 22:14
Hat man eine bessere Wahrscheinlichkeit, dass die CD vorhanden ist, wenn man Cuetools statt Foobar nimmt? Oder ist in der AR1 eh viel mehr drinnen als in der AR2?

Mit Klassik ist das echt ein Krampf.
Habe zufällig 3x dieselbe Ausgabe (also keine späteren MidPrice etc..) vom Fliegenden Holländer greifbar
CD1 ist bei allen dreien unterschiedlich, CD2 ist bei 2en gleich, und keine einzige Version ist in der Datenbank...


[Beitrag von cr am 21. Jun 2015, 22:37 bearbeitet]
cr
Moderator
#35 erstellt: 12. Jul 2015, 17:07
Nachdem ich ca 1500 CDs geprüft habe.

Das Foobar Tool ist eher ein Jux, denn brauchbar. Bei Klassik war die Trefferrate weit unter 50%, ganz bekannte CDs von Karajan, Solti, Chailly, Giulini etc waren nicht verfügbar (ich weiß, dass es da oft mehrere Pressungen gibt, aber trotzdem, dass von 30 Solti-CDs gerade mal eine auftaucht, ist schon dürftig). Am ehesten fand ich noch Telarc und Naxos CDs. Auch bei Pop war die Trefferquote nur mäßig über 50%.
Ganz anders bei Cuetools: Hier habe ich vom Rest an die 80% gefunden, dh. mit Cuetools hätte ich 90% gefunden. Die nicht auffindbaren obigen Klassik-Bestseller konnten bei Cuetools teils mit Konfidenzen von 10-50 bestätigt werden, wobei man die Treffer eher in der CTDB fand als in der AR2.
Eine fehlerhafte CD mit 100 E32 konnte in der Tat sogar repariert werden......

Jedenfalls: Man kann nur hoffen, dass auch Foobar hier in Zukunft was Brauchbares anbietet, das derzeitige Tool ist wohl eher zum Vergessen. Besser als nichts, aber auch nicht mehr.

Was mir leider nicht gelang: Dass Cuetools als Dateiname des Logs den Namen des Ordners nimmt, wo die Tracks liegen. Es nahm immer den Namen des ersten Tracks. Geht das irgendwie?


[Beitrag von cr am 12. Jul 2015, 17:10 bearbeitet]
Suche:
Das könnte Dich auch interessieren:
EAC und Accurate Rip - Einstellungsfehler?
*Nightwolf* am 18.06.2012  –  Letzte Antwort am 19.06.2012  –  4 Beiträge
accurate cue+wav (EAC) nachträglich in wavpack encoden
uwedamm am 10.10.2012  –  Letzte Antwort am 12.10.2012  –  5 Beiträge
Welches Rip-Programm für CD-->ALAC - iTunes, foobar2000 oder doch EAC? (Archivierung!)
Music-Holic am 05.06.2012  –  Letzte Antwort am 31.12.2014  –  73 Beiträge
High Res Audio Dateien - analysieren + prüfen
Rainbow1 am 08.07.2014  –  Letzte Antwort am 09.07.2014  –  3 Beiträge
Frage an die Rip-Profis
Spike_muc am 04.07.2008  –  Letzte Antwort am 01.04.2013  –  82 Beiträge
Rip-Vorgang verbessern / tunen - Voodoo?
Bartók-Fan am 22.02.2013  –  Letzte Antwort am 22.02.2013  –  3 Beiträge
Gebrannte CDs der EAC-Accurate-Rips werden nicht als Accurate verifiziert!
Pittylabelle am 22.10.2013  –  Letzte Antwort am 12.11.2013  –  7 Beiträge
.wav Dateien umbenennen mit freedb
Manfred_K. am 02.02.2013  –  Letzte Antwort am 05.03.2016  –  13 Beiträge
Flac-Rip fehlerhaft, aber Abspielen der CD funktioniert?
HartWieStein am 07.08.2013  –  Letzte Antwort am 11.08.2013  –  9 Beiträge
Kann man FLAC nachträglich checken?
kai_od am 15.11.2008  –  Letzte Antwort am 30.07.2012  –  30 Beiträge

Anzeige

Produkte in diesem Thread Widget schließen

Aktuelle Aktion

Hersteller in diesem Thread Widget schließen

  • SEG

Forumsstatistik Widget schließen

  • Registrierte Mitglieder807.269 ( Heute: 39 )
  • Neuestes MitgliedStv737
  • Gesamtzahl an Themen1.345.384
  • Gesamtzahl an Beiträgen17.664.435