auch ich bin wie Horst nicht sicher, ob das egal ist. Welches Output-Device ist denn angegeben in der obersten Zeile der Settings-GUI?
Grüße
Fujak
wie bereits gesagt ASIO > und laut Josef von JPLAY und dem pop up window bei den JPLAY settings sollte ja bei ASIO keinerlei Einfluss der oben genannten settings möglich sein. Ob das stimmt kann ich nicht sagen.
Auf jeden Fall weiss ich, dass die JPLAY Jungs eine simple sample rate Umschaltung in Vernindung mit einer RME FF400 nicht schaffen (JRiver MC schafft dies problemlos).
besten Dank für Deinen Höreindruck. Du bist ja sehr systematisch vorgegangen in Bezug auf den Hörtest - auch in den möglichen Ursachen für das Ergebnis.
Zu Punkt 1, 2 und 4 Deiner möglichen Ursachen: Du hast ja Dein System in Deinem Vorstellungsthread vorgestellt. Deine Lautsprecher sind aus meiner Sicht über jeden Zweifel erhaben, dass sie Klangunterschiede nicht darstellen könnten. Du betreibst Acourate, sodass in Bezug auf FG und Phase Präzision vorhanden ist.
Das einzige, was mir an Deiner Konfiguration nicht klar ist, ist der AVR (Modell?) sowie - noch wichtiger - der Bereich der D/A-Wandlung. Einen DAC habe ich in Deinem Setup nicht finden können. Oder setzt Du dies mit der M-Audio-Karte um? Das würde in dem Falle zwar aus meiner Sicht einen klanglichen Flaschenhals darstellen, aber ob dies das dazu führt, die Unterschiede zwischen den Softwareplayern nicht detektieren zu können, vermag ich nicht zu beurteilen. Meine Erfahrung ist jedoch, dass je hochwertiger die D/A-Wandlung läuft, desto leichter sind Unterschiede zu hören.
Zu Punkt 3: Zur Konfiguration von JRiver kann ich mangels Erfahrung mit diesem Player nichts sagen, aber ich denke, wenn von unseren JRiver-Nutzern hier kein Einwand in Bezug auf die Konfiguration kommt, dürfte Dein Test schon schlüssig sein.
Insofern bleibt für mich der Hintergrund des Ergebnisses unklar. Aber: wie Du schon selber schreibst, ist das ja kein Beinbruch, wenn Du mit JRiver ohnehin vollauf zufrieden bist.
Zu Deiner Frage der drei Engines bei JPlay: Jeder der drei Engines arbeitet bitgenau. Sie unterscheiden sich lediglich darin, wie das Musiksignal im PC intern aufbereitet wird. Insbesondere das Zusammenspiel zwischen Arbeitsspeicher und CPU unterscheidet sich ziemlich. Das hat Auswirkungen auf den Klang. Die simpelste Variante (Engine River) klingt wärmer aber auch ein wenig (!) unsauberer mit etwas (!) weniger Räumlichkeit als das aufwändigere Verfahren (Beach Engine), welches mehr Räumlichkeit ins Geschehen bringt aber auch ein wenig heller in der Tonalität ist. Die Xtream-Engine verwendet das komplexeste Verfahren in der Speicherzuteilung (was bei vielen Setups auch am meisten Problem bringt, wenn die Hardware nicht 100% leistungsfähig und exakt konfiguriert ist), was sich m.E. auch in der besten Detailauflösung und Abbildung äußert, allerdings in manchen Wiedergabeketten auch mit einer gewissen analytischen Schärfe verbunden ist (was oft mit dem nachfolgenden Wandler in Verbindung steht).
Weshalb eine unterschiedliche Aufbereitung zu klanglichen Unterschieden führt, ist aus meiner Sicht ebenso wenig schlüssig geklärt, wie die Frage, welche der drei Klang-Charakteristiken nun die "richtigste Wiedergabe" darstellt. Indofern finde ich es begrüßenswert, wenn die Entwickler die Wahl dem User freistellen. Ich selber bevorzuge übrigens Beach oder Xtream - das wechselt im Moment ein wenig, weil die Unterschiede in den RC-Versionen von Update zu Update wechseln können.
danke für die sehr ausführlich Antwort! Ja, ein paar offene Rätsel wirft das Ergebnis bei mir auch auf.
Noch mal zu meiner Kette, wo du möglicherweise noch Ursachen vermutest. In meinem Vorstellungsthread sind die ersten 2/3 Text Historie. Im letzten 1/3 ist mein aktuelles Setup in Auflistungsform dargestellt. AVR + M-Audio Soundkarte sind längst Geschichte. Die Kette ist denkbar einfach und schlank.
Soundkarte und DAC RME Fireface UC
Wandlung: da bis zum Ausgang voll digital, findet nur am Ausgang 1x eine DA Wandlung statt
Endstufe Rotel RB -1552
Lautsprecher Audio Physic Tempo 25
Die drei Engines bleiben für mich weiterhin ein Rätsel. Welche Faktoren außer Bitgenauigkeit, Amplitude/Pegel und Zeitrichtigkeit (hier duch den Einsatz von JPlay zur Jitterreduzierung) verändern denn den Klang am Ende der Kette? Eine Dimension muss doch da noch fehlen? So viele "Geheimnisse" in der digitalen Signalverarbeitung dürfte es meiner Meinung nach eigentlich nicht mehr geben.
Mein Englisch ist nicht so toll, evtl. frag ich Marcin und Josef trotzdem mal...
Bezüglich der klanglichen Relationen zwischen JRiver und JPlay hier noch eine weitere Variante:
JRiver MC18 hört sich in meinem System recht gut und musikalisch an, schaltet man JPlay dazu, gewinnt der Klang aber noch deutlich an Qualität. Ähnliches bewirkt das Zuschalten von JPlay zu Allerweltsquellen wie Spotify: Die ansonsten wenig genussvolle Spotify-Wiedergabe wird dadurch wesentlich durchhörbarer, rhythmischer und räumlicher. Einfach als rein subjektive Anmerkung ohne Anspruch auf Allgemeingültigkeit zu sehen ...
nightingale hat geschrieben:Ich verwende, wie ihr ja wisst, eine RME FF400. Ich habe nun versucht Dateien mit unterschiedlicher sample rate mit JPLAYmini abzu spielen. Die automatische sample rate Umschaltung funktioniert nur leider nicht mit JPLAY. Ich bin auch schon in regem Kontakt mit den JPLAY und den RME Mannen um eine Lösung zu finden. Kann das bitte jemand der ebenfalls eine RME verwendet (muss ja nicht die FF400 sein) ebenfalls ausprobieren
BUMP - hat keiner diese Probleme? JPLAY schiebts auf RME und RME schiebts auf JPLAY
ich habe auch JPlay (Test-Vers), Foobar und AcourateConvolver mit der FF400.
FF400 unterstützt automatische Abtastraten-Umschaltung nur zwischen folgenden Gruppen: 44/48, oder 88/96, oder 176/192. Automatisches Umschalten von 44 auf 88 geht z.B. nicht. Zusätzlich wird die Anzahl der ADAT-Kanäle bei unterschiedlichen Abtastraten geändert.
das stimmt nicht ganz. Das Problem tritt nur bei hinter dem Player eingeschliffenen Komponenten/Software auf. Verwende ausschließlich jRiver und und das FF schaltet on-demand auf jedes anders Quellmaterial um. Das soll nicht heißen, dass die Komponente/Software schuld ist. Ich weiß aber auch nicht, ob andere Karten das besser können...
modmix hat geschrieben:Bleibt natürlich die Frage, wieso dieser Umstand Einfluß auf den Klang hinter USB/HiFace/SPDIF/DEQX... haben kann. Na klar, Windows ist kein Realtime Betriebssystem, es gibt also Verzögerungen in der Abarbeitung - wieso werden diese Verzögerungen nicht durch die Puffer ausgebügelt, die es auf dem Weg von der Platte / aus dem RAM zum DAC gibt?
Da wie du richtig beschreibst Win kein realtime OS ist (es kann kein wirkliches realtime geben, man kann sich ja nur annähern kann) und daher wird dem Netzwerk task eben CPU Zeit zugeordnet. Damit werden die Signalbearbeitung und Ausgabe tasks kurz gestoppt. Damit kann es IMHO zu einer Klangbeeinflussung kommen. Je optimaler eine PC Hardware, OS und SW aufgesetzt ist, umso weniger Einfluss wird der NW tasks auf den Klang haben. Ich denke, dass die packet size keinem A/B Blindtest standhält.
Nach meiner Beobachtung im Ressourcemonitor reicht es, die Wiedergabe im Foobar zu stoppen und neu zu starten - die genutzte Netzbandbreite ändert sich dann.
Ob das auch für Änderungen im jplay.setting gibt, weiß ich nicht.
Prio 1 liegt beim klanglichen Ergebnis und zum Glück ändert man an den jplay.setting nur selten was. Aber wenn die V5 RCs dann mal abgeschlossen sind, haben die beiden hoffentlich etwas mehr Zeit, um sich auch um Bedienung und Doku zu kümmern.
Ich denke, dass die packet size keinem A/B Blindtest standhält.
Der Unterschied zwischen 0 und 2 fällt bei mir klanglich geringer aus als der Unterschied zwischen zwei 'Engines', ist aber durchaus ein schöne Feintuningmöglichkeit.
modmix hat geschrieben:mit PS=0 machte sich jede andere Aktivität, die ich dem WinDOS noch nicht abgewöhnen konnte, als kleine Aussetzer bemerkbar
Mit PS=4 treten Aussetzer kaum auf und es kling hervorragend - ob ich wirklich einen schnelleren Rechner brauche ?...
das ist bei mir auch so. Ich kann mir ehrlich auch nicht vorstellen, dass wenn man das System brutal, koste was es, was es wolle, so limitiert. jPlay ist nicht das Betriebsystem .
Wenn die kleinste Aktivität schon Knistern hervorruft, möchte ich nicht wissen, was sich zwar nicht durch klar herrauszuhörendes Kistern, dafür aber wieder durch Jitter bemerkbar macht. Das Betriebsystem ist der Container der Software und sendet sich sich selbst innerhalb sehr kurzer Zeit hunderte von Nachrichten die es benötigt, um sich selbst stabil zu halten und vor allem auch dazu, damit Software ungestört und fehlerfrei funktioniert. Hier wird das System instabil und das kann sich für mein Verständnis nicht klangfördernd auswirken.
ich habe keinerlei Aussetzer bei PS=0 - weder im Single-PC-Modus noch im Dual-PC-Modus (Xtream); ich vermute, dass Aussetzer weniger mit dem Abspecken des OS zu tun haben, als vielmehr mit der Leistungsfähigeit des PC (CPU insbesondere aber möglicherweise noch andere Komponenten).
auch nicht, wenn du auf den Singleplay PC z.B. ein Fenster etwas unkontollierter hin und her schiebst? Wenn auf dem System absolut nichts passiert, außer Wiedergabe, ist ja nichts zu vernehmen.
und zum Glück ändert man an den jplay.setting nur selten was. Aber wenn die V5 RCs dann mal abgeschlossen sind, haben die beiden hoffentlich etwas mehr Zeit, um sich auch um Bedienung und Doku zu kümmern. 
