Nubert Lautsprecher, HiFi- und Surround-Elektronik

Wete hat geschrieben: ↑Sa 18. Feb 2023, 13:36 Bei paketvermittelter Übertragung gibt es keine Qudlitätsunterschiede. Denn hier gibt es Fehlerkorrektur.
...

Du widersprichst deiner Aussage von deinem letzen Beitrag.
Zuerst führst Du die nicht vorhandene Fehlerkorrektur als Begründung dafür an, dass es auf digitaler Ebene keine Unterschiede geben kann, um anschließend aber zu behaupten, dass es doch eine Fehlerkorrektur gibt.

Richtig ist aber, dass SPDIF überträgt nur in eine Richtung überträgt und es daher ganz sicher keine Fehlerkorrektur geben kann.


Gruss Rank

S/PDIF hat keine Fehlerkorrektur
IP-Pakete übers Internet streamen hat eine Fehlerkorrektur. Bzw. sogar mehrere.

silver-classic hat geschrieben:
Oder sind diese auf dem digitalen Übertragungsweg entstandenen Verfärbungen/klangliche Unterschiede in Wirklichkeit so gering, dass wir sie gar nicht wahrnehmen können. D. h. unser Hörapparat, der ja auch nicht perfekt und bei jedem sicherlich etwas anders ist, ist einfach zu grob/ungenau um diese Unterschiede zu detektieren?

Einfache Antwort:

Ja. Genau wie bei Videostream. Entweder die Fehler werden durch Vorwärtsfehlerkorrektur unbemerkbar ausgeglichen, oder aber der Fehler ist sooo groß, dass selbst ein Blinder ihn bemerkt. Dazu braucht man dann keine Spezialgeschulten Augen, die Klötze sind unübersehbar.

Aber was anderes: Jeder, der bis 3 zählen kann und 3 Zeilen dieser Website aus den USA genossen hat, merkt instinktiv sofort, daß da etwas faul ist.
Der Autor der dortigen Verrisse zeigt eindeutig narzistische Züge. Er ist jemand, der sich zeitlebens nicht genügend geschätzt fühlte, und nach Jahrzehnten des Leidens nutzt er nun seine Kenntnisse, um Kübel voller Häme auszugiessen über denen, die ihn geringschätzen, da es bald vorbei sein wird.
Insofern: Mach es wie alle hier, schenke dem alten weißen Mann DIE Beachtung, die er verdient...

gruss gangster

anphex hat geschrieben: Was der DAC/ADC-Chip dann damit anstellt, ist eine ganz andere Geschichte und hier sind wir eben auch wieder teilweise in der analogen Domäne.

Voooorsicht :

Was der Chip himself anstellt ?

Was die Beschaltung! desselben macht, könnte, entsprechende Inkompetenz vorausgesetzt, Folgen haben.

Der Chip selber hat unmöglich einen Eigenklang. Auch wenn das ein Einzelfall stringent erzählt.

Ausser man bewegt sich gedanklich NICHT im Jahr 2023 sondern irgendwo Mittelalter.

gruss gangster

gangster1234 hat geschrieben: ↑Sa 18. Feb 2023, 14:25

silver-classic hat geschrieben:
Oder sind diese auf dem digitalen Übertragungsweg entstandenen Verfärbungen/klangliche Unterschiede in Wirklichkeit so gering, dass wir sie gar nicht wahrnehmen können. D. h. unser Hörapparat, der ja auch nicht perfekt und bei jedem sicherlich etwas anders ist, ist einfach zu grob/ungenau um diese Unterschiede zu detektieren?

Einfache Antwort:

Ja. Genau wie bei Videostream. Entweder die Fehler werden durch Vorwärtsfehlerkorrektur unbemerkbar ausgeglichen, oder aber der Fehler ist sooo groß, dass selbst ein Blinder ihn bemerkt. Dazu braucht man dann keine Spezialgeschulten Augen, die Klötze sind unübersehbar.

Auf die S/PDIF- und HDMI-Übertragung trifft das zu. Aber der Fragende spricht ja von Streaming übers Internet und den Einfluss auf die dabei zum Einsatz kommenden Kabel oder gar - bei WLAN - die Luft. Und das ist natürlich alles nicht der Fall, denn hier greifen zahlreiche Fehlerkorrekturen. Sonst wären bei schlechten Telefonkabeln ja auch die Preise auf der Nubert-Seite gerundet, die Grafiken unscharf und ähnlicher Unfug.

Rank hat geschrieben: ↑Fr 17. Feb 2023, 09:06 Das liegt einfach daran, dass HDMI für die digitale Stereo-Übertragung kaum Vorteile bietet, sondern eher von Nachteil sein kann.

Hier findet sich ein sehr interessanter Artikel über dieses Thema:
https://www.audiosciencereview.com/foru ... rmance.56/

Warnung:
Dieser Artikel könnte das komplette bisherige "Weltbild" über digitales Audio etwas auf den Kopf stellen, denn wer hier aufmerksam genug liest, dem wird auch klar werden, warum ein digitales Audio-Signal nicht zwangsläufig völlig verlustfrei und absolut unverändert ankommt/interpretiert wird (man beachte z.B. auch die deformierte Kurve beim Schaubild "Clock with Jitter")
Der Artikel ist zwar schon etwas älter, aber am Sachverhalt ändert dies trotzdem nix.

Naja, das Thema ist ja bekannt und auch schon hier im Forum mehrfach angeschnitten: Es kommt darauf an, wie gut das PLL-Design des Empfängers ist. Der Audiotakt muss aus dem HDMI-Signal natürlich wiedergewonnen werden und was da die einschlägigen Chips leisten, ist bisweilen sehr bescheiden, das ist richtig. Die Chips geben z.T. S/PDIF direkt ab, oder bieten I2S an. Chips mit denen ich vor 10 Jahren Video gemacht habe liefern aber schon ein brauchbares S/PDIF Signal. Es kommt aber auch auf das Taktdesign an: Wenn du die mit den dedizierten 12MHz-Reftakt betreibst, braucht es eine interne Taktrekonstruktion fürs Audio. Nimmst du aber einen Audio-Takt von 12.288 sieht das besser aus. Der ADV7611 z.B. liefert einen sehr guten MCLK den man direkt als Takt für einen FPGA nutzen kann. Hernach ist aber eine saubere Filterung Pflicht, d.h. an den gewonnenen Takt kommt eine sehr träge tieffrequent regelnde PLL, die die Daten aus dem FPGA holt und den digitalen Ausgang bedient - respektive den Wandler ansteuert, wenn es analog raus geht. Soetwas kann man einfach und billig bauen oder eben auch in gut. Ich kann mit meinem Signalsynthesizer gezielt jitternde und defektiöse Takte generieren und checken, was ein Chip daraus macht.
http://www.96khz.org/htm/signalanalyser.htm

Damit kann man testen ab wann eine PLL ausfällt und wie sehr sie im Normalbetrieb filtert. Mein $35 HDMI-Audio-Extractor aus dem Lande des Lächelns liefert denn auch ziemliches Gezitter, was aber sowohl von meinem Digitalpult, meinen RME-Interfaces als auch von meiner Pyra sehr tolerant gehandhabt und glattgemacht wird.

Signalrekonstruktion auf S/PDIF-Ebene ist dabei technisch anspruchsvoller, als bei einem sychronen Signal bei HDMI, da die Bandbreite beim S/PDIF maximal im Bereich 25Mbps (384kHz) liegt und wegen 1b2b-Codierung eben genau einen Takt auf 12,288MHz liefert, während das Videosignal bei HDMI2.0 (1080p) 1.5Gbps hat und wegen 8b10b sozusagen mit 300MHz Taktflanken liefert, auf die man synchronisieren kann. Zudem nutzt HDMI mit TMDS einen störsichereren Signalstandard und ist auch von der SPEC enger toleriert.

HDMI hat definitiv das Potenzial, Daten jitterfrei zu transportieren. Das Signal selbst muss ja bereits auf einen viel geringeren Jitter rekonstruiert werden, damit man überhaupt ein stabiles Bild bekommt.

Wete hat geschrieben: ↑Sa 18. Feb 2023, 14:03 S/PDIF hat keine Fehlerkorrektur
IP-Pakete übers Internet streamen hat eine Fehlerkorrektur. Bzw. sogar mehrere.

Mal kurz hierzu:

S/PDIF hat in der Tat keine Fehlerkorrektur im Protokoll. Aber: Man kann in den user-Daten einen FEC, CRC übertragen, was manche Hersteller auch nutzen, um zwischen ihren Geräten firmenspezifische Daten auszutauschen. In der Regel geht man aber von einem kontinuierlichen Stream aus. S/PDIF ist aus Datensicht ja lückenlos. Was aber praktisch jeder drin hat, ist eine Signalrekonstruktion, die es erlaubt, defekte Daten über ein kurze Zeitspanne zu interpolieren und somit defektiöse Daten zu interpolieren. Das ist streng genommen aber keine Fehlerkorrektur im eigentlichen Sinne.

Die ist aber auch in vielen Streaming-Geräten verbaut und zwar genau deshalb, um etwaige Lücken zu überbrücken, wo Daten wirklich weg sind. Dass man beim Streaming also scheinbar perfektes Audio zu hören glaubt, bedeutet nicht, dass man auch alle Daten bekommen hat - trotz einer Redunanz in den Protokollen. Wenn man es mit einer mehrkanaligen FFT baut, lassen sich Datenlücken bis in den Milisekundenbereich rekonstruieren, ohne dass es der Nutzer merkt, wenn er nicht ein Original parallel hört. Voraussetzung: Es ist genug Material im Puffer, was aber in der Regel der Fall ist. Um z.B. eine Basswelle zu rekonstruieren, sind 3-4 Wellen völlig ausreichend.

Worum man sich aber mehr Sorgen machen sollte, ist in der Tat die Qualität des Abspielers: Wenn das über den PC-Zuspieler läuft, dann ist der quasi Master und fordert die Pakete an, spielt sie mit seinem Takt ab und der ist mitunter ein recht bescheidener. Da hängt der Jitter voll drin. Inklusive falsch taktender PLL, die auf 48,040 Hz abspielt, statt auf 48,000.

Interesant sind in dem Zusammenhand live-Streaming-Dienste, wenn z.B. ein Konzert übertragen wird. Dann fordert ja nicht jeder Client "seine" IP Pakete, wie er sie braucht und legt sie passend auf Halde (wobei nur Lücken entstehen, wenn mal der Puffer unterläuft), sondern die Zentrale sendet die Daten raus. Da diese einen eigenen Takt hat, muss sich der Abspieler ja darauf synchronisieren, oder er tutet mit seinem Takt und benutzt einen fetten Puffer, der die auftretenden Zeitdifferenzen zu Beginn der Übertragung schon mit einkalkuliert.

Weis jemand, wie das konkret gemacht wird?

Wenn man von einem Abspielfehler von nur einem Promille ausgeht, dann ist ein 1h-Konzert 3s länger oder kürzer. Das müsste dann vorgepuffert sein.

engineer hat geschrieben: ↑Di 21. Feb 2023, 00:03 Interesant sind in dem Zusammenhand live-Streaming-Dienste, wenn z.B. ein Konzert übertragen wird. Dann fordert ja nicht jeder Client "seine" IP Pakete, wie er sie braucht und legt sie passend auf Halde (wobei nur Lücken entstehen, wenn mal der Puffer unterläuft), sondern die Zentrale sendet die Daten raus. Da diese einen eigenen Takt hat, muss sich der Abspieler ja darauf synchronisieren, oder er tutet mit seinem Takt und benutzt einen fetten Puffer, der die auftretenden Zeitdifferenzen zu Beginn der Übertragung schon mit einkalkuliert.

Weis jemand, wie das konkret gemacht wird?

Wenn man von einem Abspielfehler von nur einem Promille ausgeht, dann ist ein 1h-Konzert 3s länger oder kürzer. Das müsste dann vorgepuffert sein.

Da sich Multicast - leider - nicht durchsetzt, bekommt sehr wohl jede IP ihre Datenpakete. Der von Dir so gerne aufgeführte "Takt" hat da aber doch überhaupt keine Bewandtnis, der ist nur bei durchgehenden Datenströmen von Belang, nicht aber bei Paketen. Zumal beim Streaming kein Bitstream-Signal wie PCM zum Einsatz kommt sondern ein über größere Abschnitte datenreduziertes, da ist also nichts mehr in irgendeinerweise synchron. Da wird sehr viel vorgeladen und gepuffert.

Edit: Nochmal zur Verdeutlichung: Eine PCM- oder MP3-Datei von Festplatte kannst Du ja auch abspielen, obwohl die Festplatte keinen Takt liefert. Nichts anderes ist "Streaming", nur dass die Datei dabei eben sehr langsam gelesen wird. Niemals jedoch ohne ausreichend großem Puffer. Wenn der leer läuft, kommt's zu Aussetzern, aber sicher nicht zu klanglichen Veränderungen (wie interpolierten Basswellen und was Du weiter oben beschreibst).

Anders bei nicht-IP-basiertem digitalem Streaming wie DVB, DAB usw! Aber auch hier hat der "Takt" nach meinem Verständnis keine Bewandtnis, weil immer soviel gepuffert wird/werden muss, dass das abspielende Gerät seinen Takt (beim Videostreaming auch die Bildwiederholrate) selbst generieren kann.

Ich sehe auch keinerlei Problem darin, einen Takt exakt zu generieren. Warum sollte ein Rechner mit 48040 statt 48000 laufen? Wie sollte der gleiche Rechner dann eine Bildwiederholrate von 23,97 fps von 24 unterscheiden können? Und das klappt ja auch!

Takt und Jitter sind in meinen Augen Schlangenölwörter, die man immer ziehen kann, wenn man ein Problem zu erklären versucht, weil dann jeder wissend nickt und "ououou" sagt. Dabei haben sie bei nicht-synchronen Verbindungen meines Wissens keinerlei Bewandtnis. Aber um zum Thema das Threads zurückzukommen: Bei PCM via S/PDIF natürlich schon, weshalb sich der Empfänger da meines Wissens einfach auf die Quelle aufsynchronisiert. Der Takt wird ja frei Haus mitgeliefert.

Jitter wird immer erwähnt, wenn man Ereignisse aus der analogen Welt glaubt MEHR als 1:1 in die digitale übernehmen zu können.
Natürlich totaler Humbug.

Fehlerkorrektur wird von den Autoren stringent ignoriert.

gruss gangster

Wete hat geschrieben: ↑Di 21. Feb 2023, 07:36 Der von Dir so gerne aufgeführte "Takt" hat da aber doch überhaupt keine Bewandtnis, der ist nur bei durchgehenden Datenströmen von Belang, nicht aber bei Paketen.

Das ist ja der Punkt. Der Takt muss im Zielsystem erzeugt werden und in irgendeiner Weise auf das Sendeformat abgestimmt werden, sonst laufen sie auseinander. Beim Video ist das kein Problem, weil man empfängerseitig einfach ein paar ns der Videotaktes in der blank Phase anhängt. Damit ist das Bild in kleinen Häppchen synchronisierbar, weil es eh nur 16ms Auflösung hat. Gerne wird auch mal ein ganzer frame wiederholt. Beim Audio mit wenigstens 48kHz und einem DSP-System der nur auf vlt S/PDIF Takt, also Faktor 64 auflöst, geht das nicht mehr ohne Artefakte und mit Sampleauflösung schon mal gar nicht.

Am Ende ist es der PC, der den Takt macht und der kann beliebig schlecht und störanfällig sein.