bitgenau?

Einfach eine dts CD abspielen und schauen was der AV Receiver macht. Gibt es nur rauschen ist es nicht bitgenau. Gibt es Musik dann ist die Kette in Ordnung.

danke!
manchmal sehe ich den Wald vor lauter Bäumen nicht...

mir ist letztens sogar mal aufgefallen, dass bei einer Rosenstolz CD (bzw. dem FLAC davon) auf einmal "richtiger" Surround Ton dabei war. Dann kann ich damit ja mal die verschiedenen "Wege" testen.

Edit:
und wie erhofft und irgendwie auch erwartet, auch wenn man sich eben nicht sicher ist:
sowohl der HTPC mit Kodi als auch die Squeezebox Duett über den LMS auf der Synology NAS spielen dts Titel ohne Probleme ab.
Das erklärt dann auch, warum ich solche Schwierigkeiten hatte Unterschiede zum CD-Player zu hören

Edit2:
da sieht man mal wieder, wie man von den "unabhängigen" Tests verarscht wird!
wenn ein 90€ Gerät aus der Bucht wie die Squeezebox die Daten bitgenau am AVR abliefert, warum werden dann solche Geräte für 1500€ wie in diesem Test so hoch dafür gelobt?
Und wie kann es zu solchen Sprüchen kommen:

gerade kürzlich hatte ich das Vergnügen, den noch vielseitigeren AVM CS 2.2 testen und besprechen zu dürfen. Aber selbst bei Letzterem konnte ich feststellen, dass die Streamingabteilung sich im Vergleich zum ebenfalls vorhandenen integrierten CD-Player keinen eindeutigen Vorteil herausspielen konnte. Mir gefiel sogar die etwas frischere Gangart der CD im Vergleich mit gestreamtem, gleichsam mit 44,1 kHz/16 Bit aufgelöstem Musikmaterial etwas besser.

da reden wir über ein 4500€ Gerät und das schafft es nicht die Daten genauso bitgenau an den DAC zu liefern wie meine "Billig-Lösungen"?!?

Die ganzen superschlauen HiFi-Tester waren vor lauter Schwurbelei bisher nicht mal in der Lage, festzustellen, ob der jeweilige CDP oder DVDP etc, bitgenau ausgibt (oder findet man das inzwischen?).
Seinerzeit, als ich bitgenaue Ausgabe für den CD-Rekorder benötige, hatte ich Riesenärger, weil ich 2x mal auf einen nicht bitidentischen CDP hereingefallen bin: Philips und Marantz. Gerade von einem, der sich als hiEnd-Hersteller ausgeben will, hätte ich was Brauchbareres erwartet. Nicht nur nicht bitidentisch, sondern auch noch 0,7dB im Pegel reduziert. Aufgefallen ist mir der Mist, weil die Kopie von der Kopie deutlich leiser war als das Original (-1,5dB)

So, gestern auch mal getestet.

Mein Pioneer PDR 609 Brenner gibt bitgenau aus.
Ebenfalls mein Kenwood DP 3050.
Getestet mit einer DTS-CD.

Gruß
Georg

Ich hoffe, das mal hier ungestraft unterbringen zu können:
Ich mag es, CD-Spieler neuzulöten. Lötstellen, wie sie (meiner Meinung nach,-) sein sollten. Und die Masse, mitunter Spannungsanschlüsse, bekommen gelegentlich, wenn machbar (bei manchen Geräten wäre der Aufwand zu hoch), neues Layout. Analogverstärker bleiben unberücksichtigt - wie auch immer,-) Ich weiß nicht, was passiert, aber der Kram spielt anders. Bitgenau sollte es ja geblieben sein, oder spielt es nun erst bitgenau, oder ist Schwarz auf Weiss echt nur für das Gewissen, wie auch Frequenzgang, was uns andere, oft wesentliche-re Effekte nicht erkennen läßt?
Keine Ahnung.

cumbb (Beitrag #6) schrieb:

Ich weiß nicht, was passiert, aber der Kram spielt anders. Bitgenau sollte es ja geblieben sein, oder spielt es nun erst bitgenau, oder ist Schwarz auf Weiss echt nur für das Gewissen, wie auch Frequenzgang, was uns andere, oft wesentliche-re Effekte nicht erkennen läßt? Keine Ahnung.

naja, wenn du es glaubst...

wenn die Übertragung nicht bitgenau ist, dann kann das Ergebnis auch nicht identisch sein! Ob es sich trotzdem gleich anhört ist etwas anderes.
wenn es bitgenau übertragen wird, dann sind zumindest schonmal die Vorraussetzungen dafür da, dass es sich auch gleich anhört.

wie immer: wenn am DAC die Daten bitgenau angeliefert werden und jemand hört anschließend noch Unterschiede zwischen zwei (bitgenauen) Quellen, dann taugt der DAC nix, weil er offensichtlich mit minimalen Jitter am Eingang nicht umgehen kann. Den kann man heutzutage ohne Probleme unterdrücken, so dass er keinen Einfluss auf den Klang hat.
wenn es bei dir also durch (aus meiner Sicht sinnloser) Löterei an der Digitaltechnik oder anderer Masseführung zu Klang Unterschieden kommt, dann solltest du stattdessen mal den DAC überdenken.

noch zu den Übertragungsformaten, die hier bitgenau arbeiten ja/nein:
Mac mini -> iTunes -> HDMI -> AVR : bitgenau
Mac mini -> iTunes -> Airplay -> AppleTV -> HDMI -> AVR : NICHT bitgenau
Mac mini -> iTunes -> Airplay -> AVR (intern) : NICHT bitgenau
PC -> Kodi (WASAPI) -> HDMI -> AVR : bitgenau
PC -> Kodi (Direct Audio) -> HDMI -> AVR : NICHT bitgenau
PC -> VLC (default) -> HDMI -> AVR : NICHT bitgenau
Dune-HD -> HDMI -> AVR : bitgenau
Fire-TV -> KODI -> HDMI -> AVR : NICHT bitgenau
Squeezebox Duett -> S/PDIF -> AVR : bitgenau

die Dateien (ALAC für iTunes, FLAC für den Rest) liegen auf dem NAS und es wird per SMB/CIFS darauf zugegriffen, nur die Squeezebox muss vom Logitech Music Server (läuft auf dem NAS) "gefüttert werden".

Tag,

vielen Dank für die Liste und Erklärung Mickey Mouse. Kann man einen klanglichen Unterschied zwischen bitgenau und nicht bitgenau bei Wiedergabe von 44,1 khz/16 Bit FLAC oder ALAC Files hören? Also hast Du es schon ausprobiert oder magste ausprobieren ein beliebiges 44,1 khz/16 Bit FLAC oder ALAC File einmal mit Squeezebox Duett -> S/PDIF -> AVR zu hören und danach mit Mac mini -> iTunes -> Airplay -> AppleTV -> HDMI -> AVR und danach berichten?

Grüße

Max

wenn es Unterschiede gibt, dann reicht mein "Klang-Gedächtnis" dafür nicht aus die beim nacheinander Hören zu erkennen.
das ist ja auch dasselbe wie z.B. mit den verschiedenen Filter Charakteristiken vom DAC. Wenn ich dazwischen umschalte höre ich auch Unterschiede und kröne einen Favoriten. Starte ich aber ein Lied, dann kann ich nicht sagen welcher Filter gerade aktiv ist.

und machen wir uns nix vor, wenn man weiß, dass z.B. das ATV nicht bitgenau arbeitet, dann wird man dahin tendieren, dem einen schlechteren Klang "anzudichten".

es geht auch ein bisschen nur um das Prinzip. Ich rippe meine CDs mit AccurateRip Kontrolle der Prüfsumme um sicher zu gehen, dass die Daten so auf der Platte sind wie sie auch auf der CD drauf sind, damit geht es ja los. Und wenn eine Squeezebox von 2008 das ohne Probleme hinbekommt, dann sollte das doch nicht so schwer sein.
Wenn ich die Daten in digitaler Form habe, dann möchte ich sie auch bis zum DAC ohne Änderungen dahin transportiert haben, da bin ich stur

das hält mich aber nicht davon ab, meine Klapp-Box mit Aktiv-LS und einem AirPort Express zwischen den Terrassen hin und her zu schleppen um zum Frühstück und Abends jeweils Mucke zu haben. Da muss ich dann wohl damit leben, dass AirPlay das nicht bitgenau hinbekommt

M.E. ist die Reduzierung auf bitgenau falsch.
Wo und wann ist die Info bitgenau?
Was ist mit Jitter, wo wird geklockt und synchronisiert?
Wird ggf. reclockt und oder upgesampled?
In einer Digitalkette gibt es so viele Stellen, an denen unerwartete Einflüsse zum tragen kommen.
Es ist aber immer auch eine Frage, auf welchem Niveau wir uns bewegen.

avh0 (Beitrag #10) schrieb:

M.E. ist die Reduzierung auf bitgenau falsch. Wo und wann ist die Info bitgenau?

Das ist eine einfache Frage wenn ein Wert genauso ausgegeben wird, wie er aufgezeichnet wird.
Sobald allerdings nur die Lautstärke um den kleinstmöglichen Wert gändert wird, ist es nicht mehr bitgenau, bedeutet aber nicht gleich schlechteren Klang, halt etwas leiser oder lauter.

http://nwavguy.blogspot.de/2011/02/jitter-does-it-matter.html

das ist doch völlig egal!

wenn die Daten bitgenau am Eingang vom DAC ankommen und der ein ordentliches Clock-Recovery macht, dann ist doch alles gut. Zumindest sind die Grundvoraussetzungen erfüllt. Da ist es völlig egal, ob zwischendurch schonmal der Takt neu generiert wurde oder nicht.

Leider hat sich ja heraus gestellt, dass gerade die sogenannten "High-End" Geräte mit solch einfachen Dingen wie einem vernünftigen Puffer und dem Clock Recovery ernsthafte Probleme haben.
Ich kann an der AV-Vorstufe in drei Stufen einstellen wie aggressiv die PLL nachlegen soll, damit es nicht zu Puffer Unter/Über-läufen kommt. Es hat sich heraus gestellt, dass einzig das Fire-TV die Daten so unregelmäßig anliefert, dass es gelegentlich in der "sanftesten" Stellung (PLL wird nur ganz langsam nachgeführt) zu Aussetzern kommt.

Aber wie gesagt, wenn man einen DAC hat, der das nicht hinbekommt, dann muss man vorne mehr Aufwand treiben. Hat man "vernünftige" Geräte, dann ist es eben egal ob es am Eingang etwas Jitter gibt oder nicht. Und vor allem: es wird eben NICHT besser nur weil die Daten ohne Jitter ankommen, daher kann man an diesen Geräten dann auch keine Unterschiede hören.
Je mehr Schrott man in der Kette hat, desto mehr Auswirkungen haben solche Effekte, die "normalerweise" keinen Einfluss haben.

Mickey_Mouse (Beitrag #12) schrieb:

wenn die Daten bitgenau am Eingang vom DAC ankommen und der ein ordentliches Clock-Recovery macht, dann ist doch alles gut.

Stimmt.

Und vor allem: es wird eben NICHT besser nur weil die Daten ohne Jitter ankommen, daher kann man an diesen Geräten dann auch keine Unterschiede hören.

Der beste Beweis sind moderne softwaregesteuerte digitale Zuspieler. Auf so manchen dieser Systeme laeuft ein Multitasking-Betriebssystem, das die Daten naturgemaess mit extrem unregelmaessigem Timing anliefert, weil die Software, welche die "Musik" anliefert, immer nur eine kurze Zeiteinheit laeuft, und dann jeweils wieder unterbrochen wird, um andere Tasks laufen zu lassen, oder z.B. Interrupts der Hardware zu bedienen. Solange das Timing des Wandlers aus dessen Puffer dann wieder passt, ist das aber alles egal.

ich habe mir heute die Media Center Erweiterung zum Windows 8.1 installiert und wie erwartet:
PC -> Win8.1 Media Player -> HDMI -> AVR : NICHT bitgenau

PC ist selten bitgenau, weil die allermeisten Soundlösungen im PC die Daten mit 48 kHz ausgeben.
Der PC sampelt also 44,1 kHz auf 48 kHz hoch.
Und schon wars das mit der bitgenauigkeit.

Nur mit bestimmten Treiberlösungen kann man PCs dazu zwingen, die Samplingrate nicht zu verändern.

Grüße
Roman

naja, es gibt ja trotzdem Lösungen die das hinbekommen, Kodi zum Beispiel, auch wenn man da erst "etwas" herum konfigurieren muss (wenn man es schon zig mal gemacht hat, dann ist es pottensimple, aber Einsteiger werden ja schon daran scheitern, dass man den Bediener Level auf Erfahren oder gar Experte setzen muss, um die Einstellungen überhaupt zu Gesicht zu bekommen ).

Das es auch anders geht beweist Cyberlinks PowerDVD 15 Ultra:
PC -> PowerDVD15 (default) -> HDMI -> AVR : bitgenau
bis auf auf die "Ok-Buttons" bei der Installation zu klicken ist dafür nichts weiter nötig!

Sie es einfach mal so, der der nicht in der Lage ist ein System zu beherrschen und nur Knöpfe drücken kann, hat der bitperfekt verdient?

ich habe gerade noch ein paar AirPlay Versuche gemacht:
Apple Airport Express (alte Version in Macbook Netzteil Look, Version 7.2.4): bitgenau!
Apple TV 3rd Gen: NICHT bitgenau
Yamaha CX-A5000: NICHT bitgenau
Yamaha CX-A5100: bitgenau

den Airport Express hatte ich eigentlich nur zur Unterstützung meiner Theorie getestet, dass es bei aktuellen AirPlay Implementierungen funktioniert und bei älteren nicht. Nun macht genau der mir einen Strich durch die Rechnung, weil der mit Abstand der älteste ist und die bitgenaue Übertragung beherrscht.
Fazit: es hängt vom Einzelfall ab und man kann AirPlay nicht über einen Kamm scheren.

Hi

als auch die Squeezebox Duett über den LMS auf der Synology NAS spielen dts Titel ohne Probleme ab.

na dts-CDs spielt sogar mein Denon CDP von (ca) 1998 ab

std67 (Beitrag #19) schrieb:

na dts-CDs spielt sogar mein Denon CDP von (ca) 1998 ab

wäre ja auch traurig wenn nicht...
Dass jeder anständige Player das mit der Scheibe kann, davon gehe ich mal aus.

der hat doch aber nichtmal einen Netzwerk Anschluss, oder? Darum geht es (mir) hier ja: wie kann ich Musik auf einem NAS/Server/PC per Netzwerk abspielen, ohne mir immer überlegen zu müssen: klingt die original CD vielleicht doch besser und lohnt es sich die aus dem Schrank (oder gar Keller, bei >1000 CDs) raus zu kramen?

Jetzt muss ich einfach blöd fragen, wie testest du ob eine Übertragung vom iPhone per airplay am AVR bitgenau ankommt?
Ich frage mich wie es sich bei DLNA verhält.

na ich meinte weil du das Alter der Squeezebox (2008) so explizit erwähntest
Ich hatte mal enen DVD-Plaer der das nichtkonnte, und kann mich dunkel an Berichte ausm DVD-Board erinnern wo der ei oder andere User berictete das es nicht geht. Bei CDP dagegen geht die Abspielfähigkeit gegen 100%

Bei Netzwerkgeräten, vor allem wenn PC oder Apple (Airplay oder was auch immer) dazwischenhängt hängt das halt imervom Einzelfall ab,wie du ja selber schon getestet hast
Dahat man ja auch schnellmal was falsch eingestellt, und wenns nurne Kleinigkeit ist.

ich habe AirPlay nicht mit dem iPhone sondern einem Mac und iTunes getestet.
in meiner Bibliothek habe ich die "Erwarten se Nix" von Rosenstolz und da sind die letzten beiden Lieder in 5.1 dts Ton (ganz normal lossless gerippt).
wenn das vom AVR abgespielt wird, dann wird der dts Stream wohl bitgenau dort angekommen sein, sonst könnte der ja keinen komprimierten Ton ohne Aussetzer abspielen.
Wie die Tests zeigen, kommt es bei vielen Übertragungen eben nicht zu dieser 1:1 Übertragung, da kommt nur digitaler Müll (Rauschen) aus den LS.

Der Logitech Music Server (LMS) müsste ja so etwas ähnliches wie DLNA sein, nur mit wesentlich mehr Möglichkeiten (synchrones Abspielen auf mehreren Geräten usw.) und prinzipiell funktioniert es damit ja.

Zum Einzelfall oder verschiedenen Einstellungen:
ich will nicht ausschließen, dass ich etwas falsch gemacht habe. Z.B. muss man immer darauf achten, dass die Lautstärke am sendenden Gerät voll aufgedreht bzw. die Einstellung deaktiviert ist, natürlich kann das nicht funktionieren, wenn der Sender schon den Pegel reduziert.
Aber bei CX-A5000/5100 kann man meines Wissens nichts konfigurieren und mit der 5100 funktioniert es, mit der 5000 nicht, beides direkt hintereinander vom Mac aus getestet.

Ja, LMS ist DLNA
https://de.m.wikipedia.org/wiki/Logitech_Media_Server
schön das es da bitgenau funktioniert, DLNA ist mir irgendwie auch sympathischer.

wenn das vom AVR abgespielt wird, dann wird der dts Stream wohl bitgenau dort angekommen sein, sonst könnte der ja keinen komprimierten Ton ohne Aussetzer abspielen.

genau das bezweifle ich irgendwie. Falls dts keine Prüfbits enthält, kann der AVR gar nicht wissen ob ein Bit verändert wurde oder nicht. Werden zu viele bits verändert kommt natürlich nur Mist am AVR an

HiFi_Addicted (Beitrag #2) schrieb:

Einfach eine dts CD abspielen und schauen was der AV Receiver macht. Gibt es nur rauschen ist es nicht bitgenau. Gibt es Musik dann ist die Kette in Ordnung.

Dem letzten Satz muss ich leider aus aktuellem und äußerst frustrierendem Anlass widersprechen. Ich weiß, dass ein solcher DTS-Test gerne der Einfachheit halber empfohlen wird, da bei jedweder Verfälschung der Daten das Dekodieren nicht mehr klappt, doch es scheint entgegen meiner eigenen Annahme kein Beweis für zumindest "16-bittige" Transparenz zu sein:

Ich habe nämlich gerade das perfide Problem, dass Überspielungen via S/PDIF von einer DTS-CD 1:1 mit dem Original übereinstimmen, Musik sowie Testsignale je nach Aussteuerung jedoch zu (scheinbar) zufälligen Abweichungen führen.

Interessanterweise sind dabei mehrere Durchläufe zueinander bitidentisch, jedoch leider nicht zum Original.

Nachdem auch 7-Bit-Text als Audio-CD gebrannt (um etwaige Verfälschungen gleich direkt im Hexeditor sehen zu können) bitgenau ist, vermute ich, dass es mit dem Pegel zusammenhängt und da nahe 0dBFS irgendein Dithering oder sonstige Nachbearbeitung im Hintergrund stattfindet. Das würde erklären, weshalb DTS unbeschadet "durchgeht", da hier absichtlich mit 14-Bit gearbeitet wird, um das weiße Rauschen bei versehentlicher D/A-Wandlung auf maximal -12dBFS zu haben.

avh0 (Beitrag #10) schrieb:

M.E. ist die Reduzierung auf bitgenau falsch.

Es ist die einzig Richtige und im Alltag schon Herausforderung genug (siehe oben).

avh0 (Beitrag #10) schrieb:

Wo und wann ist die Info bitgenau?

Wenn nur jede Definition im Leben so einfach wäre.

avh0 (Beitrag #10) schrieb:

Was ist mit Jitter, wo wird geklockt und synchronisiert? Wird ggf. reclockt und oder upgesampled?

Völlig wurscht. Bitgenau ist bitgenau ist bitgenau.

avh0 (Beitrag #10) schrieb:

In einer Digitalkette gibt es so viele Stellen, an denen unerwartete Einflüsse zum tragen kommen.

Erstmals einer Meinung. Was mich jedoch nicht davon abhalten wird, möglichst die richtigen Schlüsse zu ziehen.

So wie es Wandler und Sondkarten gibt, die NON-PCM automatisch bypassen, könnte es ev. auch im Receiver ablaufen. Dass es am CDP liegt, erscheint mir eher wenig wahrscheinlich. Warum sollte der zB DTS automatisch bypassen und PCM verändern?

Kannst du nicht einen Einzeltrack mit der Soundkarte vom CDP aufzeichnen? Mit der aktuellen Bitcompare-Version von Foobar (nur diese kann Offsets handhaben) kannst du feststellen, ob der Track (im Kern) bitidentisch zur gerippten WAV-Datei ist.
Falls dir ein Audiobrenner zur Verfügung steht, gehts einfacher. WAV-Datei des Originals und der CDR mit Foobar vergleichen.
Ich konnte jedenfalls inzwischen feststellen, dass meine CDRs von den Audiobrennern bis auf Track für Track unterschiedliche Offsets bitidentisch zur CD sind (diverse CDPs als Zuspieler, außer dem Philips CD 753, der bekannterweise nicht bitidentisch ausgibt, sonder den Pegel um 0,7dB herunterrechnet).

Da es mich beim Thema S/PDIF nicht wundern würde, wenn morgen wieder alles ganz anders ist, will ich den Tag nicht vor dem Abend loben und allenfalls vermelden, dass ich den Fehler "womöglich, vielleicht, unter Umständen" gefunden habe - jetzt, unter Windows 7, mit Goldwave 6.10 und 6.18, mit einer TerraTec Aureon 5.1 PCM Karte und dem D0gbert-Treiber 1.2.6 WaveRT.

Zunächst: glücklicherweise sind meine beiden Zuspieler - allen voran ein ehrwürdiger LaserDisc (!) -Player (um deren Aufnahme es eigentlich geht) Pioneer CLD-D925 sowie ein Panasonic DVD-S47 unschuldig und liefern nach bisherigen Tests 44,1 kHz / 16 Bit exakt so aus, wie es auf die CD gebrannt wurde (das Thema mit den schwachen Sektoren, die man bei Sector-Scrambling auch bei Audio-CDs erzeugen kann, lasse ich jetzt mal außen vor ). Ich erinnere mich an einen deiner älteren Beiträge, cr, mit den 0,7 dB. Interessant wäre zu erfahren, was die sich dabei gedacht haben. Selbst wenn sie "Intersample Overs" vorbeugen wollten, wären um die 3 dB zur Sicherheit wohl eher angebracht und davon abgesehen könnte das Signal ja dann immer noch ausschließlich vor dem DAC "abgeschwächt" werden. Immerhin erfordert ein solcher Designfehler ja zusätzliche Überlegungen und Rechenleistung, kurios.

Goldwave bietet unter "Settings" -> "Device" -> "Quality" die Einstellungen "PCM 16 bit", "PCM 24 bit", "IEEE 32 bit" sowie "shared". Während meiner unzähligen Tests in den letzten Tagen stand das nun (wieder) auf "shared", nachdem "PCM 16 bit" zuvor je nach Treiberkonstellation nicht funktionierte. Seltsamerweise muss ich beim D0gbert-Treiber nun den Mikrofon (!)-Eingang wählen, um S/PDIF aufzunehmen. Die Einstellungen bezüglich 'validity flag' oder invertiertem S/PDIF (wozu das auch immer gut ist), erfolgt jedoch bei den Optionen des eigentlichen S/PDIF-Eingangs - mehr als seltsam, mir aber auch bald egal, Hauptsache, es funktioniert endlich.

Nun auf PCM 16 bit gestellt und vom Mikrofoneingang aufgenommen ergibt bitgenaue Daten.

Nachfolgend die Einstellungen "PCM 16 bit" und "shared" im Vergleich - auffallend und interessant ist, dass meine kleine gebastelte "Synchronisationssequenz" ABCDEF zunächst unangetastet bleibt, dann aber Unterschiede auftreten.






14-Bit-DTS als 16-Bit-PCM verpackt, wie es bei offiziellen DTS-CDs vorkommt, übersteht die "shared" - Einstellung wie gesagt unbeschadet - aus beiden Aufnahmen ("PCM 16 bit" und "shared") lässt sich DTS bitgenau rekonstruieren, soeben nochmal getestet.

Um also sicherzugehen, dass der komplette Signalweg vom Player bis zum Audio-Editor wirklich verlustfrei ist, habe ich mir ein RAR-Archiv, wie auf den Bildern ausschnittsweise zu sehen, gebastelt und dieses am Anfang und Ende mit ein paar "Sekunden" an Daten aufgefüllt. WinRAR ist nämlich so tolerant, am Anfang der Datei "Unrat" zu übersehen und nach dem RAR-Header Ausschau zu halten. Dies, um Offsets beim Brennen und wieder Einlesen der CD zu kompensieren. Im Idealfall kann man die Aufnahme im Editor also direkt speichern und als RAR-Archiv öffnen. Durch den immanenten CRC32-Check weiß man dann ohne langes Rumgefummel in Hex-Editoren relativ schnell, woran man ist.

Eine weitere Besonderheit beim Kopieren dieser CD über S/PDIF ist bei mir jedenfalls, dass der Anfang inklusive ABCDEF-Sequenz Player-seitig "verschluckt" wird, wenn die Wiedergabe direkt von STOP aus startet. Starte ich und halte den Player auf Pause bei 0:00, starte die Aufnahme am PC und drücke PLAY, geht nichts verloren.


Zusammenfassend kann man also sagen: ja, Bitgenauigkeit ist möglich und mit etwas Glück auch ganz einfach, jedoch lauern unzählige Stolpersteine vom Zuspieler über Kabel bis Empfänger, Betriebssystem, Treiber, Audioeditor.

So habe ich mit Audition und Audacity immer noch keine bitgenaue Aufnahme hinbekommen und bei der M-Audio Transit-USB das Problem, dass Daten zwar (trotz "shared"!) zwar nicht verfälscht werden (daher kam ich so spät darauf, das wieder umzustellen), jedoch Lücken aufweisen, also Samples flöten gehen. Keine Ahnung, woran das schon wieder liegt, aber es ist nervig. Von drei Soundkarten funktioniert es nun endlich mal mit einer, wie es soll. Und das nach mehr als einem Wochenende des sich-schwindlig-Überspielens.

cr (Beitrag #26) schrieb:

Mit der aktuellen Bitcompare-Version von Foobar (nur diese kann Offsets handhaben) kannst du feststellen, ob der Track (im Kern) bitidentisch zur gerippten WAV-Datei ist.

Vielen Dank noch für diesen Hinweis, das muss ich mal testen.

Habe mir bislang mit der "Vergleiche WAVs" - Funktion von EAC beholfen, nur werden hier offiziell natürlich nur Wave-Dateien akzeptiert, so dass man um Rohdaten erst Header basteln muss und außerdem ist EAC leider extrem zickig, was Offsets angeht. Eine Sekunde Stille etwa am Anfang ist da erfahrungsgemäß schon zu viel, so dass dann angeblich alle Samples unterschiedlich sind und es ewig dauert.

Da kann es dann wiederum einfacher und schneller sein, via Hex Editor eine Sequenz herauszugreifen, diese selbst als Synchronisationspunkt zu verwenden, beide Dateien zurechtzuschneiden und sie fc.exe vorzuwerfen.

... Asynchroner Modus/Jitterbekämpfung
Klangtrübender Jitter lässt sich am wirkungsvollsten vermeiden, indem man einen mit fester Frequenz schwingenden Systemtaktgeber möglichst dicht beim D/A-Wandler anordnet. Und genau das ist beim asynchronen USB-Modus möglich, weil hier die Zeitbasen von Computer und Outboard-DAC unabhängig voneinander arbeiten können.

Mein DAC Pre kann den asynchronen USB-Modus.

Bitgenau
Windows Vista (SP1 und höher) und Windows 7 verfügen über WASAPI, was entwickelt wurde, um einen bitgenauen Datenausgang zu erhalten.

Deswegen hat mein DAC Pre im Beipack Windowstreiber.

CD gerippt mit EAC dann auf ein Synology NAS dann gestreamt per cat7 kabel am Linn Majik DS. Genau oder nicht?

little-endian schrieb:

Eine weitere Besonderheit beim Kopieren dieser CD über S/PDIF ist bei mir jedenfalls, dass der Anfang inklusive ABCDEF-Sequenz Player-seitig "verschluckt" wird, wenn die Wiedergabe direkt von STOP aus startet. Starte ich und halte den Player auf Pause bei 0:00, starte die Aufnahme am PC und drücke PLAY, geht nichts verloren. [...] So habe ich mit Audition und Audacity immer noch keine bitgenaue Aufnahme hinbekommen und bei der M-Audio Transit-USB das Problem, dass Daten zwar (trotz "shared"!) zwar nicht verfälscht werden (daher kam ich so spät darauf, das wieder umzustellen), jedoch Lücken aufweisen, also Samples flöten gehen. Keine Ahnung, woran das schon wieder liegt, aber es ist nervig.

Hallo little-endian,

das "Verschlucken" insbesondere zu Beginn des Abspielens (und ferner auch zwischendurch), ist in der Regel durch eine Vergrößerung des Audiobuffers abspielseitig zu beheben. Manche Zuspieler schalten z.B. ihren Toslink erst ein, wenn ein Quellsignal detektiert wird oder wenn sie von STOP nach START "aufwachen". In dieser kurzen Initialisierungsphase können Audiodaten verloren gehen. Wenn man den Audiobuffer aber groß genug wählt, vergeht erst mehr Zeit, bis er gefüllt ist, und der S/PDIF-Link kann sich noch rechtzeitig etablieren. Bei mir reicht z.B. in Audacity ein Audiobuffer von 20 ms in der Regel schon aus (voreingestellt sind AFAIR 100 ms).

Manche CD-Player haben auch einen nichtabschaltbaren, kaum wahrnehmbaren Fade-In bei Titelstart, der die Datenintegrität unterläuft.