Hallo Uli,
uli.brueggemann hat geschrieben:Nun erklär mir mal einer sachlich, was nun dann die Klangänderungen bewirkt.
ich glaube, dass es in letztendlicher Klarheit niemand vermag. Auch die Entwickler von JPlay haben einen Erklärungsansastz, der in manchen Aspekten oberflächlich bleibt; so liest man in deren Forum auch immer wieder auf Fragen zu bestimmten Sachverhalten solche Sätze wie: "Warum das so ist, wissen wir auch nicht, wir stellen nur fest, dass es so ist. Und wir würden uns freuen, wenn jemand eine schlüssige Erklärung dazu findet."
Die klanglich qualitativen Unterschiede begründen sich m.E. nicht in tonalen Unlinearitäten. Du erinnerst Dich vielleicht an unseren kurzen Mail-Kontakt in Bezug auf Messungen unterschiedlicher Player-Software vor ein paar Monaten. Es ging aus wie das Hornberger Schießen: im hörrelevanten Bereich keine messbaren Unterschiede im FG und im Klirr feststellbar. Den klanglichen Unterschied führe ich daher auf Jitter zurück, zumal es sich in Klang-Kategorien zeigt, die für Jitter-Phänomene typisch sind.
In Bezug auf die damit zusammenhängenden klanglichen Unterschiede der Player-Software scheint offensichtlich zu sein, dass hier noch Faktoren hineinspielen, die nicht hinreichend in der Tiefe begründbar sind. Klar sind lediglich bestimmte phänomenologische Zusammenhänge: Eine Steigerung der Klangqualität kann erreicht werden z.B. durch das Abschalten von Diensten, das Abspielen von Musikfiles aus reserviertem RAM (mit möglichst hoher Taktrate), das Einbinden des Renderers als Windows-Dienst mit hoher CPU-Priorität, Kernel-Streaming statt WASAPI (und bei JPlay auch statt Asio), und so weiter.
Aber warum da so ist, kann niemand in der Tiefe zweifelsfrei begründen. Zwar gibt es Erklärungsmodelle - einige, die mich überzeugt haben, hatte ich hier ja schon ausgebreitet (und werde noch ein weiteres weiter unten ausbreiten) - aber die Tatsache, dass sie aus technischer Sicht ebenso gut auch als Nonsens angezweifelt werden könnten oder mit anderen Erklärungsansätzen widerlegt werden können, zeigt, wie dünn das Eis ist.
Mir persönlich hat vor allem ein Ansatz sehr viel Orientierung gebracht, und er hat mir dabei geholfen, mein Audio-PC-Setup klanglich effizient zu optimieren: nämlich die Unterscheidung verschiedener Jitter-Kategorien (und damit vielleicht auch zusammenhängend Jitter-Spektren) und ihren klanglichen Auswirkungen. Das möchte ich hier ein wenig ausführen, auch auf die Gefahr hin, von technisch versierteren Mitgliedern Kopfschütteln zu ernten:
Man müsste ja davon ausgehen, dass eine asynchrone USB-Anbindung (Hiface) plus ein zusätzlich nachgeschaltetes Reclocking (Big Ben) den im PC entstandenen Jitter bei der anschließenden D/A-Wandlung so weit reduziert, dass alles, was davor im PC bei der Aufbereitung des Audio-Signals passiert, klanglich keine Rolle mehr spielen dürfte. Damit müsste auch klar sein, dass es keine hörbaren qualitativen Unterschiede zwischen diversen Software-Playern gibt / geben dürfte.
Was nun aber, wenn entgegen dieser Theorie, weiterhin klanglich hörbare Unterschiede zwischen Software-Playern auftauchen - zwar durch den Big Ben auf einem insgesamt klanglich höheren Niveau, aber in ihrem
relativen Unterschied zueinander fast genauso ausgeprägt vorhanden, wie ohne Big Ben?
Dann liegt für mich die Vermutung nahe, dass es sich hier um eine andere Quelle/Kategorie von Jitter handelt, die durch die Takt-Rekonstruktion des Big Ben nahezu unbeeinflusst bleibt.
Und diese andere Quelle/Kategorie von Jitter lässt sich offenbar durch keine Maßnahme beseitigen, die erst
nach der Aufbereitung des Audiosignals (also ab USB-/SPDIF-Ausgangsbuchse) stattfindet: nicht durch asynchrone Anbindung des PC, nicht durch Reclocking, nicht durch optimierte Stromversorgung von Hiface, Big Ben und nachgeschalteten DAC.
Diese Quelle lässt sich offenbar nur beseitigen durch Maßnahmen, die
direkt während der Erzeugung des Audio-Signals passieren, also innerhalb des Zusammenspiels von Betriebssystem, Player-Software und Audio-Schnittstelle. Dieses Zusammenspiel zu optimieren, ist Gegenstand der Bemühungen von den Entwicklern von JPlay oder auch cMP². Diese Optimierungen sind (klanglich hörbar) offenbar so essentiell wie das, was dem Audiosignal nach Verlassen des Computers bei der D/A-Wandlung widerfährt.
Wie gesagt: ich weiß nicht, inwieweit dies wissenschaftlich fundiert belegbar ist, sondern ich nehme es als ein für mich hilfreiches Erklärungsmodell, mit dem ich bei der klanglichen Optimierung meines Audio-PC-Setups sehr weit gekommen bin (siehe Streamer-Test).
Mit diesem Erklärungsmodell wäre möglicherweise auch der Unterschied im klanglichen Abschneiden von La Rosita Beta Connect und dem Linn Akurat DS/1 begründbarer (ohne Anspruch, dass es die letztliche Begründung ist). Demnach spielen auch im Streamer diese beiden Komponenten eine klangentscheidende Rolle: Die Aufbereitung (Rendering) des Audiosignals und die Wandlung des Audiosignals (die dritte Komponente, analoge Ausgangsstufe, hier außen vorgelassen, da es um Betrachtungen zum Jitter geht).
Mit der Optimierung der zweiten Komponente, nämlich D/A Wandlung (sowie der nachfolgenden dritten Komponente = Ausgangsstufe) hatte sich Gert sehr intensiv befasst und dabei optimiert, was zu optimieren geht. Was passiert aber davor, nämlich in der ersten Komponente: beim Auslesen der Daten von der Festplatte, bei der Übersetzung in einen Audiostream etc.? Könnte es sein, dass hier weitere Faktoren weit vor dem eigentlichen Wandlungsprozess qualitativ klanglich entscheidend sind, die der Beta Connect qualitativ besser als die Leute von Linn umgesetzt hat?
Soweit meine Hypothesen.
Grüße
Fujak