CDs bitgenau rippen, dieses prüfen, bitgenau ausgeben und dieses beweisen

Zum Ersten möchte ich die Daten der CD Bitgenau Kopieren und auf der Festplatte abspeichern. Die Freeware Exact Audio Copy (EAC)ist, wie ich gelernt habe, wohl das geeignetste Programm, um einen bitgenaue Kopie zu erzeugen.
Deswegen habe ich mir das Programm besorgt und erste CDs eingelesen. Dabei konnte ich nützliche Infos aus einigen alten Tutorials ziehen, die mir empfohlen wurden:

http://www.audiohq.de/index.php?showtopic=47

http://www.audiohq.de/index.php?showtopic=428

Danach habe ich das Laufwerk eingereichtet, das vorgeschlagene Preset habe ich nicht geladen, da hier der Schwerpunkt (wie sooft) auf Dateikompression lag. Ich möchte einfach nur Wavedateien erzeugen.

Doch verschiedene Dinge sind mir nicht klar:

1. Warum werden alle Dateien, die eigentlich als WAV. abgelegt werden sollten als "Windows Audio" abgelegt ? Habe ich irgendeine Voreinstellung falsch eingestellt ?

2. Ich kann die Sample Offsetkorrektur nicht durchführen, da die Downloadlinks für Accurate Rip aus dem Tutorial von 2004 veraltet sind. Der Ofset für mein Laufwerk ist in der Liste nicht aufgeführt. Selbst wenn ich einen Wert von Hand in das Feld in EAC (EAC / Laufwerkseinstellungen / Offset /Geschwindigkeit) eintragen möchte, muss ich ja erst den Haken vor "Benutze Accurate Rip mit diesem Laufwerk" entfernen. (Was ja wiederum keine belastbaren Ausleseergebnisse verifizieren würde) gibt es da andere Wege ?

3. Wenn ich die CD fertig gerippt habe, erscheinen folgende Ergebnisse:



davon sind die Begriffe wie "Spitzenpegel" und "Trackqualität" klar. Ist es jedoch richtig, dass die Trackqualität, selbst wenn sie etwas unter 100 % liegt nichts über den Riperfolg aussagt, da ggf. mehrfach ausgelesen wurde ?
Dann kommt die Aussage "Akkurat" gelesen, die (so wie ich die Sache verstanden habe) aussagt, das eine Prüfsumme des Tracks mit der anderer User verglichen wurde und übereinstimmt.
Was bedeutet der Text "Zuversicht 200" oder was genau sagt die 200 aus ?
Ist der Code der danach kommt die sog. Prüfsumme ?

Ich würde mich sehr freuen, wenn jemand, der mehr Erfahrung mit dem bitgenauem Rippen hat mir helfen könnte.

Ad 1. Die .wav-Dateien werden auch als Windows Audio bezeichnet

Ad 2. EAC ermittelt die Offset-Korrektur automatisch (siehe EAC - Laufwerkseinstellungen - Offset - Schalter "Erkenne")

Ad 3. Akkurat gelesen (Zuversicht 200) bedeutet: Über 200 Anwender haben die gleiche CD ebenfalls geripped, und die Prüfsumme stimmt mit deren überein. Damit kannst Du davon ausgehen, daß bit-identisch geripped wurde.

Erstmal zu Frage 3:

Soweit ich mich erinnern kann, werden die Werte wie folgt beeinflusst.

Trackqualität:
Gibt an, wie hoch der Anteil der Fehlerkorrektur vom Track war.

EDIT: bzw. zu welchem Anteil natürlich nicht korrigiert worden ist, da 100% = keine Korrektur.

Dies hat nichts mit Lesefehler zu tun. Diese entstehen nur, wenn die Fehlerkorrektur keinen Wert mehr ermitteln kann.

Och seh grad,RoA hat den Rest geschtrieben

Hallo,

RoA hat ja schon die wichtigsten antworten geliefert.
2 sachen noch von mir:
Wenn du bei 'normalisieren' ein Häckchen gemacht hast - wieder raus.
Wenn du als Flac Comprimierst, hast Lossless gespeichert UND kannst die gerippten Files richtig mit Tags versehen.
Hat enorm viele Vorteile gegenüber der Speicherung als .wav. Die Ersparnis beim Platz ist da eher ein Nebenprodukt.

Danke für die schnellen Antworten.

1. WAV. = Windows Audio, ok ich habe mich sehr gewundert, da vor der Installaation von EAC die WAV. Dateien auch als solche angezeigt wurden. Nun ha be ich in den odner eigene Musik geschaut, in dem ja 2 Audiotracks liegen, dieser werden nun auch als Windows audio angezeigt. Also nur ein Unterschied im Dateinamen.

2. Bei den Offseteinstellungen von EAC wird folgendes angezeigt:



bei Verwendung von AkkurateRip wird die Sample Offset Korrektur von EAC inaktiv. Es wurde dort zwar auch automatisch ein Wert ermittelt (+102), mit dem jedoch nicht gearbeitet wird.
Entferne ich nun das Häkchen bei "Benutze AkkurateRip mit diesem Laufwerk" und versuche es mit dem Button "Erkenne Sample-LeseOffset Korrektur", erscheint folgendes Fenster: Das besagt, dass sich mit der Audio-CD im Laufwerk kein Wert ermitteln lässt, da die CD nicht in der Datenbank erfasst ist. Ich konnte bis jetzt keine geeignete finden.



Dennoch werden exakte Kopien gemacht. Ist es richtig, dass die Aussage "Akkurat gelesen" bei der Verwendung mit dem falschen oder ohne Smaple Offset Korrektur (SOK) garnicht angezeigt würde ?
Arbeitet das System nun mit einem Sample Offset der von AkkurateRip automatisch ermittelt wurde ?

Ich möcht ja nur sichergehen, dass mit dem richtigem Sample Offset gearbeitet wurde.

Ich befürchte, dass die alten Totorials in diesem Punkt eher Verwirrung stiften, da dort auf getrennte Installation von AR und EAC, Händiges Einbetten von AR in EAC, eigenes Ermitteln von SOK in AR und veraltete Installaions links verwiesen wird.

Ich denke mal, dass sich dort einges geändert hat seit 2004 da AR schon mit EAC installiert wurde.
Es interessiert mich trotzdem, wann und wo das Ermitteln der SOK passiert ist, und wie ich diesen Wert, der ja wie sich vermuten lässt mit AC ermittelt wurde, anzeigen lassen kann ?

Ich hoffe, ich ermüde euch nicht mit den Detailfragen, ich möchte nur sichergehen, dass bis hierhin das Signal bitgenau und in einer Vergleichbaren Form, eben ohne Sampleversatz vorliegt.

E: wird es nicht höchste Zeit für ein neues Tutorial ?

Unter Umständen habe ich zu viele Frage zu ungenau gestellt. Darum erneut ein Versuch:

1. Wie ist die Zeile auf dem Bild bei Track 19 zu verstehen ?
Es wurde eine andere Prüfsumme ermittelt. Trotzdem Zuversicht 10 und Kopie ok ?

2. Wie wird die Prüfsumme generiert ? Ist sie der Beweis für die bitgenaue Kopie ? Oder anders gefragt, reicht dieser 8 Stellige Code aus, um alle Bits eines Tracks zu prüfen ?

3. Ändert sich die Prüfsumme, wenn die Sampleoffsetkorrektur nicht richtig ermittelt wurde, bzw ein anderes Sampleoffset eingestellt wurde ?

Sorry, aber hier fehlt einfach grundlegendes Wissen.

Es empfiehlt sich eine Lektüre in Wikipedia: http://de.wikipedia.org/wiki/Pr%C3%BCfsumme

ad 1) Die Prüfsumme stimmt nicht mit der Accurate-Rip-Database überein. Ob der Unterschied nur in einem einzigen Bit oder 1000en von Bits besteht, läßt sich nicht sagen. Es kann also durchaus sein, daß die Unterschiede unhörbar sind. In derartigen Fällen bietet es sich an, das betreffende Stück nochmal zu rippen, und zwar im sicheren Modus

ad 2) Man muß nicht alles (genau) wissen. Es reicht die Erkenntnis, daß die Prüfsumme gut genug ist, um die an sie gestellten Anforderungen zu erfüllen, und davon darfst Du hier getrost ausgehen.

ad 3) Der Offset ist lediglich ein Zeitversatz, d.h. ohne Einfluß auf die Prüfsumme. Nähere Infos dazu z.B. hier.

Danke für die Antworten,

so wie es aussieht, gibt es gar keine andere Methode, eine bitgenaues Rippen zu prüfen, als mit EAC zu rippen und der Acurate Rip Prüfsumme der einzelnen Tracks zu vertrauen.

Ich konnte den Begriff Prüfsumme in diesem Zusammenhang etwas mit Inhalt füllen.

Damit betrachte ich vorerst den ersten Teil des Titels als abgehakt. "CDs bitgenau rippen, dieses Prüfen..." Ich darf also nun davon ausgehen, dass meine Wavedateien bitidentisch auf der Festplatte liegen.

Geht es weiter zur bitegnauen Ausgabe und deren Verifizierung. Die Hürden, die auf dem weiteren Signalweg durch den PC auftauchen sind Player, Kernelmischer, Treiber (Resampling 44,1kHz / 48kHz), Soundkarte.

Player: Hier ist wohl Foobar2000 der "ehrlichste Player" mit deaktiviertem Equalizer sollte er bitgenau abspielen.
Stimmt das so ?

Nun das Thema das mich am meisten interessiert:

Das Umgehen des Kernelmischers. Er scheint die bitgenaue Ausgabe durch seine Gleitkommadarstellung und den daraus resultierenden Rundungsfehlern (Bitfehldeutung) am meisten zu gefährden.

Was macht ein sog. ASIO Treiber ?
Wie funktioniert Kernelstreaming ?

Ich merke schon an zwei absolut unterschiedlichen Reaktionen auf ein und das selbe Posting, dass ich hier 2 Dinge vereinen muss. Mir fehlen teilweise die Basics, auf der anderen Seite will ich Verschiedenes aber recht genau erfahren. Daraus resultieren halt Fragen auf absolut unterschiedlichem Niveau.

Wie schalte ich bei EAC in den "sicheren Modus" ?

Julian_AERO schrieb:

...Wie schalte ich bei EAC in den "sicheren Modus" ?[/b]

Siehe dazu hier : Anleitung EAC

Ok, danke

das hätte ich selber herausfinden können, war schon eingestellt.

Auch hierzu gibt es wieder Wikipedia Einträge die man konsultieren kann:

http://de.wikipedia.org/wiki/Audio_Stream_Input/Output
http://en.wikipedia.org/wiki/Kernel_streaming

Im Grunde funktionieren beide gleich. Beide umgehen die Software-Ebene und greifen direkt auf den Kernel bzw. die darunter liegende Hardware-Ebene zu. Stark vereinfacht gesagt. Eine genauere Erklärung würde einen weiteren Exkurs in die Software-Architektur erfordern...

Die "Wirkung" ist aber in beiden Fällen gleich: Mixer, DSPs etc. werden umgangen und es wird ohne Umwege an die Hardware weitergegeben. (Streng genommen erst an die Treiber bzw. Betriebssystem-Ebene, die den Zugriff auf die Hardware erst erlaubt)

so wie es aussieht, gibt es gar keine andere Methode, eine bitgenaues Rippen zu prüfen, als mit EAC zu rippen und der Acurate Rip Prüfsumme der einzelnen Tracks zu vertrauen.

Wieso?
Rippe die Datei dreimal und vergleiche alle drei paarweise mit
Ausführen > comp "Dateipfad Datei1""Dateipfad Datei2" etc.
Wenn diese drei Dateien identisch sind, kannst du davon ausgehen, dass richtig gerippt wurde, bzw. die zwei übereinstimmenden die richtigen sind (EAC macht ja auch nichts anderes, aber falls du ihm nicht vertraust, kannst du es so überprüfen)
Die Wahrscheinlichkeit, dass 3x an genau derselben Stelle genau derselbe Fehler auftritt, ist praktisch Null.

cr schrieb:

Die Wahrscheinlichkeit, dass 3x an genau derselben Stelle genau derselbe Fehler auftritt, ist praktisch Null.

Sie ist > 0 .. Das reicht als Strohhalm.

Es reicht ja, dass ÜBERHAUPT ein Fehler beim Auslesen passiert, egal an welcher Stelle, um das Ergebnis "Nicht identisch" zu erzeugen...

Bei nem kaputten Laufwerk oder - wahrscheinlicher - bei einer zerkratzten/defekten CD bzw. einem Laufwerk mit schlechter Lesekorrektur mag die Wahrscheinlichkeit eines Fehlerhaften Auslesens allerdings durchaus rapide in die Höhe schnellen.

Ok,

danke für die Ausführungen. Ich denke, dass EAC schon die beste Methode ist.
Ich dachte halt es gäbe ein Tool, dass von auf der Festplatte liegenden Tracks nach dem selben System wie EAC die Prüfsumme Bildet, um diese zu vergleichen.
Bei Schätzungsweise nur jeder 10. CD meines Fundus werden einzelne Tracks ohne ACR Bestätigung gerippt. Aber sonst liefert das Programm auch bei unbekannteren Aufnahmen z.B. "Henry Mancini - Moon River" belastbare Prüfsummen (Zuversicht 4) und das ist schon sensationell:

Denn wenn ich mir das alles nochmal durch den Kopf gehen lasse:

Selbst wenn die (Zuversicht) "nur" 1 ist, bedeutet das ja eigentlich, dass "nur" ein User das selbe Ergebnis hatte. Das habe ich Anfangs für sehr nachteilig gehalten.
Aber das ist doch schon ein fast 100 %iger Beweis für eine bitgenaue Kopie.
Nur ein Bit Abweichung im Track und jede der 8 Stellen der Prüfsumme mit 8^36 Kombinationen könnte abweichen.
Oder anders gesagt, die Chance, dass dieser eine User durch einen identischen Fehler (woher auch immer) die selbe Prüfsumme generiert hat steht unter 1 zu 3,45*10^32 !!!
Also, dieser eine User hat mit eine umgekehrt hohen Chance genau wie ich auch bitgenau gerippt. Und wenn das nun bei gleich 4 Usern der Fall ist...
E: Achso die Wahrscheinlichkeit ist etwa um 0,000000000000000000000000000000003 > 0. (bei einem identischem Ergebnis)
Für mich ist die Sache nun erstmal abgeschlossen.

Aber wie ist es nun mit dem ASIO Treiber, der muss doch in dem Player Foobar2000 eingebunden werden. Wie gehe ich da vor ?
Und wie kann man die Reduzierung der Signal-Verfälschung (bzw. die Korrekte Funktion) der "Kernelmixerumgehung" beweisen ? (ich habe da was von stillgeleten Reglern etc. gelesen)

Julian_AERO schrieb:

Ich dachte halt es gäbe ein Tool, dass von auf der Festplatte liegenden Tracks nach dem selben System wie EAC die Prüfsumme Bildet, um diese zu vergleichen.

Gibt es auch. Das Problem ist halt: Wenn Du ein Fehlerhaftes Laufwerk/CD mit unkorrigierbaren Fehlern hat, wird die Prüfsumme eventuell trotzdem gleich sein, weil das Laufwerk beim Auslesen immer den gleichen Fehler macht (Ist zwar statistisch gesehen unrealistisch, aber darum gehts ja net). Ein Vergleich mit der ausgelesen Datei auf der HDD ergibt somit ein "Identisch", obwohl dennoch fehlerhaft ausgelesen wurde.
Deswegen ist der Ansatz von EAC theoretisch ganz hilfreich. Je öfter eine Prüfsumme "ausgelesen" wird, desto wahrscheinlicher ist, dass sie, bzw. die zu Grunde liegende Datei, korrekt ist.

Allerdings ist das doch alles sehr stark theoretisiert. Bei Kratzer freien CDs und ordnungsgemäß funktionierenden Laufwerken dürfte die tatsächliche Fehlerrate (Also Falsch übertragene Dateien (NICHT mit den normalen Fehlern beim Auslesen verwechseln, die immer mal vorkommen, aber von der Fehlerkorrektur abgedeckt werden!)) verschwindend gering sein.
EACs "Sicherer Modus" ist in meinen Augen einfach nur Paranoia. Wer auf Nummer Sicher gehen will, rippt mit dem "Schnellen Modus" in Verbindung mit AccurateRIP. Für alle anderen tut es jedes andere Ausleseprogramm genauso.
Höchstens bei Problemfällen (Stark verkratzte CDs, CDs mit unsäglichem Kopierschutz etc.) könnte es sich lohnen auf den "Sicheren Modus" umzusteigen.

Wie gesagt, meine Meinung. Andere hier denken darüber anders, das weiß ich

Kann ich denn mit meiner Konfiguration,

Win XP, Foobar2000, Terratec Aureon 5.1 fun, die ASIO Treibersoftware verwenden. Wenn ja welche Ausführung ?

Julian_AERO schrieb:

Wenn ja welche Ausführung ?

Wenn der Hersteller keinen ASIO-Treiber für diese Karte anbietet, kannst Du asio4all verwenden. Soweit ich das verstanden habe, nutzt dieser universelle Treiber letztlich Kernel-Streaming, und das würde ich dann auch direkt nutzen. Aber wenn ASIO drauf stehen soll, probier's halt mal aus.

Ach ja: Es gibt noch eine Luxusversion eines deutschen Systemhauses, das "echte" ASIO-Treiber für Hersteller von Soundinterfaces entwickelt. Die kostenlose Demo piept alle paar Sekunden, und der Treiber kostet eine Stange Geld. Wenn KS (oder WASAPI) geht, lohnt das aber nicht.

Wenn nur die Frage interessant ist, ob akkurat gerippt wurde, dann bitte einfach mal eine CD selbst erstellen und die zugrundeliegenden Wave-Files (oder meinetwegen das eine Wave-File) aufheben. Das ist das Original, mit dem das zurückgegrabbte Machwerk der selbstgebrannten CD verglichen werden muß.

Ein Beispiel für eine solche Datei:

10 Sekunden Stille (die "Stille, die aus einer "digitalen Mittellinie" besteht, also "analog Null" und mit Audioeditoren (Funktion "Silence") erzeugt werden kann.

Dahinter (in der gleichen Datei) folgt z.B. 10 Sekunden Sinus 1 kHz. Wir brauchen das zum Synchronisieren beim Zurücklesen, um Laufwerksoffsets ausgleichen zu können.

Danach 60 Minuten weißes Rauschen, voll ausgesteuert und kanalgetrennt. Ein statistischeres Signal ist nicht zu bekommen - Adobe Audition / CoolEdit Pro liefert so etwas zum Beispiel.

Und zum Schluß nochmal 10 Sekunden Stille.

Das alles in eine Wave-Datei mit 44.1 kHz / 16 Bit / stereo basteln, ohne zusätzliche Infos in den Dateiheader zu packen abspeichern und die als Audio-CD mit einem Track brennen. Diese dann zurückgrabben in eine Wave-Datei.

Wenn das Brennen (erste Hürde!) und das Grabben (zweite Hürde) fehler- und offsetfrei vonstatten gegangen sind, haben wir jetzt eine Datei, die bis ganz kurz vorm Schluß bitgenau identisch zur Originaldatei ist. Nur ganz am Ende steht vermutlich etwas über, nämlich ein aufgefülltes letztes Frame der Audio-CD, es beinhaltet maximal knapp 1/75 Sekunde Stille, also maximal (44100/75)-1 = 587 Samples. Um dieses kommt das Brennprogramm nicht herum, denn es soll eine normgerechte Audio-CD brennen und die kennt nur Häppchen von 1/75 Sekunden Länge. Eine Wave-Datei im üblichen "CD-Format" kennt allerdings "Häppchen" von 1/44100 Sekunden Länge - unsere Samples. Also muß das Brennprogramm auffüllen - da liegt auch der Grund, warum Live-Aufnahmen, die man in Einzeltitel "zerbrochen" hat, um sie dann auf CD zu brennen, oft kurz knacken am Titelübergang.

Da das Leselaufwerk garantiert irgendeinen Offset fabriziert, sind die Dateien allerdings vermutlich gegeneinander leicht "verschoben". Macht nix... wir haben ja unseren Sinus als Synchronmarke.

Jetzt beide Dateien (Original und das Gegrabbte) in einen Mehrspureditor laden und so lange gegeneinander verschieben, bis es samplegenau paßt. Mit Audition geht das ganz wunderbar (schrittweise reinzoomen und die Dateien auf Übereinstimmung bringen).

Dann eine der beiden Dateien invertieren (an de ranalogen Nullinie spiegeln) und einen Mixdown machen. Da müßte jetzt ein langes Nichts herauskommen... eine Stunde Stille. Das ist dann beinahe der Beweis, daß Brennen und Grabben fehlerfrei funktionieren.

Wer ganz vorsichtig und mißtrauisch ist, könnte auf den Gedanken kommen, daß beim Brennen ja Fehler entstanden sein könnten, die beim Grabben exakt kompensiert werden. Daß z.B. beim Brennen durch eine schlampig programmierte Brennsoftware oder eine fehlerhafte Firmware im Brenner zwischen dem original-Wave und der gebrannten CD ein Offset zwischen linkem und rechtem Kanal von exakt 1 Sample auftritt (durchaus realistisch gewesen in der Anfangszeit der Brennerei) und beim Auslesen durch einen weiteren Fehler das genau kompensiert wurde. Das ist zwar in seiner Wahrscheinlichkeit nahe Null, aber die gesamte Highend-Branche operiert ausschließlich in diesem Nebel.

Deshalb: ein zweiter Einleseweg muß her. Also die CD nochmal 1:1 via optischen Ausgang des CD-Players und eine geeignete Audiokarte in den PC zurückspielen und abermals vergleichen.

Ich habe das vor vielen Jahren mal gemacht, aus Neugier, Lust und Langeweile. CD gebrannt (Teac 4x-SCSI-Brenner, war damals was tolles...), zurückgelesen (Plextor PX40), verglichen - exakt bitgenau. Dann die CD via CD-Player optisch auf Terratec EWX 24/96 zurückgespielt und abermals verglichen - wieder bitgenau. Dann der Härtestest: Ausspielen der Originaldatei in Echtzeit via Winamp 2.666 optisch auf den DAT und das vom DAT zurückgelesen - wieder absolut identisch. Das fand ich dann doch bemerkenswert, denn ich hätte dem DAT nicht zugetreut, eine halbe Stunde lang auch wirklich kein einziges Sample falsch zu lesen.

Bei der Gelegenheit war dann gleich noch bewiesen, daß der PC sowohl "optisch rein" als auch "optisch raus" bitgenau arbeitet. Fein! Den PC (Windows 98SE, Pentium III 850, 256 MByte RAM, VXD-Treiber ohne Resampling oder Pegelschweinereien) benutze ich übrigens auch heute noch für meine Audiobearbeitung. Ich tu mich schwer, was neues zu evaluieren und hoffe auf noch lange Lebensdauer der Kiste.

Solcherart Audiospeicherung ist robuster als man denkt. Wenn 2 Leseversuche von CD identisches Resultat liefern, sollte alles paletti sein. Ich hatte jahrelang nichts anderes mehr, bis letzte Woche. Da kopierte ich eine Audio-CD und die Kopie war nur mit Fehlern lesbar. Offenbar eine Ausschuß-Spindel erwischt.

Da das Leselaufwerk garantiert irgendeinen Offset fabriziert, sind die Dateien allerdings vermutlich gegeneinander leicht "verschoben".

Das kann ich mit jeder x-beliebigen wav-Datei machen. Einen Offset hatte ich noch mit keinem meiner Brenner, da ich die Dateien sonst mit dem primitiven Programm comp.exe nicht vergleichen könnte. Das Ripping/Brennprogramm sollte den Offset automatisch berücksichtigen. Meines tuts zumindest.

Audiograbber schiebt auch automatisch, wenn ein Offset im Spiel ist.

Danke sehr informativ,

es ist doch bemerkenswert, dass sich viele Leute mit einer gewissen Ensthaftigkeit mit dem Thema auseinander setzten.
Diesen Versuchsaufbau werde ich mit Sicherheit auch mal durchführen.
Doch soweit bin ich leider noch nicht:
In vorerst interssiert mich das "cleanen" des Signalweges durch den PC sowie die bitgenaue Ausgabe über Toslink und dessen Beweis.

Ich hänge immernoch beim Treiber für das Umgehen des Kernelmixers fest. Ich habe den Treiber asio4all installiert, doch er arbeitet nicht. Der Sound der Excell Büroklammer etc. wird weiter munter eingespielt.
Stimmt es, das bei einem korrekt arbeitendem Kernelstreaming die Regler des Mixers keine Funktion mehr haben ?
Hat noch jemand einen Tip es muss ja auch kein ASIO Treiber sein. Es geht mir grudsätzlich um die Funktion.

- es begab sich vor langer Zeit

da hatten CD Laufwerke einen extra Digital 2 Pin Ausgang
welcher mit passender Soundkarte verbunden wurde und dort auf SPDIF ausgab.

Soweit erinner kann man aber mit technischem KnowHow auch direkt vom Ausgang auf coaxial Anschluss gehen.

Da lag es viel am Laufwerk und seiner verbauten Technik.

Heutzutage wird intern digital ausgelesen.. da gibt es solch Anschlüsse halt nichtmehr.

Julian_AERO schrieb:

es ist doch bemerkenswert, dass sich viele Leute mit einer gewissen Ensthaftigkeit mit dem Thema auseinander setzten.

Allerdings, denn dieses Thema hat doch mittlerweile einen Bart bis nach Mexiko.
Selbst die billigsten Laufwerke rippen mit ordentlicher Software Bitperfect... Das ist keinerlei Anforderung mehr und muß auch nicht getestet werden.

Software wie Foobar, EAC oder dbPowerAMP lesen selbständig mehrmals und vergleichen die gelesenen Daten mit den vorherigen versuchen. Bislang hatte ich damit noch NIE ein einziges Problem.

Julian_AERO schrieb:

In vorerst interssiert mich das "cleanen" des Signalweges durch den PC sowie die bitgenaue Ausgabe über Toslink und dessen Beweis.

Theoretische Spielerei. Praktisch wirst Du den Unterschied ohnehin nicht hören. Davon aber abgesehen: Bitperfect wiedergabe ist speziell im WASAPI Betrieb kein Kunststück und muß auch nicht verifiziert werden, weil es todsicher funktioniert.

Ok,

Ich hab es ja befürchtet, dass ich hier alten Kaffee aufkoche... aber ich finde es klasse, dass sich alte Hasen auf diesem Gebiet zu Wort melden.
das mit dem Rippen habe ich ja verstanden und dass es bitidentisch bei mir funktioniert. Ich habe bis jetzt nur EAC installiert. Wie funktioniert das denn bei EAC mit dem selbstständig mehrmalslesen? Das wäre für mich ganz interessant bei Alben, bei denen EAC keine Prüfsummen in der Datenbank findet oder eine andere Pressung vermutet da jeder Track abweicht.

Und mit diesem WASAPI (Treiber?) wird dierekt auf die Hardware zugegriffen (also der etwas umständliche Signalweg verkürzt) ? Das ist ein Plugin für Foobar2000 ? Funktioniert es nicht nur unter vista ?

Könnte jemand die Unterschiede zwischen WASAPI und ASIO kurz zusammenfassen ?

Julian_AERO schrieb:

Wie funktioniert das denn bei EAC mit dem selbstständig mehrmalslesen?

Ich verwende seit längerem kein EAC mehr sondern Foobar2000.
Soweit ich mich erinnern kann gibt es bei den Laufwerkseinstellungen 3 Modi... "Burst" ist unsicher, alles darüber ist Secure.

Julian_AERO schrieb:

Und mit diesem WASAPI (Treiber?) wird dierekt auf die Hardware zugegriffen (also der etwas umständliche Signalweg verkürzt) ? Das ist ein Plugin für Foobar2000 ? Funktioniert es nicht nur unter vista ?

Funktioniert erst ab Windows Vista und wird von vielen Programmen unterstützt. Für Foobar2000 gibt es ein entsprechendes Plugin. Zu den Unterschieden möchte ich nicht viel schreiben, nur soviel

WASAPI = Schnittstelle von Microsoft

Asio = Schnittstelle von Steinberg um die Latenz der Ton-Wiedergabe zu senken (z.B. für Software-Synthesizer).
Asio war nie dafür gedacht wofür es hier im Forum "mißbraucht" wird.

Asio war nie dafür gedacht wofür es hier im Forum "mißbraucht" wird.

Ist doch egal, wenn es den Zweck erfüllt, den K-Mixer zu umgehen. Was soll man denn sonst bei w2k und xp machen?
Bei semiprof. Soundkarten ist zudem ein passender ASIO-Treiber dabei und man braucht keine Ersatzlösungen.*
Ich mußte allein deshalb schon den ASIO installieren, weil sich nach jedem Standby der K-Mixer verstellt hat (nicht mehr auf Vol.max). Und sowas nervt, wenn man 5-10x am Tag das Notebook aus dem Standby holt.

*Edirol empfielt, auch für Wiedergabe den ASIO Treiber zu verwenden.

cr schrieb:

Was soll man denn sonst bei w2k und xp machen?

Du kannst auf ASIO zurückgreifen, bzw. notfalls auf ASIO4ALL.

Wenn ich mir hier die Beiträge zum Rippen so durchlese, bekommt msn den Eindruck, das es egal ist, ob ich nun mit EAC oder Foobar meine CD's zu FLAC's Rippe. Liege ich da richtig???
Dann würde ich gerne noch wissen wie ich bei Foobar die Plattencover automatisch mit in die gerippten Dateien bekomme?!? Die Anzeige der Titel funktioniert ja wunderbar, aber Cover habe ich noch kein einziges bekommen???
Danke und Gruß
Stefan

Hallo,

ich möchte meine Frage nochmal wiederholen:
Wenn ich mir hier die Beiträge zum Rippen so durchlese, bekommt man den Eindruck, das es egal ist, ob ich nun mit EAC oder Foobar meine CD's zu FLAC's Rippe. Liege ich da richtig???
Wenn mann sich die Einstellmöglichkeiten bei EAC ansieht, sind diese viel umfangreicher als bei Foobar?!?!
Ist die Qualität trotzdem identisch?? Also die Fhlerrate =0?
Danke und Gruß
Stefan

Die Qualität ist identisch.
Die Fehlerrate nicht zwangsläufig.

EAC hat theoretisch mit dem Sicheren Modus und AccurateRIP zwei (kombinierbare) probate Mittel, um sicher zu stellen, dass beim Rip-Prozess nichts schief gelaufen ist.

Praktisch habe ich aber quasi noch nie erlebt dass ein Fehlerfreies Laufwerk Fehler beim Rippen produziert hat, die das Rip-Programm nicht eh selbst fest gestellt hätte. Und ich habe schon einige Hundert Scheiben gerippt.

Wenn man auf Nummer sicher gehen will... EAC. Wer nicht ganz so paranoid ist, kommt mit dem Ripper seiner Wahl bzw. dem MediaPlayer auch so weiter

Danke für Deine Antwort! Foobar verfügt aber genau wie EAC über den Sichern Modus und über AccurateRip!!
Damit dürfte es doch wohl keine Unterschiede geben!
Gruß
Stefan

Damit dürfte es doch wohl keine Unterschiede geben!

Richtig. Vorrausgesetzt Du stellst in Foobar als Security "Standard" im RIP-Dialog ein... Per default ist das nämlich aus.