Audio-CD aus bereits komprimierten Daten?

Hallo trige,

Mir persönlich ist keine Sofware und auch kein anderer technischer Weg bekannt, der die Quelle einer Audio CD rekonstruieren kann.
Sollten die Quellen mehr oder minder stark komprimierte Audio Dateien (z.B. mp3) sein, kann man das vielleicht hören, aber über den technischen Weg die Quelle heraus zu finden - das wäre mir neu.

Sollte jedoch jemand wissen, wie das geht, lasse auch ich mich nur zu gerne eines besseren belehren.

Gruß

Man könnte z.B. in Foobar das File-Verifier-Plugin drüberlaufen lassen und die CD mit der Accurate Rip Datenbank vergleichen. Wenn du ein "positiv" bekommst, weißt du mit Sicherheit, dass es Original-Musik ist. Bei einem "negativ" bist du aber genau so schlau wie vorher - ob es nur ein einzelnes Bit ist, welches nicht stimmt, oder ob die Musik zwischenzeitlich in MP3 gewandelt wurde wird dir nicht angezeigt.

*Nightwolf* (Beitrag #3) schrieb:

Man könnte z.B. in Foobar das File-Verifier-Plugin drüberlaufen lassen und die CD mit der Accurate Rip Datenbank vergleichen. Wenn du ein "positiv" bekommst, weißt du mit Sicherheit, dass es Original-Musik ist. Bei einem "negativ" bist du aber genau so schlau wie vorher - ob es nur ein einzelnes Bit ist, welches nicht stimmt, oder ob die Musik zwischenzeitlich in MP3 gewandelt wurde wird dir nicht angezeigt.

Jo, Rippen und mittels AccurateRip vergleichen halte ich schon mal für eine gute Idee. Ansonsten gibt es auch diverse Tools, die Dich hierbei unterstützen können, wie etwa Tau Analyzer:

http://en.true-audio.com/Tau_Analyzer_-_CD_Authenticity_Detector

Allerdings liefern diese nicht in 100% aller Fälle korrekte Resultate; die Ergebnisse sind also mit ein wenig Vorsicht zu genießen.

das ganze ist überhaupt kein Problem mit Software wie dem genannten Tau Analyzer oder Audiochecker (nehme ich) - diese Tools suchen nach typischen Artefakten wie sie eine lossy-Komprimierung wie MP3 typischerweise hinterläßt.

Spuckt die Aalysesoftware 100% lossless aus, dann kannst du sicher sein, dass das nicht ein lossy-Codec hier wieder nach lossless umgewandelt wurde...
Spuckt die Software Zweifel aus (in Form von einer Wahrscheinlichjkeitsangabe), dann besteht leider keine 100% sicherheit, dass das Material wirklich aus lossy stammt - in seltenen Fällen interpretiert die software korrektes lossless als lossy (das läßt sich nicht vermeiden, liegt in der natur der sache)..

aber generell kann ich das nur empfehlen, um Musik aus zweifelhaften Quellen zu überprüfen...

AccourateRip bringt da eher wenig - IMHO..

Kumbbl (Beitrag #5) schrieb:

Spuckt die Aalysesoftware 100% lossless aus, dann kannst du sicher sein, dass das nicht ein lossy-Codec hier wieder nach lossless umgewandelt wurde...

Zumindest für Tau Analyzer stimmt das leider nicht (und bei anderen Tools wird's vermutlich ähnlich sein). Es kann sowohl passieren, dass original CD-Tracks als lossy als auch das MP3-Tracks als lossless klassifiziert werden, wie anahnd dieser Testresultate zu sehen ist:

http://en.true-audio.com/Tau_Analyzer_-_Aucdtect_Testing_Results

Kumbbl (Beitrag #5) schrieb:

AccourateRip bringt da eher wenig - IMHO..

Im Falle von Kopien vollständiger CDs (und natürlich nur bei diesen, d.h. nicht bei selbst zusammengestellten CDs) kann AccurateRip sehr viel bringen. Abhängen tut das zu 100% davon, wie die Kopie erstellt wurde. Wurde Exact Audio Copy (oder ein anderes auf DAE spezialisiertes Programm) oder beispielweise auch CloneCD verwendet, klappt die Verifikation mit der ARDB ganz hervorragend. Wurden weniger brauchbare Programme verwendet oder gar zusätzliche Pausen zwischen den Songs eingefügt, sieht's natürlich schlecht aus ...

shaboo (Beitrag #6) schrieb:

Kumbbl (Beitrag #5) schrieb: Spuckt die Aalysesoftware 100% lossless aus, dann kannst du sicher sein, dass das nicht ein lossy-Codec hier wieder nach lossless umgewandelt wurde... Zumindest für Tau Analyzer stimmt das leider nicht (und bei anderen Tools wird's vermutlich ähnlich sein). Es kann sowohl passieren, dass original CD-Tracks als lossy als auch das MP3-Tracks als lossless klassifiziert werden, wie anahnd dieser Testresultate zu sehen ist: http://en.true-audio.com/Tau_Analyzer_-_Aucdtect_Testing_Results

ja, du hast scho recht - ich hätte schreiben sollen "fast 100% sicher sein", denn die Fehl-interpratation bei MP3 (also ein MP3 fälschlich als lossless zu klassifizieren) ist vernachlässigbar - wie auch diese testergebnisse zeigen... und das ist ja der kritische Fall... ubnd darum gings mir,...

shaboo (Beitrag #6) schrieb:

Im Falle von Kopien vollständiger CDs (und natürlich nur bei diesen, d.h. nicht bei selbst zusammengestellten CDs) kann AccurateRip sehr viel bringen. Abhängen tut das zu 100% davon, wie die Kopie erstellt wurde. Wurde Exact Audio Copy (oder ein anderes auf DAE spezialisiertes Programm) oder beispielweise auch CloneCD verwendet, klappt die Verifikation mit der ARDB ganz hervorragend. Wurden weniger brauchbare Programme verwendet oder gar zusätzliche Pausen zwischen den Songs eingefügt, sieht's natürlich schlecht aus ...

ich hab da ein anderes problem: ein test gegen AccurateDB klassifiziert ja einen fehler nicht, sondern sagt ja nur, passt oder passt nicht - und das ist hier nicht zielführend. Denn: eine korrekt lossless gerippte CD (mit oder ohne zusätzliche Pausen), bei der aber auf grund eines minimalen Rippproblems (welches in 99% der fälle unhörbar sein wird) ein "nicht übereinstimmend" mit der DB gereportet wird, ist für mich überhaupt kein problem unter der vom TE aufgeworfenen Fragestellung - denn hier wurden einem keine als lossless bezeichneter lossy-Files untergeschoben

somit ist Accourate Rip für genau diese Fragestellung ungeeignet, weil man im fehlerfall genau so schlau ist wie vorher - und nur im Korrektfall eine verlässliche und aussagekräftige Antwort hat.

BTW: für mich ist AccurateRip sowieso overhyped, denn bei einer durch mich bestmöglich gerippte CD (vernünftige Ripper wie Foobar, EAC, dbPoweramp etc.) aus meinem Besitz hab ich von der antwort rein gar nix - denn was soll ich tun, wenn AR eine nicht übereinstimmung liefert? soll ich mir deswegen ein neues exemplar kaufen, nur weil vielleicht ein minimaler (und unhörbarer) Kratzer die eine Unübereinstimmung verursacht hat? Quatsch... CD geputzt, CD vernünftig geripped und gut ist - was soll der ganze Quatsch mit Bitgenau? aus einer Hörperspektive hat man davon rein gar nix - es verursacht nur ein problemgefühl, wo gar kein problem ist.... Just my 2ct

Kumbbl (Beitrag #7) schrieb:

somit ist Accourate Rip für genau diese Fragestellung ungeeignet, weil man im fehlerfall genau so schlau ist wie vorher - und nur im Korrektfall eine verlässliche und aussagekräftige Antwort hat.

Volkommen richtig, aber auf diese Art und Weise zumindest schon einmal alle Korrektfälle abhaken zu können, ist doch etwas sehr Schönes! Klar ist AR keine eierlegende Wollmilchsau und trägt im Fehlerfall erst einmal gar nichts zur Klärung der Frage lossy oder lossless bei (dafür war es ja auch nie gedacht), aber diese Fälle kann man ja dann noch einmal gesondert unter die Lupe nehmen.

Kumbbl (Beitrag #7) schrieb:

BTW: für mich ist AccurateRip sowieso overhyped, denn bei einer durch mich bestmöglich gerippte CD (vernünftige Ripper wie Foobar, EAC, dbPoweramp etc.) aus meinem Besitz hab ich von der antwort rein gar nix - denn was soll ich tun, wenn AR eine nicht übereinstimmung liefert? ... Was soll der ganze Quatsch mit Bitgenau?

Für mich ist AR alles anderes gehypt und der Nutzen doch wohl ziemlich offensichtlich: Du kannst eine CD einfach im Burst-Modus auf maximaler Geschwindigkeit rippen und Dir - im Falle Bit für Bit übereinstimmender Rips in der ARDB - dennoch sicher sein, einen perfekten Rip zu haben. Secure Mode, langsameres oder schnelleres Auslesen, maximale Fehlerkorrekturstufe und jede sonstige EAC-Spielerei (die bei kratzerfreien CDs eigentlich immer totaler Overkill ist) - all das kannst Du Dir für die (wenigen) Fälle aufheben, in denen AR Abweichungen liefert. Ich habe gerade (mit CUERipper) über 2000 CDs gerippt. Hast Du eine Ahnung, wieviel Zeit AR mir dabei gespart hat? (Ich habe übrigens vor knapp zehn Jahren auch mal über 1000 CDs mit EAC gerippt und weiß, wovon ich rede.)

Wenn AR Dir eine Übereinstimmung liefert, hast Du davon also eine ganze Menge (und sei es nur gesparte Zeit). Und selbst wenn AR Dir nur Abweichungen liefert, kann das - bei korrekter Interpretation des Verifikationslogs - sehr hilfreich sein. Natürlich ist diese Interpretation wichtig, denn es ist nun mal ein Unterschied, ob die ARDB nur ein Exemplar der fraglichen CD enthält (in diesem Falle ist ein abweichendes Resultat kein Grund zur Beunruhigung, denn das ARDB-Exemplar kann ja fehlerhaft oder einfach eine andere Prerssung sein) oder 200 Exemplare. Wenn die dann aber sämtlich in 14 von 15 Songs mit meinem Exemplar übereinstimmen und nur in einem Song kollektiv abweichen, ist die Wahrscheinlichkeit schon recht groß, dass mein Rip dieses Songs fehlerhaft ist. Und wenn CUERipper oder EAC mir beim Auslesen verdächtige Positionen auf der CD anzeigen und sich dieses Ergebnis perfekt mit dem Resultat des AR-Checks deckt, kann ich mir sehr sicher sein, eine fehlerhafte CD und einen fehlerhaften Rip vor mir zu haben - auf jeden Fall (noch) sicherer als dies ohne AR der Fall wäre.

Der Witz an AR ist halt, dass es Dir (zumindest im Falle nicht-superobskurer und gut gepflegter CDs) in 99% eine Übereinstimmung liefert. Wie man mit dem verbleibenden 1% dann umgeht, muss halt jeder für sich entscheiden. Ich unternehme - bei ernstzunehmenden Hinweisen auf einen Fehlrip - in der Regel zunächst einen neuen Ripversuch mit einem anderen Laufwerk und anderer Software (EAC statt CUERipper) und falls das keine Verbesserung bringt, einen Reparaturversuch mit CUETools. Hat die CUETools-Datenbank keine ausreichenden Korrekturdaten für eine Reparatur, höre ich mir den Song einfach an und wenn ich da keinen Fehler höre, dann ist halt gut und ich bin zufrieden. Und wenn da tatsächlich ein hörbarer Fehler sein sollte, muss ich halt selber entscheiden, wie wichtig mir der Song ist. Entscheidend ist hierbei einfach, dass AR die Anzahl potentiell fehlerhaft gerippter Songs so stark reduziert, dass das intensive Auseinandersetzen mit dem verbleibenden 1% zeitlich problemlos machbar ist.

shaboo (Beitrag #8) schrieb:

Für mich ist AR alles anderes gehypt und der Nutzen doch wohl ziemlich offensichtlich: Du kannst eine CD einfach im Burst-Modus auf maximaler Geschwindigkeit rippen und Dir - im Falle Bit für Bit übereinstimmender Rips in der ARDB - dennoch sicher sein, einen perfekten Rip zu haben. Secure Mode, langsameres oder schnelleres Auslesen, maximale Fehlerkorrekturstufe und jede sonstige EAC-Spielerei (die bei kratzerfreien CDs eigentlich immer totaler Overkill ist) - all das kannst Du Dir für die (wenigen) Fälle aufheben, in denen AR Abweichungen liefert. Ich habe gerade (mit CUERipper) über 2000 CDs gerippt. Hast Du eine Ahnung, wieviel Zeit AR mir dabei gespart hat? (Ich habe übrigens vor knapp zehn Jahren auch mal über 1000 CDs mit EAC gerippt und weiß, wovon ich rede.)

ich auch, ich auch (über 1000 CDs im "batch" und damals mit EAC gerippt)

du hast mit allem recht, trotzdem halte ich das für übertrieben, denn
- ich lege eine CD ein
- rippe die mit Foobar im standard secure Mode ohne Speed-Limit
und alles ist gut... die CD ist dann auf der Festplatte so gut es eben ging - wenn Foobar den Ripp ohne Meckern durchführen konnte, dann ist die CD entweder perfekt (= mögliche Artefakte sind unhörbar) auf der Platte, wenn Foobar meckert, d.h. eine warnmeldung liefert, dann kann ich mir das immer noch anschauen, sofern es mir wert ist... wozu brauche ich da Accurate Rip?

Egal, AccurateRip schadet ja auch nix, also brauchen wir uns da ja auch nicht die Köpfe heiss diskutieren - ich kann deinen Ansatz und Argumantation ja eh nachvollziehen (der ja zumindest einen pragmatischen sinnvollen grundansatz hat mit der zeitersparbnis im Burstmnodus), mir persönlich bringt das alles nur nix... für manche hat das Bit-genau ja was von Klangfetischismus, das meinte ich hauptsächlich mit over-hyped....

BTW: 1000de CDs en Block zu rippen ist so oder so ein Scheiss-Job, egal ob mit oder ohne Accurate Rip - gut dass ich hinter mir habe und schon seit jahren nur noch die einzelkäufe rippen muss

AccurateRip wird bei den meisten wohl den Verdacht auf "nicht-Bitgenau" erwecken... AccurateRip ist nicht sonderlich Clever und lässt sich bereits mit 1 anführenden Byte voller nullen in die Irre führen... Obwohl das an der Genauigkeit der eigentlichen Nutzdaten nichts ändert.

Kein DVD / CD / BluRay Laufwerk richtet den Laser 100% korrekt auf den Track-Anfang aus (falscher Offfset). Das reicht AccurateRip bereits aus um eine "nicht-Bitgenau" Meldung zu kreiieren. Meine Meinung: Wer mit EAC, Foobar2000, usw. im Secure-Mode einen problemlosen RIP zieht, der kann sich sicher sein, dass alles OK ist. Egal was AccurateRip sagt.

Einziger Sinn ist tatsächlich sich bei Burst rips nachträglich zu vergewissern, dass der Rip ok war.

Noch eine einfache Möglichkeit wäre, sich das Differenzsignal anzuhören:
Da hört man ziemlich gut, ob es eine MP3 war. Allerdings wird es ab Bitraten von 256kBit/s schon ziemlich schwierig...

HiLogic (Beitrag #10) schrieb:

AccurateRip wird bei den meisten wohl den Verdacht auf "nicht-Bitgenau" erwecken... AccurateRip ist nicht sonderlich Clever und lässt sich bereits mit 1 anführenden Byte voller nullen in die Irre führen... Obwohl das an der Genauigkeit der eigentlichen Nutzdaten nichts ändert. Kein DVD / CD / BluRay Laufwerk richtet den Laser 100% korrekt auf den Track-Anfang aus (falscher Offfset). Das reicht AccurateRip bereits aus um eine "nicht-Bitgenau" Meldung zu kreiieren. Meine Meinung: Wer mit EAC, Foobar2000, usw. im Secure-Mode einen problemlosen RIP zieht, der kann sich sicher sein, dass alles OK ist. Egal was AccurateRip sagt. Einziger Sinn ist tatsächlich sich bei Burst rips nachträglich zu vergewissern, dass der Rip ok war.

Vielleicht sollte man sich ja erst einmal darüber informieren, wie Accurate Rip überhaupt funktioniert, bevor man sich abfällig darüber äußert - eine Mühe, die Du Dir offenbar nicht gemacht hast.

Erstens können viele Ripper heutzutage automatisch den Offset eines Laufwerks ermitteln, so dass im Gegensatz zu früher, wo das eine reine EAC-Spezialität war, offset-korrigierte Rips längst die Regel und nicht länger die Ausnahme sind.

Zweitens ignoriert AR eine bestimmte Anzahl Samples zu Beginn und am Ende jedes Rips schlicht - weil die Verifikation so robuster wird und diese Samples für praktische Zwecke in der Tat irrelevant sind.

Drittens ist AR dazu in Lage, einen korrekten, aber um einen Offset verschobenen Rip zu erkennen. Da kannst Du auch beliebig viele Nullen davor oder hinten dran hängen; das ist AR total egal.

Die (nachweislich falsche) Behauptung, bereits ein nicht korrigierter Offset führe zu einer Nicht-Bitgenau-Meldung von AR lässt mich daran zweifeln, ob Du jemals in Deinem Leben ein AR-Log gesehen hast ...

Aber damit Du nicht dumm stirbst:

...
[AccurateRip ID: 001209b5-009d5bc5-820aec0b] found.
Track [ CRC | V2 ] Status
01 [ae362717|2a4db107] (200+200/678) Accurately ripped
02 [e8cfa06a|ba829ccd] (200+200/673) Accurately ripped
03 [fce3bf74|bc0f6e02] (200+200/668) Accurately ripped
04 [de62fa00|b9f77fff] (200+200/672) Accurately ripped
05 [8546dcf9|bfffa80b] (200+200/671) Accurately ripped
06 [94d91525|ad47105a] (200+200/674) Accurately ripped
07 [613eba84|13f55636] (200+200/670) Accurately ripped
08 [05d1fd41|98ba1eae] (200+200/670) Accurately ripped
09 [ba27eab4|80f693ba] (200+200/670) Accurately ripped
10 [b83f0ed5|c6185fd5] (200+200/669) Accurately ripped
11 [5dc7e936|42a785d0] (200+200/668) Accurately ripped
Offsetted by -1346:
01 [4a6ffc1b] (003/678) Accurately ripped
02 [ee61cbde] (003/673) Accurately ripped
03 [4f38e0c7] (003/668) Accurately ripped
04 [e910040f] (003/672) Accurately ripped
05 [849934ce] (003/671) Accurately ripped
06 [4d823e82] (003/674) Accurately ripped
07 [a8e0bc73] (003/670) Accurately ripped
08 [add41ec4] (003/670) Accurately ripped
09 [a870e8ad] (003/670) Accurately ripped
10 [cf7c557f] (003/669) Accurately ripped
11 [447bb765] (002/668) Accurately ripped
Offsetted by -874:
01 [299feac2] (002/678) Accurately ripped
02 [3a6cdda5] (002/673) Accurately ripped
03 [b914e344] (002/668) Accurately ripped
04 [b731c297] (002/672) Accurately ripped
05 [97684dbc] (002/671) Accurately ripped
...

Das nächste Mal also bitte erst Informieren und dann Rumhupen ...

Kumbbl (Beitrag #9) schrieb:

... für manche hat das Bit-genau ja was von Klangfetischismus, das meinte ich hauptsächlich mit over-hyped....

Das stimmt natürlich; für viele ist das mittlerweile reiner Selbstzweck geworden. Früher hatten wir nur EAC und waren auch glücklich. Und wie zuverlässig EAC ist, habe ich ja jüngst erst gesehen, als ich an die 1000 mit EAC gerippte und gebrannte CD-Rs noch einmal gerippt und mit AR gecheckt habe - mit perfektem Resultat. Für mich geht's bei AR in der Tat in erster Linie um reine Zeitersparnis ...

Kumbbl (Beitrag #9) schrieb:

BTW: 1000de CDs en Block zu rippen ist so oder so ein Scheiss-Job, egal ob mit oder ohne Accurate Rip - gut dass ich hinter mir habe und schon seit jahren nur noch die einzelkäufe rippen muss :*

In der Tat, in der Tat! Bin auch froh, dass ich das demnächst hinter mir habe und nur noch Neuzugänge rippen muss ...

shaboo (Beitrag #12) schrieb:

Die (nachweislich falsche) Behauptung, bereits ein nicht korrigierter Offset führe zu einer Nicht-Bitgenau-Meldung von AR lässt mich daran zweifeln, ob Du jemals in Deinem Leben ein AR-Log gesehen hast ...

Was fährst Du mich so an?! Bei mir hat bereits ein Offset von 5 gereicht, damit AccurateRip den Track als "ungenau" deklariert. Das ist ein paar Jahre her, hat mir aber gereicht AccourateRip nicht mehr zu nutzen. Mal abgesehen davon, dass die meisten CDs meines Musikgeschmacks ohnehin nicht in der Datenbank hinterlegt sind.

Zu der anderen Aussage: Foobar2000 kann z.B. keine automatische Offset Korrektur und selbst in EAC arbeitet diese nicht unbedingt zuverlässig.

Ich werde darüber aber nicht weiter diskutieren, weil es mir schlichtweg sch*issegal ist.

HiLogic (Beitrag #14) schrieb:

Zu der anderen Aussage: Foobar2000 kann z.B. keine automatische Offset Korrektur

ehrlich nicht?! Es gibt aber zumindest einen Button "Auto" in den Foobar-Drive-settings beim Offset... hab aber keine Ahnung, ob der nun gut funktioniert oder nicht - ich hab den Wert für mein Laufwerk im Internet recherchiert und dann eingetragen...