Freunde,
wenn wir über digitale Schnittstellen diskutieren wollen, dann müssen wir doch präzisieren:
1. meinen wir nur die Verbindung zweier Komponenten ?
und falls ja, dann
a) Verarbeitung durch Empfänger in Echtzeit ?
b) Speichern der Daten durch Empfänger ?
2. oder schliessen wir dabei noch digitale Datenumwandlungen, z.B. 16 bit auf 24 bit oder Upsampling mit ein ?
Grüsse, Uli
Sind analoge Schnittstellen besser als digitale?
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Nein, Rudolf. So wird nur derjenige denken oder argumentieren, der stets nur "entweder - oder" kennt bzw. digital gegen analog setzen will. Beides kann wunderbar funktionieren, wenn man die nötige Sorgfalt walten läßt. Das bezieht sich auch auf die Auswahl der Tonträger, denn deren Aufnahmequalität ist als Quelle für mich der ganz zentrale Punkt. Stimmt die nicht, ist es völlig egal, ob ich nun analog oder digital bevorzugend höre. Mist bleibt dann Mist.Rudolf hat geschrieben:wobei man den Griff zum Plattenspieler als eine vollständige "Kapitulation" vor der Komplexität des digitalen Übertragungsweges ansehen könnte.
Ich höre beides mit dem größten Vergnügen. 
Gruß
Franz
Hallo Bernd Peter,
Nochmals: Ich selbst favorisiere die Digitalübertragung und bin gerne bereit meine Zeit in die Optimierung der Anpassung von Digitalkomponenten zu stecken. So sind aber nicht alle HiFi-isten gestrickt. Das hat Linn anscheinend erkannt und sich entschlossen, die D/A-Wandlung wieder vollständig in die eigenen Hände zu nehmen - mit offensichtlich hervorragendem Ergebnis!
Viele Grüße
Rudolf
da habe ich mich wohl missverständlich ausgedrückt: ich meinte nicht das "Einzementieren" des digitalen Signals sondern der darin enthaltenen Klanginformation, die am digitalen Ausgang infolge inkompatibler Weiterverarbeitung eher verhunzt werden kann als bei analoger Weitergabe.Bernd Peter hat geschrieben:es gibt m.E. keinen technischen Grund, das digitale Signal "einzuzementieren".
Das habe ich früher auch immer gedacht, sehe dies aber angesichts meiner Fragestellung heute anders.Bei Linn ist es m.E. eine interne Produktlinienentscheidung, die man als kundenunfreundlich kommentieren kann, aber kaufmännisch Sinn macht.
Das ist von mir unbestritten, ebenso wie klar geworden sein sollte, das es im Zusammenspiel mit weiteren digitalen Komponenten eben doch zu einer "Signalverschlechterung" kommen kann, die auf analogem Wege so nicht möglich ist.Ein Qualitätsverlust des Signals durch einen Digitalausgang gibt es nicht
Nochmals: Ich selbst favorisiere die Digitalübertragung und bin gerne bereit meine Zeit in die Optimierung der Anpassung von Digitalkomponenten zu stecken. So sind aber nicht alle HiFi-isten gestrickt. Das hat Linn anscheinend erkannt und sich entschlossen, die D/A-Wandlung wieder vollständig in die eigenen Hände zu nehmen - mit offensichtlich hervorragendem Ergebnis!
Viele Grüße
Rudolf
Hallo Uli,
Meine Eingangsfrage also reloaded: Ist eine analoge Übertragungskette prozesssicherer als eine digitale?
Viele Grüße
Rudolf
ich plädiere für 2., schon alleine deshalb, weil die Datenumwandlungen oftmals ohne Kenntnis des Anwenders stattfinden (und er dies dann fälschlicherweise der Quelle - oder umgekehrt: dem Wandler - zuschreibt).uli.brueggemann hat geschrieben:wenn wir über digitale Schnittstellen diskutieren wollen, dann müssen wir doch präzisieren:
1. meinen wir nur die Verbindung zweier Komponenten ?
[...]
2. oder schliessen wir dabei noch digitale Datenumwandlungen, z.B. 16 bit auf 24 bit oder Upsampling mit ein ?
Meine Eingangsfrage also reloaded: Ist eine analoge Übertragungskette prozesssicherer als eine digitale?
Viele Grüße
Rudolf
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Wenn 2. eingeschlossen wird, ja genau dann wird es nämlich richtig spannend. Weil dann nämlich zum Thema Bitgenauigkeit etc. reichlich Quatsch durch die Foren geistert.Rudolf hat geschrieben:ich plädiere für 2., schon allein deshalb, weil die Datenumwandlungen oftmals ohne Kenntnis des Anwenders stattfinden (und er dies dann fäschlicherweise der Quelle - oder umgekehrt: dem Wandler - zuschreibt).
Meine Eingangsfrage also reloaded: Ist eine analoge Übertragungskette prozesssicherer als eine digitale?
Ein "simples" Beispiel und gleichzeitig Beweis ist hier das intersample clipping. Dahinter steckt der wahre Spitzenwert, der oberhalb der Vollaussteuerung liegt. Leider beachten das die meisten Studios nicht bzw. ignorieren ihn bewusst wegen dem Loudness Race. Zwar liegen alle Samples des Tracks im zulässigen Bereich, das ändert sich aber schlagartig bei Abtastratenkonvertierung. Und dann kommen da die wildesten Ergebnisse raus (cMP² eingeschlossen
).Was bei der analogen Kette nicht passiert, es sei denn dass ein Ausgang einen Eingang übersteuert. Im Vergleich hierzu übersteuert das digitale Signal bereits selbst.
Perfidia digitalis lat. = digitale Tücke
Gruss, Uli
So nagativ würde ich das nicht sehen. Der Griff zum Plattenspieler würde ich eher als Rückbesinnung auf die optimale Wiedergabe verstehen (entsprechende Gerätschaften vorausgesetzt) und er kann dazu dienen, den digitalen Hörgenuß in diese analoge Richtung zu optimieren.Rudolf hat geschrieben:...wobei man den Griff zum Plattenspieler als eine vollständige "Kapitulation" vor der Komplexität des digitalen Übertragungsweges ansehen könnte.
Stefan (der zumindest momentan keine Platte hört)
Hallo Rudolf,
Ich kann gut nachvollziehen, dass die Thesen mit der asynchronen Übertragung den meisten nicht verständlich ist, denn S/PDIF und adaptiver USB ist nunmal der gängige Standard. Die Zweifler müssen ihre Denkweise umstellen um es zu verstehen.
Jedes digitale Gerät hat eine Clock. Ein Netzwerkplayer, ein DAC und auch ein Computer haben eine. Jeder dieser Clocks bestimmt die Genauigkeit mit der dieses Gerät seine Samplingrate und seine Datenverarbeitung hinbekommt. Implizit liegt auch hier die Ursache des Jitters eines Geräts. Ein hochwertiger Netzwerkplayer hat mit seinem schlankem Betriebsystem und einer eher hochwertigen Clock einen deutlichen Vorsprung gegenüber einem normalen Computer. Meist weil der Netzplayer nicht so viel Multitasking & Interrupts & Prozesse durchführen muss wie ein Computer es zwangsläufig tut. Daher ist ein Netzplayer das eigentlich bessere Gerät um jitterfreie Daten zu liefern ...
... wäre da nicht diese S/PDIF bzw. adaptive USB-Schnittstelle dazwischen.
Beide Übertragungsmodi benutzen den Taktgeber des jeweiligen Geräts. Wären das sendende Gerät und das Kabel dazwischen nun völlig/total jitterfrei, könnte dies auch gut funktionieren. Ist aber leider nicht so.
USB Controller sind notorisch "zappelig" weil Plug n´Play abfragen ständig im Hintergrund laufen, und die S/PDIF Sender/Empfängerbausteine (vor- und nach dem Kabel) oftmals selber jitterbehaftet sind und bestimmt nicht absolut synchron zur Empfänger-Clock des DAC laufen.
Der einzige Weg, die Kommunikation perfekt zu synchronisieren ist wenn nur die Clock des D/A Wandlers die völlige Kontrolle über den Takt des Zuspielers hat. Und das geht nur wenn (ich sage es noch mal) die Taktung und die Daten asynchron übertragen werden: FireWire, USB asynchron (mit entsprechenden Treiber) oder I2S - oder wenn man wie Linn das alles intern regelt.
Erst dann bestimmt die Präzision der Clock im DAC wie jitterfrei es wird. Es ist dabei auch völlig logisch warum ein BigBen Reclocker in vielen Systemen so entscheidend besser klingt.
Gruß Leif
Nein, das kann man nicht so sagen, aber eine digitale (Schnittstellen-)Übertragung von einem Gerät zum anderen Gerät ist einfach komplizierter.Rudolf hat geschrieben:Ist eine analoge Übertragungskette prozesssicherer als eine digitale?
Ich kann gut nachvollziehen, dass die Thesen mit der asynchronen Übertragung den meisten nicht verständlich ist, denn S/PDIF und adaptiver USB ist nunmal der gängige Standard. Die Zweifler müssen ihre Denkweise umstellen um es zu verstehen.
Jedes digitale Gerät hat eine Clock. Ein Netzwerkplayer, ein DAC und auch ein Computer haben eine. Jeder dieser Clocks bestimmt die Genauigkeit mit der dieses Gerät seine Samplingrate und seine Datenverarbeitung hinbekommt. Implizit liegt auch hier die Ursache des Jitters eines Geräts. Ein hochwertiger Netzwerkplayer hat mit seinem schlankem Betriebsystem und einer eher hochwertigen Clock einen deutlichen Vorsprung gegenüber einem normalen Computer. Meist weil der Netzplayer nicht so viel Multitasking & Interrupts & Prozesse durchführen muss wie ein Computer es zwangsläufig tut. Daher ist ein Netzplayer das eigentlich bessere Gerät um jitterfreie Daten zu liefern ...
... wäre da nicht diese S/PDIF bzw. adaptive USB-Schnittstelle dazwischen.
Beide Übertragungsmodi benutzen den Taktgeber des jeweiligen Geräts. Wären das sendende Gerät und das Kabel dazwischen nun völlig/total jitterfrei, könnte dies auch gut funktionieren. Ist aber leider nicht so.
USB Controller sind notorisch "zappelig" weil Plug n´Play abfragen ständig im Hintergrund laufen, und die S/PDIF Sender/Empfängerbausteine (vor- und nach dem Kabel) oftmals selber jitterbehaftet sind und bestimmt nicht absolut synchron zur Empfänger-Clock des DAC laufen.
Der einzige Weg, die Kommunikation perfekt zu synchronisieren ist wenn nur die Clock des D/A Wandlers die völlige Kontrolle über den Takt des Zuspielers hat. Und das geht nur wenn (ich sage es noch mal) die Taktung und die Daten asynchron übertragen werden: FireWire, USB asynchron (mit entsprechenden Treiber) oder I2S - oder wenn man wie Linn das alles intern regelt.
Erst dann bestimmt die Präzision der Clock im DAC wie jitterfrei es wird. Es ist dabei auch völlig logisch warum ein BigBen Reclocker in vielen Systemen so entscheidend besser klingt.
Gruß Leif
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4007
- Registriert: 04.05.2010, 19:37
Hallo Rudolf,
was genau meinst Du mit
Wenn der SPDIF gut gemacht ist (da hat einer oder haben zwei aus dem Forum eine sehr saubere Lösung entwickelt), kein Problem.
Wenn der USB etc. asynchron arbeitet und gut gemacht ist (wie exakt ist die Clock des DAC, wie gut ist der Treiber für den Chip programmiert), kein Problem.
Wenn I2S enhanced gut gemacht ist (welche Kabel, welche Buchsen - RJ45, HDMI, Koax), kein Problem.
Alle digitalen Übertragungswege zwischen 2 Geräten können sehr gut sein, es ist doch die Sorgfalt bei der technischen Ausführung. Umgekehrt haben die all-in-one-Geräte auch ihre grundsätzlich technischen Schwierigkeiten.
Gruß
Bernd Peter
was genau meinst Du mit
?Rudolf hat geschrieben:die am digitalen Ausgang infolge inkompatibler Weiterverarbeitung eher verhunzt werden kann als bei analoger Weitergabe.
Wenn der SPDIF gut gemacht ist (da hat einer oder haben zwei aus dem Forum eine sehr saubere Lösung entwickelt), kein Problem.
Wenn der USB etc. asynchron arbeitet und gut gemacht ist (wie exakt ist die Clock des DAC, wie gut ist der Treiber für den Chip programmiert), kein Problem.
Wenn I2S enhanced gut gemacht ist (welche Kabel, welche Buchsen - RJ45, HDMI, Koax), kein Problem.
Alle digitalen Übertragungswege zwischen 2 Geräten können sehr gut sein, es ist doch die Sorgfalt bei der technischen Ausführung. Umgekehrt haben die all-in-one-Geräte auch ihre grundsätzlich technischen Schwierigkeiten.
Gruß
Bernd Peter
Hallo Bernd Peter,
vielen Dank für deine Erläuterungen, weshalb es mit einem Computer besser gehen kann. Insbesondere die "normalen User" werden diesen Weg aber nicht unbedingt gehen wollen. (Insbesondere auch deshalb nicht, weil eine falsche Konfiguration die theoretischen Vorteile schnell wieder über den Haufen werfen kann.)
Viele Grüße
Rudolf
z.B. dies:Bernd Peter hat geschrieben:Hallo Rudolf,
was genau meinst Du mit
Rudolf hat geschrieben:die am digitalen Ausgang infolge inkompatibler Weiterverarbeitung eher verhunzt werden kann als bei analoger Weitergabe.
Hallo Leif,uli.brueggemann hat geschrieben:Ein "simples" Beispiel und gleichzeitig Beweis ist hier das intersample clipping. Dahinter steckt der wahre Spitzenwert, der oberhalb der Vollaussteuerung liegt. Leider beachten das die meisten Studios nicht bzw. ignorieren ihn bewusst wegen dem Loudness Race. Zwar liegen alle Samples des Tracks im zulässigen Bereich, das ändert sich aber schlagartig bei Abtastratenkonvertierung. Und dann kommen da die wildesten Ergebnisse raus.
vielen Dank für deine Erläuterungen, weshalb es mit einem Computer besser gehen kann. Insbesondere die "normalen User" werden diesen Weg aber nicht unbedingt gehen wollen. (Insbesondere auch deshalb nicht, weil eine falsche Konfiguration die theoretischen Vorteile schnell wieder über den Haufen werfen kann.)
Viele Grüße
Rudolf
Hallo Rudolf,
Diese Problematik ist aber nicht spezifisch für Computer! - aber eher ein Problem der Hersteller von DACs.
Externe DACs sind meist als Interfaces zu Computern zu verstehen, denn dort werden solche eingesetzt.
Man darf nicht vergessen dass wir Audiophile eigentlich nur (noch) eine Randerscheinung im Markt von D/A Wandler sind.
Dies ganz generell.
Der weitere entscheidende Faktor (aber unabhängig von der Übertragung) ist wie der DAC seine Daten bekommt. Es macht gar keinen Sinn die Daten im DAC Up-zu-Samplen; es muss vor der digitalen Übertragung passieren um einen Nutzen zu ergeben -und die Daten müssen auch wirklich interpoliert werden. D.h. es müssen neue Samplingpunkte entstehen um kürzere Intervalle der Übertragung zu ermöglichen. Nur dann verbessert man auch die Präzision bzw. die Jitter-Werte.
-auch das macht der Linn ganz gut mit dem Xilinx Virtex-4 FPGA.
Kurz um : digitale Geräte sind einzeln nicht besser, als wie sie zusammen die Datenpakete zeitkorrekt am Wandlerchip liefern.
L.
das verstehe ich schon ganz genau, aber leider ziehen sich viele Konsumenten mit in den Zog das USB und S/PDIF einfach prima ist. Wenn wir schon darüber lernen wollen, gehören auch die unbequemen Wahrheiten dazu.Rudolf hat geschrieben:Insbesondere die "normalen User" werden diesen Weg aber nicht unbedingt gehen wollen.
Diese Problematik ist aber nicht spezifisch für Computer! - aber eher ein Problem der Hersteller von DACs.
Externe DACs sind meist als Interfaces zu Computern zu verstehen, denn dort werden solche eingesetzt.
Man darf nicht vergessen dass wir Audiophile eigentlich nur (noch) eine Randerscheinung im Markt von D/A Wandler sind.
Dies ganz generell.
Der weitere entscheidende Faktor (aber unabhängig von der Übertragung) ist wie der DAC seine Daten bekommt. Es macht gar keinen Sinn die Daten im DAC Up-zu-Samplen; es muss vor der digitalen Übertragung passieren um einen Nutzen zu ergeben -und die Daten müssen auch wirklich interpoliert werden. D.h. es müssen neue Samplingpunkte entstehen um kürzere Intervalle der Übertragung zu ermöglichen. Nur dann verbessert man auch die Präzision bzw. die Jitter-Werte.
-auch das macht der Linn ganz gut mit dem Xilinx Virtex-4 FPGA.
Kurz um : digitale Geräte sind einzeln nicht besser, als wie sie zusammen die Datenpakete zeitkorrekt am Wandlerchip liefern.
L.
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4007
- Registriert: 04.05.2010, 19:37
Hallo Rudolf,
die Abtastratenkonvertierung würde ich aber nicht in Abhängigkeit zur digitalen Schnittstelle sehen.
Wenn ich als Hersteller alle Kundenwünsche abdecken möchte, würde ich auch Komplettgeräte anbieten, schaut doch im Rack sehr aufgeräumt aus. Wenn das gut sein soll, kostet es aber auch.
Restek macht es ähnlich, der EPOS ist CD-Laufwerk, DAC und VV in einem, zusätzlich hat er aber auch digitale Ausgänge. Finde ich fair und besser gegenüber dem Kunden.
Gruß
Bernd Peter
die Abtastratenkonvertierung würde ich aber nicht in Abhängigkeit zur digitalen Schnittstelle sehen.
Wenn ich als Hersteller alle Kundenwünsche abdecken möchte, würde ich auch Komplettgeräte anbieten, schaut doch im Rack sehr aufgeräumt aus. Wenn das gut sein soll, kostet es aber auch.
Restek macht es ähnlich, der EPOS ist CD-Laufwerk, DAC und VV in einem, zusätzlich hat er aber auch digitale Ausgänge. Finde ich fair und besser gegenüber dem Kunden.
Gruß
Bernd Peter
-
realperfekt
- Aktiver Hörer
- Beiträge: 543
- Registriert: 24.01.2008, 22:45
- Wohnort: Bochum
... das sehe ich auch so.Bernd Peter hat geschrieben: Wenn ich als Hersteller alle Kundenwünsche abdecken möchte, würde ich auch Komplettgeräte anbieten, schaut doch im Rack sehr aufgeräumt aus.
Wenn ich aber den Finger selber auf die Wunde legen kann und darüber hinaus ein System habe, das aus externen DACs besteht (z.B. BM Line Serie), dann ist es schon verdammt verlockend, konsequent auf digitaler Ebene zu bleiben, denn hier gilt auch "weniger ist mehr"! Der Weg ist sicher dornenreicher, das Ziel sowohl technisch, als auch qualitativ effizienter, gell Leif!
Und Rudolf, wenns das System hergibt, kann das analoge Gedöns seine Signale gleich in den LS-eigenen AD einspielen - und man hat eine saubere Trennung der Welten.
Für mich derzeit die sauberste Lösung!
Peter
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo zusammen,
ich hab da mal was zusammengestellt, um die Problematik der Abtastratenwandlung an und für sich als auch bei der digitalen Signalübertragung aufzuzeigen.
Ausgangspunkt ist ein Testsignal in 44/16, welches zugegebenermassen teuflisch ist.
Alle Samples sind im zulässigen Bereich, entweder maximal 32768 oder minimal -32768. Dies dient einfach zur Extremdarstellung des Intersample-Cliipings, im Prinzip könnten die Amplituden auch kleiner sein, ohne prinzipiell was zu ändern.
Fangen wir mit dem Ausgangssignal an, dargestellt im nächsten Bild:
Das Bild ist dargestellt mit Adobe Audition, es zeigt zum einen die Abtastpunkte (wichtig! auf diese kommt es an) und macht eine graphische Interpolation, die ganz gut gelungen ist (wichtig! nicht ganz genau nehmen, nur als Anhaltspunkt1)
Wir erkennen in der Bildmitte einen großen Peak, im Bild ca. 8.5 dB über der weissen 0 dB-Linie (die den maximal erlaubten Bereich kennzeichnet!), in Wirklichkeit über 11.2 dB hoch. Eine korrekte Rekonstruktion des Testsignals müsste analog eine solche Signalspitze aufweisen !!
Wenn wir nun so ein Signal übertragen wollen, 1:1, dann ist dies im Prinzip einfach möglich (wir betrachten hier diesmal nicht das Jitter-Problem). Wenn nun aber entweder im Sender oder aber im Empfänger eine Abtastratenwandlung stattfindet, entweder per Software oder per SRC-Chip, dann wird es spannend.
Ich habe das für 3 Beispiele durchgeführt, hierbei einmal nach 176,4/32 gewandelt, also Vervierfachung der Abtastrate, und dann wieder zurück nach 44.1 kHz. Im perfekten Fall würde da wieder dasselbe herauskommen wie das Eingangssignal.
Idealfall also mit Umwandlung nach 176.4 kHz:
und dann wieder zurück nach 44.1 kHz:
Die Hin- und Rückwandlung ist durchgeführt mit einem sehr langen sinc-Filter mit 65536 taps. Es ist vielleicht interessant zu wissen: beim Upsampling muss ein Filter eingesetzt werden, um Frequenzen über 22050 Hz herauszufiltern, die ja im Originalsignal nicht vorhanden sind.
Nun könnte ja das 176.4 kHz-Signal ja auch noch vor der Rückwandlung irgendwelche Bearbeitungen erfahren haben, welche ihrerseits Frequenzen über 22050 Hz erzeugen (z.B. Limiter). Demzufolge MUSS vor der Rückwandlung noch ein zweites Mal die Bandbreite begrenzt werden, also ein weiteres Mal gefiltert werden. Das ist auch hier der Fall.
Nun denn, wie zu erkennen, liegen die Punkte des rückgewandelten Signals doch mehr oder weniger da wo sie hingehören
Schauen wir uns das Ganze mal mit dem Abtastratenkonverter von Audition an, zuerst in Richtung 176.4 kHz:
und dann zurück nach 44.1 kHz:
Es sollte jedem sofort klar werden, dass das rückgewandete Ausgangssignal nicht mehr dem Eingangssignal entspricht.
Nun gut, an dieser Stelle haben wir beim Upsampling und für das Downsampling die Berechnung innerhalb Audition mit 32 bit Gleitkomma durchgeführt. Und was kommt heraus, wenn man aber bereits das hochgesampelte Signal weiterverwenden will, z.B. im DA-Wandler? Da wird denn aus 16 bit PCM bestenfalls 24 bit PCM. Weil aber 0 dBFS = 0 dB full scale, also Ende der Fahnenstange bedeutet, bleibt nichts anderes übrig, als alles was bei Gleitkomma über 0 dBFS hinausgeht, bei Festkomma abzuschneiden bzw. auf 0 dBFS zu limitieren. Was dann seinerseits Klirr, also Unharmonische erzeugt.
Bitte behaltet einfach im Hinterkopf, dass im Rahmen des Loudness Race heute praktisch 70-80% aller CDs ein intersample clipping aufweisen !! Eine korrekte digitale Übertragung mit ASRC klappt damit nicht.
Ok, noch ein Praxisbeispiel. Ich habe nun aufgrund der häufigen Bewerbung hinsichtlich Bitgenauigkeit, Rechnentiefe und optimale Interpolation das cPlay angeworfen. Hierbei den SRC 145 dB (secret rabbit code) gewählt, also nach 176.4 kHz upgesampelt und die vorgegebene ASIO-Ausgabe in Richtung spdif gelenkt. Und dann mit meiner Fireface 400 das Ausgangssignal direkt digital aufgezeichnet.
Das Ergebnis der 176.4 kHz-Ausgabe:
Wir erkennen bereits hier ein Einschnüren des Signal, aber eben zusätzlich noch die Begrenzung der Peaks auf max. 0 dBFS. Ok, dieses 176.4 kHz-Signal nun wiederum per cPlay ausgegeben und mit secret rabbit nach 44.1 gewandelt ergibt:
Ich erspare mir hier eine analytische Bewertung mit einer einzigen Ausnahme: wenn jemand feststellt, dass ihm die Wiedergabe mit cPlay gefällt, so ist das für mich ok. Wenn jemand das aber mit Rechenalgorithmen und Bitgenauigkeit begründet, so liegt er schief.
Zusammenfassung:
Bei der digitalen Übertragung mit Abtastratenwandlern in der Signalkette ergeben sich im allgemeinen irgendwelche Resultate, auf die der geneigte Hörer selbst keinen Einfluss hat. Ausser, er findet das eine oder andere Resultat schlichtweg beim Hören besser. Was aber nicht bedeutet, dass er damit dann richtiger hört.
Nun ist das verwendete Testsignal ein extremes Signal, um eben die Fallstricke zu verdeutlichen. Gott sei Dank sind die realen Signale gutmütiger, aber trotzdem scheinen die kleinen Effekte sich dahingehend bemerkbar zu machen, als dass eben bei der einen oder anderen Wiedergabekette etwas zu bemängeln oder zu loben ist. Klar sollte sein, dass heutige Systeme noch weit weg von der perfekten und bitgenauen digitalen Übertragung sind. Die verwendeten Filter sind hierfür allemal zu kurz.
Ich wünsche Euch eine nette Diskussion
Grüsse, Uli
ich hab da mal was zusammengestellt, um die Problematik der Abtastratenwandlung an und für sich als auch bei der digitalen Signalübertragung aufzuzeigen.
Ausgangspunkt ist ein Testsignal in 44/16, welches zugegebenermassen teuflisch ist.
Alle Samples sind im zulässigen Bereich, entweder maximal 32768 oder minimal -32768. Dies dient einfach zur Extremdarstellung des Intersample-Cliipings, im Prinzip könnten die Amplituden auch kleiner sein, ohne prinzipiell was zu ändern.
Fangen wir mit dem Ausgangssignal an, dargestellt im nächsten Bild:
Das Bild ist dargestellt mit Adobe Audition, es zeigt zum einen die Abtastpunkte (wichtig! auf diese kommt es an) und macht eine graphische Interpolation, die ganz gut gelungen ist (wichtig! nicht ganz genau nehmen, nur als Anhaltspunkt1)
Wir erkennen in der Bildmitte einen großen Peak, im Bild ca. 8.5 dB über der weissen 0 dB-Linie (die den maximal erlaubten Bereich kennzeichnet!), in Wirklichkeit über 11.2 dB hoch. Eine korrekte Rekonstruktion des Testsignals müsste analog eine solche Signalspitze aufweisen !!
Wenn wir nun so ein Signal übertragen wollen, 1:1, dann ist dies im Prinzip einfach möglich (wir betrachten hier diesmal nicht das Jitter-Problem). Wenn nun aber entweder im Sender oder aber im Empfänger eine Abtastratenwandlung stattfindet, entweder per Software oder per SRC-Chip, dann wird es spannend.
Ich habe das für 3 Beispiele durchgeführt, hierbei einmal nach 176,4/32 gewandelt, also Vervierfachung der Abtastrate, und dann wieder zurück nach 44.1 kHz. Im perfekten Fall würde da wieder dasselbe herauskommen wie das Eingangssignal.
Idealfall also mit Umwandlung nach 176.4 kHz:
und dann wieder zurück nach 44.1 kHz:
Die Hin- und Rückwandlung ist durchgeführt mit einem sehr langen sinc-Filter mit 65536 taps. Es ist vielleicht interessant zu wissen: beim Upsampling muss ein Filter eingesetzt werden, um Frequenzen über 22050 Hz herauszufiltern, die ja im Originalsignal nicht vorhanden sind.
Nun könnte ja das 176.4 kHz-Signal ja auch noch vor der Rückwandlung irgendwelche Bearbeitungen erfahren haben, welche ihrerseits Frequenzen über 22050 Hz erzeugen (z.B. Limiter). Demzufolge MUSS vor der Rückwandlung noch ein zweites Mal die Bandbreite begrenzt werden, also ein weiteres Mal gefiltert werden. Das ist auch hier der Fall.
Nun denn, wie zu erkennen, liegen die Punkte des rückgewandelten Signals doch mehr oder weniger da wo sie hingehören
Schauen wir uns das Ganze mal mit dem Abtastratenkonverter von Audition an, zuerst in Richtung 176.4 kHz:
und dann zurück nach 44.1 kHz:
Es sollte jedem sofort klar werden, dass das rückgewandete Ausgangssignal nicht mehr dem Eingangssignal entspricht.
Nun gut, an dieser Stelle haben wir beim Upsampling und für das Downsampling die Berechnung innerhalb Audition mit 32 bit Gleitkomma durchgeführt. Und was kommt heraus, wenn man aber bereits das hochgesampelte Signal weiterverwenden will, z.B. im DA-Wandler? Da wird denn aus 16 bit PCM bestenfalls 24 bit PCM. Weil aber 0 dBFS = 0 dB full scale, also Ende der Fahnenstange bedeutet, bleibt nichts anderes übrig, als alles was bei Gleitkomma über 0 dBFS hinausgeht, bei Festkomma abzuschneiden bzw. auf 0 dBFS zu limitieren. Was dann seinerseits Klirr, also Unharmonische erzeugt.
Bitte behaltet einfach im Hinterkopf, dass im Rahmen des Loudness Race heute praktisch 70-80% aller CDs ein intersample clipping aufweisen !! Eine korrekte digitale Übertragung mit ASRC klappt damit nicht.
Ok, noch ein Praxisbeispiel. Ich habe nun aufgrund der häufigen Bewerbung hinsichtlich Bitgenauigkeit, Rechnentiefe und optimale Interpolation das cPlay angeworfen. Hierbei den SRC 145 dB (secret rabbit code) gewählt, also nach 176.4 kHz upgesampelt und die vorgegebene ASIO-Ausgabe in Richtung spdif gelenkt. Und dann mit meiner Fireface 400 das Ausgangssignal direkt digital aufgezeichnet.
Das Ergebnis der 176.4 kHz-Ausgabe:
Wir erkennen bereits hier ein Einschnüren des Signal, aber eben zusätzlich noch die Begrenzung der Peaks auf max. 0 dBFS. Ok, dieses 176.4 kHz-Signal nun wiederum per cPlay ausgegeben und mit secret rabbit nach 44.1 gewandelt ergibt:
Ich erspare mir hier eine analytische Bewertung mit einer einzigen Ausnahme: wenn jemand feststellt, dass ihm die Wiedergabe mit cPlay gefällt, so ist das für mich ok. Wenn jemand das aber mit Rechenalgorithmen und Bitgenauigkeit begründet, so liegt er schief.
Zusammenfassung:
Bei der digitalen Übertragung mit Abtastratenwandlern in der Signalkette ergeben sich im allgemeinen irgendwelche Resultate, auf die der geneigte Hörer selbst keinen Einfluss hat. Ausser, er findet das eine oder andere Resultat schlichtweg beim Hören besser. Was aber nicht bedeutet, dass er damit dann richtiger hört.
Nun ist das verwendete Testsignal ein extremes Signal, um eben die Fallstricke zu verdeutlichen. Gott sei Dank sind die realen Signale gutmütiger, aber trotzdem scheinen die kleinen Effekte sich dahingehend bemerkbar zu machen, als dass eben bei der einen oder anderen Wiedergabekette etwas zu bemängeln oder zu loben ist. Klar sollte sein, dass heutige Systeme noch weit weg von der perfekten und bitgenauen digitalen Übertragung sind. Die verwendeten Filter sind hierfür allemal zu kurz.
Ich wünsche Euch eine nette Diskussion
Grüsse, Uli
Hey Uli,
I´m delighted about your intrigue into this....
-ja, in Deutsch kann man ja nicht "intrigant" sagen, ohne einen negativen Beigeschmack zu provozieren.
Ich jedoch verspüre eine gesunde Neugierde bei dir in Sachen Upsampling und sinc-Filter.
-eigentlich geht´s hier ja um Schnittstellen, aber ich bin voll dahinter dass man diese schwierige Schnittstellen-Problematik nicht ganz ohne Upsampling auseinanderhalten kann.
Ein 96/192 kHz Signal überträgt in Praxis grundsätzlich weniger Jitter als ein (originales) 44.1 kHz Signal .
-populär kann man sagen, dass die kürzeren Samples, und eingehend die schnelleren Dispatches im System, für strafferen Ablauf der Datenpakete sorgen. Mit weniger Jitter zur Folge.
-dies tut jedem D/A Wandler gut; speziell diejenigen die kein avanciertes & teueres Re-Clocking betreiben.
Was man von deinen grafischen Darstellungen halten soll sei dahingestellt, aber empirische Hör-Erfahrungen sprechen auch eine Sprache....
(eigentlich sollte ich nicht die Arbeitsweise von cPlay (SRC sinc-Filter) weiter ansprechen, aber ich muss doch einen gewissen Einspruch erheben. Der Secret Rabbit Code den du auf der Webseite von Eric di Lupo (Secret Rabbit Code) gefunden hast und in deine technischen Darstellungen einfließen lässt, ist zwar prinzipiell als Quelle offengelegt, aber entspricht nur Teilweise der Funktionsweise von cPlay.
Vorerst ist der sinc-SRC Code im cPlay´er integriert; -verhält sich dynamisch zum Ereignis der Daten und die Berechnungen davon werden fortlaufend im L3 Cache des Prozessors ausgeführt.
-und zwar "real-time" !
Dies kannst du nicht pauschal mit dem statischen Quellcode vergleichen.
Es ist auch ein ungemein großer Unterschied zu einem Plug-in Verfahren das z.B. SoX in Foobar verwendet. Vorerst weil das sinc-Filter in cPlay nicht nachher im DSP verarbeitet wird, aber direkt im Prozessor stattfindet. Daher auch die spezifische cPlay Version ob nun eine SSE2, SSE3 oder SSSE4 Prozessor das Upsampling ausführen soll.
.....cics (und andere ehrgeizige Audiophile) haben sich mit der Problematik fünf Jahre akribisch damit auseinandergesetzt. cPlay ist eben nicht eine 08/15 Software. Da ist schon ein gewisser Hirnschmalz eingeflossen.... just think about it twice).
Nun ja, ich bewundere deine mathematisch-technischen Einsichten und ich danke auch für so viele deiner wissenschaftlichen Korrekturen, aber wäre es nicht einmal Zeit zu hinterfragen, warum einige Prozeduren so viel überzeugender klingen ?
Upsampling ist eben nicht einfach die Taktrate zu erhöhen, und digitale Schnittstellen sind auch nicht nur den Zustand "Bit-Perfekt" zu garantieren.
Jitter - (sprich) "Zeit-Perfekt" ist das schwierige an der Sache. Da hat Upsampling ganz andere Vorzüge die man Offline nicht beweisen kann !
Gruß Leif
I´m delighted about your intrigue into this....
-ja, in Deutsch kann man ja nicht "intrigant" sagen, ohne einen negativen Beigeschmack zu provozieren.
Ich jedoch verspüre eine gesunde Neugierde bei dir in Sachen Upsampling und sinc-Filter.
-eigentlich geht´s hier ja um Schnittstellen, aber ich bin voll dahinter dass man diese schwierige Schnittstellen-Problematik nicht ganz ohne Upsampling auseinanderhalten kann.
Ein 96/192 kHz Signal überträgt in Praxis grundsätzlich weniger Jitter als ein (originales) 44.1 kHz Signal .
-populär kann man sagen, dass die kürzeren Samples, und eingehend die schnelleren Dispatches im System, für strafferen Ablauf der Datenpakete sorgen. Mit weniger Jitter zur Folge.
-dies tut jedem D/A Wandler gut; speziell diejenigen die kein avanciertes & teueres Re-Clocking betreiben.
Was man von deinen grafischen Darstellungen halten soll sei dahingestellt, aber empirische Hör-Erfahrungen sprechen auch eine Sprache....
(eigentlich sollte ich nicht die Arbeitsweise von cPlay (SRC sinc-Filter) weiter ansprechen, aber ich muss doch einen gewissen Einspruch erheben. Der Secret Rabbit Code den du auf der Webseite von Eric di Lupo (Secret Rabbit Code) gefunden hast und in deine technischen Darstellungen einfließen lässt, ist zwar prinzipiell als Quelle offengelegt, aber entspricht nur Teilweise der Funktionsweise von cPlay.
Vorerst ist der sinc-SRC Code im cPlay´er integriert; -verhält sich dynamisch zum Ereignis der Daten und die Berechnungen davon werden fortlaufend im L3 Cache des Prozessors ausgeführt.
-und zwar "real-time" !
Dies kannst du nicht pauschal mit dem statischen Quellcode vergleichen.
Es ist auch ein ungemein großer Unterschied zu einem Plug-in Verfahren das z.B. SoX in Foobar verwendet. Vorerst weil das sinc-Filter in cPlay nicht nachher im DSP verarbeitet wird, aber direkt im Prozessor stattfindet. Daher auch die spezifische cPlay Version ob nun eine SSE2, SSE3 oder SSSE4 Prozessor das Upsampling ausführen soll.
.....cics (und andere ehrgeizige Audiophile) haben sich mit der Problematik fünf Jahre akribisch damit auseinandergesetzt. cPlay ist eben nicht eine 08/15 Software. Da ist schon ein gewisser Hirnschmalz eingeflossen.... just think about it twice).
Nun ja, ich bewundere deine mathematisch-technischen Einsichten und ich danke auch für so viele deiner wissenschaftlichen Korrekturen, aber wäre es nicht einmal Zeit zu hinterfragen, warum einige Prozeduren so viel überzeugender klingen ?
Upsampling ist eben nicht einfach die Taktrate zu erhöhen, und digitale Schnittstellen sind auch nicht nur den Zustand "Bit-Perfekt" zu garantieren.
Jitter - (sprich) "Zeit-Perfekt" ist das schwierige an der Sache. Da hat Upsampling ganz andere Vorzüge die man Offline nicht beweisen kann !
Gruß Leif
-
vincent kars
- Aktiver Hörer
- Beiträge: 154
- Registriert: 15.03.2011, 16:50
- Kontaktdaten:
