Bit-identisch ist nicht Wort-identisch??

[Herbert Z]

Liebe Foristen,

In einem Beitrag von Ralf Koschnicke bin ich auf folgenden Absatz gestossen:

Inzwischen hat Max meinen gesamten FLAC-Bestand brav in ALAC konvertiert und Stichprobenkontrollen haben Bit-identische Ergebnisse ergeben. Was will man mehr.

Gleich auf Bit-identisch kontrolliert habe ich aber nur deshalb, weil ALAC einen Tick schlechter als FLAC klingt. Hier wird es dann aber wieder verrückt … ein EDV-Spezialist hat mich neulich drauf gebracht, Bit-identisch heißt nicht Wort-identisch und vielleicht macht der unterschiedliche Aufbau des Datenwortes einen Unterschied für den Player …

Nun war ich aufgrund der hier geführten Diskussionen zum Schluss gelangt, es kommt bei den Daten auf die Bitidentität an und damit ist die Wiedergabequalität bei den digitalen Transportern ein Ergebnis wie die digitalen Daten Bitgenau als auch Tackgenau mit möglichst wenig Jitter im Wandler ankommen. Und nun behauptet ein EDV-Spezialist, dass nicht nur die Buchstaben des Alphabets (Bits) zählen, sondern das "gesproche" Wort.

Nun im richtigen Leben mag das so sein, gilt das für die Musikwiedergabe genauso, ist meine Frage hier im Forum? Oder wie sind hier die Zusammenhaege, auch verständlich dargestellt für einen nicht EDV-Spezialisten?

Schöne Grüße

Herbert

[Ralf Koschnicke]

Hallo Herbert,
besten Dank, dass Du den Teil aus dem anderen Thread auslagerst. Das Thema würde ich dort nämlich gerne nicht weiter vertiefen, weil es schon zugegeben in eine zunächst esoterisch klingende Richtung geht. Wenn wir darüber diskutieren wollen, so bitte ich aber einfach mal um ein ergebnisoffenes Herangehen, weil wir vermutlich alle nichts genaues wissen und deshalb genauso wie wir nichts sicher sagen können aber auch nichts sicher ausschließen können. Vielleicht kommen wir ja gemeinsam auf eine Lösung.

Zunächst noch ein "experimenteller Befund" zum Thema: Bei den ganzen Klangvergleichen versuche ich stets die Beurteilung der Wiedergabe im Vergleich zu einem Original als Referenz, das kann eine analoge Schallplatte oder die analoge Mischpultsumme sein. Die lasse ich über eine AD/DA-Strecke laufen die beim Durchschleifen bei 192kHz bereits fast keinen Unterschied zum Original zeigt. Somit kann ich später immer wieder eine Wiedergabe zu diesem Original – entweder echt Original oder nach AD/DA-Strecke - in Bezug setzen. Die Wiedergabe ist dann perfekt, wenn sie identisch mit der direkten AD/DA-Schleife ist.

Nun fällt folgendes sehr signifikant auf und jeder könnte das bei mir hören: Die Wiedergabe aus dem J.River Mediacenter klingt beim Abspielen der gleichen FLAC-Files auf Verzeichnisebene, aber auch über Netzwerkverbindung (also das File mit dem eingebauten Explorer ausgewählt), deutlich weniger dicht am Original als per UPnP-Stream vom NAS mit Twonky. Ich weiß, viele werden den Kopf schütteln. Ich würde es auch nicht glauben, würde mir das jemand berichten. Also vielleicht die erste Bitte: Wer die Möglichkeit hat, soll es bitte testen. Es reicht ja schon, wenn man einen Unterschied feststellt, egal in welche Richtung. Beides müsste eigentlich absolut identisch klingen.

In beiden Fällen kommen die gleichen Bits raus. Nur das geöffnete FLAC-File in dem ersten Fall und der Datenstream vom UpnP-Server unterscheiden sich ja vermutlich deutlich in ihrer inneren Zusammensetzung. Vielleicht liest jemand mit, der weiß wie die Bits im FLAC angeordnet sind und wie in einem Stream vom UPnP-Server?
Nun wird es dann komplex und ich fürchte an der Stelle auf theoretischer Ebene nicht weiterzukommen. Jetzt müsste man wissen, wie diese unterschiedliche Anordnung der Bits im Datenstrom im Rechner weiter behandelt werden und dann trotz aller Einflüsse, mindestens durch den Treiber der Audioschnittstelle und diese selbst, im Wandlerchip noch für unterschiedliche Bedingungen sorgen sollen. Dazu müsste man wissen, wie der Empfängerbaustein im DAC überhaupt erst einmal die eingehenden Daten aufbereitet. Fragen über Fragen …

Vielleicht hilft aber auch ein anderer Ansatz: Seit Computer Einzug in die Audiowelt gehalten haben, gibt es diverse Effekte, die immer in die gleiche Richtung deuten: Je mehr Systemlast desto kritischer für den Klang. Dieses ganze CMP und Cplay handelt ja auch von nichts anderem. Das wird vielfach diskutiert. Vielleicht verursacht der UPnP-Stream eine andere Last als ein File. Für die Rechner-interne Datenverarbeitung sind das doch vermutlich völlig unterschiedliche Ausgangslagen? So etwas könnte dann auch Unterschiede zwischen ALAC und FLAC erklären, denn vielleicht ist das Dekodieren des einen rechenintensiver als das Dekodieren des anderen Formats? Oder bei nicht komprimierten Formaten wie AIFF und WAV ist die Datenrate ja doppelt so hoch und das belastet das System unter Umständen mehr als das Entpacken eines FLAC-Files das dafür die halbe Datenrate erfordert.

Ich habe Zweifel, ob eine Diskussion darüber etwas bringt, weil mir die Sache zu komplex erscheint, aber mal sehen …

Grüße
Ralf

[mm2]

Hallo Ralf,

In beiden Fällen kommen die gleichen Bits raus.

d.h. die Daten sind Bit-dentisch.

Die Wiedergabe aus dem J.River Mediacenter klingt beim Abspielen der gleichen FLAC-Files auf Verzeichnisebene, aber auch über Netzwerkverbindung (also das File mit dem eingebauten Explorer ausgewählt), deutlich weniger dicht am Original als per UPnP-Stream vom NAS mit Twonky. Ich weiß, viele werden den Kopf schütteln

Computer wurden auf Bit-dentische Verarbeitung getrimmt.
Das müssen sie perfekt beherrschen sonst würden sie ( noch öfter ) abstürzen.

Jedoch beschreibst Du zwei verschiedene Transportwege. Dazu werden die Daten unterschiedlich verpackt und unterschiedlich übertragen, werden von unterschiedlichen Treibern empfangen und wieder ausgepackt, am Ende hast Du wieder aber die identischen Bits.
Es gibt also viele Unterschiede und eine wichtige Gemeinsamkeit.

Mal ein nicht ganz ernst gemeinter Vergleich

Das könnte man in etwa so Vergleichen als würdest Du die gleiche Ware einmal über DHL an Deine Postadresse, einmal an Deine Packstation und einmal per UPS zuschicken lassen .
Die Ware würde dreimal vermutlich höchst unterschiedliche Wege bis zu Dir nehmen,
von anderen Menschen und Maschinen bearbeitet werden. Die Verpackung würde unterschiedlich leiden und sehr wahrscheinlich würden die Pakete auch zu unterschiedlichen Zeitpunkten bei Dir ankommen. Nach dem Auspacken solltest Du aber die identische Ware in Händen halten .

Womit wir nun im übertragenen Sinn bei Jitter angekommen sind.
Die Unterschiede in der Übermittlung der Audiodaten werden vermutlich auch zu unterschiedlichen Jitterspektren führen, die ein möglicher Grund für die gehörten Unterschiede sind.
Kannst Du bitte genauer beschreiben wie sich die Unterschiede für Dich anhören ?

Grüße
Maximilian

[Ralf Koschnicke]

Maximilians Beispiel mit den Paketdiensten hat was. Der Jitter zwischen den Diensten ist sicher groß.

Aber vielleicht hilft folgendes Paper weiter:
http://www.amr-audio.co.uk/large_image/ ... 20Mode.pdf

Stichwort: "RF interference"

Den Verdacht habe ich ja bereits lange und hier hört sich das sehr plausibel an. Weil der Audirvana Player des Herren auch wirklich sehr überzeugt, unterstelle ich ihm gewisse Kompetenz. Der Aspekt taugt auf jeden Fall zur Erklärung vieler Dinge, ob nun unterschiedlicher Playerklang, konventionelle HD gegen Solid State Disc etc.
Wobei der Schwarze Peter dann eigentlich bei den DAC- bzw. Interface-Kontrukteuren liegt: Warum verdammt nochmal ist es so schwierig, den HF-Müll aus dem DAC rauszuhalten und diesen gegen Jitter immun zu machen

Viele Grüße
Ralf

[vincent kars]

There are claims that the amount of electrical activity inside a PC affects sound quality.
This assumes that CPU, I/O or simply ripples on the power rails affect the clock driving the DA conversion.

JRiver/FLAC from HD. There is the I/O needed to read the file and some CPU to decode the FLAC to lpcm.

Streaming is buffering data straight in memory so no access to the HD.
It is even possible that the server might do the decoding depending on the settings.
In the end the same bits are delivered to the DAC but the amount of ‘noise’ generated by the PC might differ and as a consequence the amount of sample rate jitter.

An interesting experiment would be:
Twonky – JRiver as is.
JRiver with FLAC on the local HD with Memory playback on.
This should eliminated the HD as an factor.
It might be wise to have the Windows Recourse Monitor on in both cases and keep a keen eye on amount of CPU and I/O on the HD.


Part of the “problem” with DACs is the protocol.
SPDIF is a real time stream so the input jitter is as high or as low as the quality of the clock of the sender allows for.
What we need is an asynchronous protocol decoupling DAC clockking from the source.
Asynchronous USB is an example. It is often combined with galvanic isolation to avoid all kind of stray signal from the PC to enter the DAC.

[RC23]

... Nun fällt folgendes sehr signifikant auf und jeder könnte das bei mir hören: Die Wiedergabe aus dem J.River Mediacenter klingt beim Abspielen der gleichen FLAC-Files auf Verzeichnisebene, aber auch über Netzwerkverbindung (also das File mit dem eingebauten Explorer ausgewählt), deutlich weniger dicht am Original als per UPnP-Stream vom NAS mit Twonky.

Hallo Ralf,

wie würdest Du den JRiver-Klang beschreiben? Du schreibst er sei nicht so nah am Original wie etwa Twonky. In welche Richtung verschiebt sich bei JRiver der Klang?

Grüße

Rüdiger