Bit-identische Musik-Dateien auf derselben Festplatte

frankl
Aktiver Hörer
Beiträge: 489
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

nihil.sine.causa hat geschrieben: Danke erst einmal für die Erläuterung. Damit ist sichergestellt, dass Du wirklich bit-identische Kopien vergleichst. Nennen wir sie A und B. Und ich gehe jetzt einmal methodisch davon aus, dass sich A und B innerhalb Deines Setups unterschiedlich anhören, so wie Du es beschrieben hast.

Hier schließt sich für mich die nächste grundlegende Frage an: Worin unterscheiden sich A und B? Liegen sie z.B. auf unterschiedlichen, mehr oder weniger fragmentierten Bereichen Deine Festplatte? Die Unterschiede könnten auch in der Art des Zugriffs liegen, obwohl Du das durch dein Setup vermutlich weitestgehend ausgeschlossen hast.
Hallo Harald,

die beiden Dateien werden natürlich auf exakt die gleiche Weise abgespielt. Die Fragen nach dem Bereich der Festplatte, der die Daten enthält und nach der Fragmentierung habe ich wohl schon in anderen ähnlichen Threads gesehen. Ich halte aber beides nicht für Klang beeinflussend. Die benutzte Festplatte hat viel freien Platz und es werden selten Daten davon gelöscht. Da kann man wohl davon ausgehen, dass die Dateien, die ich wie oben beschrieben erzeugt habe, hintereinander stehen. Der Unterschied in der Klangcharakteristik zwischen erster und "verbesserter" Datei ist bei den verschieden Stücken ähnlich (wie immer schwer zu beschreiben: die "verbesserte" Version klingt etwas voller oder runder). Wenn der Unterschied durch den Bereich der Festplatte zustande käme, müsste ja eher zufällig die eine oder die andere Version besser klingen. Und Fragmentierung liegt auf einer Platte, die meist nur neu beschrieben und auf der selten Dateien gelöscht werden, kaum vor. Und selbst wenn eine Datei fragmentiert ist, so heißt das nur, dass sie nicht in einem kontinuierlichen Adressbereich auf der Platte liegt, sondern ab und zu in einen anderen Adressbereich zum Weiterlesen gesprungen werden muss. Das passiert aber höchstens ganz wenige Male (alle paar Minuten, oder im Extremfall Sekunden, und hat sicher auf den laufenden Klangeindruck keinen Einfluss. (Häufiger, aber auch zu selten, um den laufenden Klangeindruck zu beeinflussen, kommen sicher Sprünge des Lesekopfes vor, weil gewisse fortlaufende Blöcke des Adressbereiches einer Festplatte unterschiedliche physikalische Blöcke ansprechen.)
nihil.sine.causa hat geschrieben: Es muss einen solchen "strukturellen" Unterschied zwischen A und B geben, denn Du kannst sie nach deinem Verfahren ja hinsichtlich ihrer Audio-Eigenschaften reproduzierbar auseinanderhalten, wenn ich Dich richtig verstanden habe.
Worin jetzt aber exakt der Unterschied der Dateien besteht, kann ich auch nicht sagen. Für Mutmaßungen verstehe ich zu wenig von den technischen Details, wie eine Festplatte funktioniert. Beim Schreiben und Lesen sind ja auch wieder Pufferspeicher und Bauteile auf dem Festplattencontroler im Spiel, das ist schon ziemlich kompliziert. Vereinfacht stelle ich mir das so vor, dass auf der Festplatte eher ein analoges Signal aufgezeichnet wird, das die zu schreibenden digitalen Daten enthält, als eine abstrakte Intepretation der digitalen Daten. Und dass beim Auslesen auch wieder ein analoges Signal erzeugt wird, dass zumindest irgendwie stark mit dem Eingangssignal korreliert (ähnlich wie bei einem Tonband oder Videoband, dass ein analoges Signal mit digitaler Interpretation aufzeichnet, wenn auch komplizierter). In meinem Beispiel sind beim Erzeugen der "verbesserten" Datei die Daten in sehr viel gleichmäßigeren Intervallen blockweise an die Festplatte geschickt worden, als bei der Ausgangsdatei. Dahinter stand die Idee, dass die Daten dann auch beim Auslesen in gleichmäßigeren Zeitabständen geliefert werden und dies am Ende beim Abspielen den Jitter verringert.

Beim Abspielen der Dateien werden bei mir übrigens unter anderem die Daten im RAM zwischengespeichert. Das zeigt, dass auch der Arbeitsspeicher eines Rechners nicht aus Speicherzellen besteht, die klar zwischen zwei Zuständen wechseln. Vielleicht lassen sich Daten im Arbeitsspeicher auch "verbessern"? Mal sehen, äh hören ...

Viele Grüße,
Frank
Bild
Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Hallo Frank
frankl hat geschrieben: ... Beim Abspielen der Dateien werden bei mir übrigens unter anderem die Daten im RAM zwischengespeichert. Das zeigt, dass auch der Arbeitsspeicher eines Rechners nicht aus Speicherzellen besteht, die klar zwischen zwei Zuständen wechseln. Vielleicht lassen sich Daten im Arbeitsspeicher auch "verbessern"? Mal sehen, äh hören ...
Deine Versuchsandordnung ist also in etwa

HD -> RAM -> DAC
oder
HD_Rechner_1 -> RAM_Rechner_1 -> Netz -> RAM_Rechner_2 -> DAC_Rechner_2.

Kommst Du mit einer SSD am Anfang der Kette zu denselben Resultaten?

Simon
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 4004
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo Stephan,

halten wir fest:

MQn gibt jeweils bitgenau aus, es kommt aber durch die unterschiedliche Verarbeitungsweise der Daten zu unterschiedlichem Klang.

Gruß

Bernd Peter
Bild
axxxxx

Timing und Flanken

Beitrag von axxxxx »

Hallo,

wenn ich mir die Bemühungen unter MQn, JPlay und dem Win Server Optimizer anschaue, dann geht es doch bei allen um die Reduzierung der Prozessorbelastung und den möglichst reibungslosen Datentransfer innerhalb des Sytemes hin zu den jeweiligen Interfaces.

Auch wenn es sich dabei ja eigentlich nur um den Transport und die Verarbeitung digitaler Informationen dreht, mithin eigentlich ja nur um die korrekte Wiedergabe von 0 und 1 in den Zwischenschritten und der am Ende Wandlung in unterschiedliche Protokolle (SPDIF/USB), so scheinen es doch analoge Vorgänge zu sein, die das Ergebnis bestimmen.

Ich denke, auch hier geht es wieder nur um das Timing und die Form des Signals, sprich die Flankensteilheit, was sich in mehr oder minder Jitter und einem unterschiedlichen Klang ausdrückt.

Gruß,
Kai
KSTR
inaktiv
Beiträge: 1221
Registriert: 08.05.2008, 11:51

Beitrag von KSTR »

Daihedz hat geschrieben:HD_Rechner_1 -> RAM_Rechner_1 -> Netz -> RAM_Rechner_2 -> DAC_Rechner_2
So war es beschrieben. Wäre Rechner_1 auch gleichzeitig der Wiedergebende, gibt es einen schwachen, aber prinzipiell vorhandenen Wirkmechanismus des "Lageklangs", nämlich des "durchdrückenden" Jitters (am DAC) aufgrund eines ja tatsächlich anderen Auslesevorgangs vom Medium, welcher also das Timing auf der Audio-Schnittstelle (welche?) und damit auch am DAC-Chip beeinflussen könnte, und nur da zählt es.

Jedoch, durch die weitere Indirektionsstufe Ethernet samt zugehöriger Treiber-Software/Firmware (die keinerlei echtzeitfähige Spezifikation hat), wird ein allfälliger Wirkmechanismus um weitere Größenordnungen geschwächt und ist (schon längst) so klein geworden dass er de facto nicht mehr vorhanden ist bzw schon längst in allem anderen Rauschen untergegangen ist. Und überhaupt, das Ockham'sche Rasiermesser ...

Ich streite das Hörerlebnis nicht ab (warum bzw. wie auch), würde aber annehmen, dass wohl dem Confirmation Bias unterlegen wurde und/oder keine ausreichende Stichprobengröße verwendet wurde, oder sonstige Verfahrenfehler unterlaufen sind so dass kein echter bzw. kein aussagekräftiger Test zustande kam.
Bild
Bernd Peter
Aktiver Hörer
Beiträge: 4004
Registriert: 04.05.2010, 19:37

Beitrag von Bernd Peter »

Hallo Kai,
aston456 hat geschrieben:ja nur um die korrekte Wiedergabe von 0 und 1
korrekt wird auch ausgegeben, wenn es schlecht klingt.
Reduzierung der Prozessorbelastung
na, der ist doch froh, wenn er zumindest leichtes Training machen darf.

Das angesprochene verbesserte Timing, das Beseitigen von parallelen Prozessen und der möglichst ungestörte Datenfluss und die Datenweitergabe, ist - wenn ich es richtig verstehe - bei HiFi-Audiowiedergabe im Focus der Entwickler.

Gruß

Bernd Peter
Bild
KSTR
inaktiv
Beiträge: 1221
Registriert: 08.05.2008, 11:51

Beitrag von KSTR »

frankl hat geschrieben:In meinem Beispiel sind beim Erzeugen der "verbesserten" Datei die Daten in sehr viel gleichmäßigeren Intervallen blockweise an die Festplatte geschickt worden, als bei der Ausgangsdatei. Dahinter stand die Idee, dass die Daten dann auch beim Auslesen in gleichmäßigeren Zeitabständen geliefert werden und dies am Ende beim Abspielen den Jitter verringert.
Gleichmäßige Intervalle beim Schreiben in den Schreib-Cache der FP sind eben wegen diesem irrelevant, die Platte entscheidet sowieso völlig autark wann (und auch wohin) sie physikalisch etwas schreibt. Beim Lesen entscheidet ebenfalls die Platte wann es die Daten ans BS schickt, nachdem diese eine Leseanforderung abgesetzt hat. Schnellstenfalls liegen schon Daten im Cache (der Platte), andernfalls muss gewartet werden bis a) die Lese-Köpfe positioniert sind und b) die Platte sich soweit weitergedreht hat, bis die Daten wieder unter den Köpfen vorbeiziehen. Das hätte man auch alles googeln können bevor man wilde Thesen aufstellt!
Bild
frankl
Aktiver Hörer
Beiträge: 489
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Daihedz hat geschrieben: Deine Versuchsandordnung ist also in etwa

HD -> RAM -> DAC
oder
HD_Rechner_1 -> RAM_Rechner_1 -> Netz -> RAM_Rechner_2 -> DAC_Rechner_2.
Hallo Simon,

die zweite Variante (hatte ich eingangs auch beschrieben). Die HD hängt über USB am Rechner_1 und der DAC am Rechner_2 ist ein USB-DAC. Zum Abspielen habe ich die beste mir bekannte Methode zum Abspielen vorgefalteter Musik benutzt (unter Benutzung meiner [url=http://frank_l.bitbucket.org/stereoutils/player.html]hier verfügbaren[/url] Programme).

Es wäre also ein gutes Ziel, die Abspielsoftware weiter zu verbessern, so dass die unterschiedlichen Dateien nicht mehr herausgehört werden können.
Daihedz hat geschrieben:Kommst Du mit einer SSD am Anfang der Kette zu denselben Resultaten?
Das würde mich auch sehr interessieren. Das ist ja eine ganz andere Speichertechnologie und die mechanischen und analogen Komponenten wie in einer Festplatte gibt es nicht. Andererseits durchlaufen auch beim Speichern auf der Festplatte und beim Abspielen in meinem Versuch die Daten diverse Flashspeicher als Puffer und den RAM in verschiedenen Rechnern. Trotzdem bleibt am Ende ein Unterschied hörbar. Es würde mich daher jetzt nicht zu sehr wundern, wenn man auch mit SSD unterschiedlich klingende, bit-identische Dateien realisieren könnte.

Leider habe ich keine SSD, um diesen Versuch zu machen (und habe in naher Zukunft auch nicht vor, eine zu kaufen, da die bezahlbaren >= 2TB SSDs noch nicht in Sicht sind).

Viele Grüße,
Frank

PS: Auf nicht unterschriebene Beiträge (die in diesem Forum nicht üblich sind) und pauschale "kann nicht sein"-Beiträge werde ich in diesem Thread nicht weiter eingehen. An konkreter und sachlicher Kritik am Versuchsaufbau bin ich natürlich interessiert.
never
Aktiver Hörer
Beiträge: 322
Registriert: 30.12.2012, 11:00

Beitrag von never »

Hallo zusammen,

dieser Thread regt natürlich nicht nur zum Diskutieren, sondern auch zum Ausprobieren an. Ohne nochmals auf alle Variablen eingehen zu wollen, die beim oder auch nach dem Rippen Einfluss auf die Wiedergabequalität digitaler Audiodateien haben können, möchte ich nur kurz auf eine weitere Überraschung hinweisen, die ich vorher noch nicht in dieser Form kennengelernt hatte.

Auf meinem ganz normalen PC (nicht ausdrücklich für JPLAY oder Audiowiedergabe optimiert) hatte ich vor einigen Monaten die konventionelle Festplatte durch eine SSD vom Typ Samsung 840 EVO 500GB ersetzt und darauf Windows 8.1 und alle meine Programme installiert. Der gesamte übrige Datenwust ist ausgelagert. Die Audiodateien sind auf einem QNAP-Server, aber auch auf einem aktuellen WD My Book, das per USB-Kabel an den PC angeschlossen ist.

Die Audiodateien, die auf dem WD My Book lagern, spiele ich meist mit JPLAYmini und JPLAY ab. Sie sind lossless FLAC, mit dBpoweramp gerippt. Angeregt durch diesen Thread hatte ich dann aber einige der Audiodateien vom WD My Book in einen neuen Ordner auf die Samsung SSD kopiert und diese dann mit JPLAYmini und JPLAY abgespielt. Natürlich unter Beibehaltung aller Einstellungen bei JPLAY. Das Ergebnis hat mich überrascht: Die auf die SSD kopierten Dateien bieten eine in jeder Hinsicht bessere Wiedergabequalität, wenn ich sie für die Wiedergabe über JPLAY und JPLAYmini nutze: Stimmliche Nuancen, Konturiertheit bei Melodie und Rhythmus, Detailfülle, Verhalten im Bass etc. sind klar und eindeutig besser.

In verschiedenen Threads dieses Forums ist schon über unterschiedliche Hörergebnisse beim Rippen oder bei der Verwendung unterschiedlicher Speichermedien berichtet und diskutiert worden. Die für mich zweifelsfrei überlegene Wiedergabequalität „derselben“ Audiodatei als Kopie von einer SSD gegenüber dem „Original“ auf konventioneller Festplatte kann ich mir als Laie zwar nicht wirklich erklären, habe aber auch wenig Sympathie für die pauschalen Verneiner, die sofort den Untergang des digitalen Abendlandes befürchten, falls solcher Frevel mehr als nur ein Hirngespinst wäre.

Am PC höre ich mit Arcam rPAC DAC und Abacus C-Box 2. Das USB-Kabel zwischen WD My Book und PC ist von üblicher Beipackqualität, das zwischen PC und Arcam rPAC DAC ist dagegen ein ordentliches Nuforce Impulse. Die abgespielten Audiodateien sind „eigentlich“ identisch, da ich lediglich eine Kopie von der konventionellen Festplatte auf die SSD verschoben habe.

Wieso klingt die Kopie besser als das Original? Für Antworten wäre ich dankbar.

Freundliche Grüße,
never (Udo)
Bild
axxxxx

Beitrag von axxxxx »

Hallo Udo,

das mit der SSD hatten wir ja schon vor ca. 100 Jahren beim Teac WAP V6000 herausgearbeitet. :mrgreen: Warum aber eine SSD "besser klingt" (Achtung: Fundstelle des Tages!) als eine konventionelle HD hatten wir noch nicht herausgearbeitet.

Ich sehe dafür mehrere Erklärungsmöglichkeiten:
1. Das Signal wird nicht durch einen magnetischen Lesekopf nochmal "verrauscht" - optimalere Flanken.
2. Die Lesegeschwindigkeit und damit der Transfer zur nächsten Station ist schneller - das Timing ist besser.
3. Das Auslesen der Daten geschieht kontinuierlicher als bei einer konventionellen HD.

Gruß,
Kai
nihil.sine.causa
Aktiver Hörer
Beiträge: 1507
Registriert: 28.07.2011, 12:31
Wohnort: Bonn

Beitrag von nihil.sine.causa »

Hallo Frank,
frankl hat geschrieben:Leider habe ich keine SSD, um diesen Versuch zu machen (und habe in naher Zukunft auch nicht vor, eine zu kaufen, da die bezahlbaren >= 2TB SSDs noch nicht in Sicht sind).
Bei den Datenmengen ist das für die "Betriebssituation" verständlich. Da Du aber ja sowieso alles per Script bedienst, könntest Du Dir die abzuspielenden Dateien auch vorher auf eine anderes Medium kopieren und nach dem Abspielen auch wieder löschen. Ich schlage vor, das auch mal mit einem USB Stick zu versuchen oder auch mal die eingebaute Festplatte zu verwenden.

Ich kann den Effekt unterschiedlicher Medien übrigens bei meiner Kette nicht nachvollziehen. Entsprechende Tests habe ich vor einiger Zeit schon mal gemacht. Aber ich streame die Musikfiles ja auch ganz anders:

Festplatte (z.B. NAS) - Netzwerk - Linn-Streamer - Lautsprecher (Details in meinem Vorstellungsthread)

Beste Grüße
Harald
Bild
Tinitus
Aktiver Hörer
Beiträge: 1323
Registriert: 10.11.2013, 21:48

Beitrag von Tinitus »

Hallo,

Ich bin weit davon entfernt ein Spezialist der Materie zu sein. Mir geht folgendes duch den Kopf:

Die beiden Dateien (die unterschiedschiedlich klingen) sind bitidentisch. Wir nehmen weiterhin an, dass der Grund für den klanglichen Unterschied analoge Prozesse während der Reise der Daten sind, die zu etwas führen, was man bei einem analogen Signal als Rauschen bezeichnen würde. Frage: Gehen wir davon aus, dass speicherseitig der RAM unserer Rechner einer SSD Festplatte deutlich ähnlicher ist als einer HD?

Wenn dem so ist, dann will ich mal einen Vergleich bemühen:

Meine Musikdatei ist ein Wackelpudding, wenn ich den durch die Gegend trage, fängt er an zu wackeln, bleibt aber eigentlich der gleiche (bitidentische Datei, aber verrauscht auf der Reise, sozusagen Wackelpudding-Jitter). Nun stelle ich meinen Wackelpudding am Ziel auf den Tisch und warte, irgendwann wackelt er nicht mehr und ist derselbe wie am Anfang der Reise oder?

Bei mir wäre das Ziel der Reise der RAM-Speicher meines Audio-Rechners, auf welchem Weg der Wackelpudding dahinkommt ist doch egal oder?

Die Datei ist doch eine Zustandsgröße oder? Der ist es doch egal was sie des Weges hinter sich hat?
Oder ist die Datei eher wie eine nicht Newton'sche Flüssigkeit (Ketchup) bei der die Viskosität unter anderem davon abhängt, ob sie vorher geschüttelt worden ist?

Wenn ich die Datei dann aus dem Rechner über ein Programm an den DAC und von dort aus an VV/LS schicke, wo soll da der Unterschied herkommen, wenn das alles gleich bleibt?

Gruß

Uwe
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4663
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Uwe,

für mich ein wunderbarer Vergleich.
Tinitus hat geschrieben:Wenn ich die Datei dann aus dem Rechner über ein Programm an den DAC und von dort aus an VV/LS schicke, wo soll da der Unterschied herkommen, wenn das alles gleich bleibt?
Die durch die Datei als Zustandsgröße erzeugte Musik kommt nicht als Zustandsgröße bei uns an. Wir nehmen sie als "Daten auf der Reise" wahr! Bei Stereo sind es genaugenommen zwei Datenströme auf der Reise, aus denen sich das Gehirn ein Phantom(ton)bild zusammensetzt.

Grüsse
Uli
Bild
Tinitus
Aktiver Hörer
Beiträge: 1323
Registriert: 10.11.2013, 21:48

Beitrag von Tinitus »

Hallo Uli,

wenn ich also die Datei gehörtechnisch auf der Reise befindlich wahrnehme (der Wackelpudding also wackelt), so stellt sich mir die Frage, wie lange ist sein Gedächtnis (wie stark ist seine innere Dämpfung)? Ist wirklich die ganze Reise entscheidend (diverse Rechner, diverse Übertragungen und diverse Speichermedien, etc.) oder ist es nur der letzte Schritt (bei mir: die Player-Software liest die Datei im RAM und schickt sie an den DAC -> VV -> LS?
Wenn wirklich die ganze Reise entscheidend fürs Ergebnis ist, dann gäbe es in einer single PC Lösung viel weniger Möglichkeiten den Pudding zum Wackeln zu bringen oder?
Die Experimente mit MQn scheinen dieser These nicht zu widersprechen.

Gruß

Uwe
Bild
Fujak
Moderator
Beiträge: 5752
Registriert: 05.05.2009, 21:00
Wohnort: Bayern
Kontaktdaten:

Beitrag von Fujak »

Hallo Udo,
never hat geschrieben:Angeregt durch diesen Thread hatte ich dann aber einige der Audiodateien vom WD My Book in einen neuen Ordner auf die Samsung SSD kopiert und diese dann mit JPLAYmini und JPLAY abgespielt. Natürlich unter Beibehaltung aller Einstellungen bei JPLAY. Das Ergebnis hat mich überrascht: Die auf die SSD kopierten Dateien bieten eine in jeder Hinsicht bessere Wiedergabequalität, wenn ich sie für die Wiedergabe über JPLAY und JPLAYmini nutze: Stimmliche Nuancen, Konturiertheit bei Melodie und Rhythmus, Detailfülle, Verhalten im Bass etc. sind klar und eindeutig besser.
Deine Erfahrung deckt sich mit meiner und der vieler anderer JPlay-Nutzer. Und um dem ganzen noch eines drauf zusetzen: Eine mit JPlay abgespielte Datei klingt dann am saubersten/natürlichsten, wenn sie keine Dateibezeichnung mehr hat (also ".wav" oder weniger gut: ".flac") und zudem vom Rootverzeichnis (meistens also C:\) abgespielt wird. Je länger der Dateiname und je tiefer die Verzeichnisstruktur ist, von dem ein File abgespielt wird, desto unsauberer klingt er.

Im JPlay-Forum wurde vor einem Jahr aus diesem Grunde ein Skript von einem findigen User entwickelt, welches die abzuspielende Datei in das Rootverzeichnis kopiert, dort ihres Namens beraubt wird (durch den rename-Befehl), und dann in die Zwischenablage kopiert. Daraufhin wird Jplay mini gestartet und mit dem bekannten "Space"-Befehl die Wiedergabe ausgelöst. Das vollzieht sich innerhalb einer Sekunde (abhängig von Filelänge, HD/SSD-Performance und CPU-Leistung für das Kopieren) und klingt wesentlich sauberer, als direkt aus dem ursprünglichen Verzeichnis heraus abgespielt. Eingefleischte JPlayer (so wie ich lange Zeit) machen das schon länger so. Ob das für andere Player auch so gilt, müsste ein entsprechender Versuch klären.

Als mögliche Ursache sehe ich die Faktoren an, wie sie Kai weiter oben benannt hat.

Grüße
Fujak
Bild
Antworten