Hallo Horst,
in meinem asynchronen System holt sich der DAC seine codierten Daten aus einem input Buffer. Wie soll da ein zeitvarianter Effekt vom lesen irgendeines Mediums vorher irgendeinen Einfluss haben?
Das mehrere Menschen Einflüsse hören, die angeblich nicht gemessen werden können, haben für mich wenig Aussagekraft, wenn kein kontrollierter Hörtest dahinter steht.
mit asynchronen Grüßen
Roland
Software-Experimente mit Linux
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo Horst,
Deine Ausführungen klingen zwar logisch aber dennoch erschliesst sich (mir) nicht, was da nun passiert.
D.h. was das Improvefile tut ist offensichtlich
Veranschaulichung:
Puffer erzeugen, zufälliger Inhalt = 1001101011110011
Puffer löschen A = 1111111111111111
Puffer löschen B = 0000000000000000
Daten einlesen = 0011001100110011
Daten invertieren A mit XOR = 0011001100110011 ^ 1111111111111111 = 1100110011001100
Daten invertieren B mit XOR = 1100110011001100 ^ 0000000000000000 = 0011001100110011
Ergebnis = 0011001100110011
Ergebnis schreiben mit gewissen Wartezeiten = "improved" file
Soweit so klar. Am Dateninhalt hat sich genau - nicht - geändert.
Nun schreibt ja nicht das kleine Tool die Daten endgültig, das tut das Betriebssystem. Üblicherweise werden Daten blockweise übergeben, es sei denn man flusht. D.h. die Daten werden an low level Routinen des OS übergeben (low level kann dabei extrem sophisticated sein). Dazu funkt noch die Zeitscheibensteuerung (Scheduling) diverser Prozesse dazwischen. Bei einer SSD geht das Ganze noch durch die SSD-Firmware zwecks wear leveling, d.h. die Daten werden ungleichmäßig verteilt.
Ob da nun die in bufhrt durchgeführten Kommandos einen Einfluß auf die nachfolgende "unkontrollierte" Bearbeitung durch das OS haben mag ich zumindest eher bezweifeln. Für einen Test kann man das ja mal weglassen oder 500 x XOR-Kommandos rechnen.
Dass sich schwankende Zeiten auswirken kann ich mir gut vorstellen. Man braucht bloß einmal einen high precision timer in einem Programm zu triggern und die Ausführungszeit eines Kommandos oder Programms messen. Es kommen immer unterschiedliche Ergebnisse heraus. Logisch, weil eben andere Ereignisse des OS dazwischenfunken.
Allerdings, um Dein Postpaket-Beispiel zu quälen: wenn 10 Pakete geliefert werden und Du die Verarbeitung während der Lieferung beginnst, hängt die Konstanz der zeitlichen Verarbeitung davon ab, wie konstant der Liefertakt ist. Wenn aber die 10 Pakete bereits da sind, hängt es nur noch davon ab wie konstant Deine eigene Verarbeitung ist. Und so findet das doch heute statt. USB und Ethernet übertragen zumindest in Paketen. Und dann muss nur noch zwischen Wechselpuffern umgeschaltet werden, fürs Takten ist dann der DAC allein zuständig. Es sollte dem dann völlig egal sein, ob der Track vorher durch XOR Kommandos behandelt wurde bzw. ob die Pakete beim Versender wieder 5-mal aus- und eingepackt wurden.
M.b.M.n. ist dann letztlich alles ein Problem von HF-Noise auf der Masseleitung. Die Masse-Impedanz ist leider nicht unendlich klein. Passende Entstörmassnahmen sollten hier aber definitiv mehr bringen.
Just my 2 cents
Grüsse
Uli
Deine Ausführungen klingen zwar logisch aber dennoch erschliesst sich (mir) nicht, was da nun passiert.
D.h. was das Improvefile tut ist offensichtlich
Veranschaulichung:
Puffer erzeugen, zufälliger Inhalt = 1001101011110011
Puffer löschen A = 1111111111111111
Puffer löschen B = 0000000000000000
Daten einlesen = 0011001100110011
Daten invertieren A mit XOR = 0011001100110011 ^ 1111111111111111 = 1100110011001100
Daten invertieren B mit XOR = 1100110011001100 ^ 0000000000000000 = 0011001100110011
Ergebnis = 0011001100110011
Ergebnis schreiben mit gewissen Wartezeiten = "improved" file
Soweit so klar. Am Dateninhalt hat sich genau - nicht - geändert.
Nun schreibt ja nicht das kleine Tool die Daten endgültig, das tut das Betriebssystem. Üblicherweise werden Daten blockweise übergeben, es sei denn man flusht. D.h. die Daten werden an low level Routinen des OS übergeben (low level kann dabei extrem sophisticated sein). Dazu funkt noch die Zeitscheibensteuerung (Scheduling) diverser Prozesse dazwischen. Bei einer SSD geht das Ganze noch durch die SSD-Firmware zwecks wear leveling, d.h. die Daten werden ungleichmäßig verteilt.
Ob da nun die in bufhrt durchgeführten Kommandos einen Einfluß auf die nachfolgende "unkontrollierte" Bearbeitung durch das OS haben mag ich zumindest eher bezweifeln. Für einen Test kann man das ja mal weglassen oder 500 x XOR-Kommandos rechnen.
Dass sich schwankende Zeiten auswirken kann ich mir gut vorstellen. Man braucht bloß einmal einen high precision timer in einem Programm zu triggern und die Ausführungszeit eines Kommandos oder Programms messen. Es kommen immer unterschiedliche Ergebnisse heraus. Logisch, weil eben andere Ereignisse des OS dazwischenfunken.
Allerdings, um Dein Postpaket-Beispiel zu quälen: wenn 10 Pakete geliefert werden und Du die Verarbeitung während der Lieferung beginnst, hängt die Konstanz der zeitlichen Verarbeitung davon ab, wie konstant der Liefertakt ist. Wenn aber die 10 Pakete bereits da sind, hängt es nur noch davon ab wie konstant Deine eigene Verarbeitung ist. Und so findet das doch heute statt. USB und Ethernet übertragen zumindest in Paketen. Und dann muss nur noch zwischen Wechselpuffern umgeschaltet werden, fürs Takten ist dann der DAC allein zuständig. Es sollte dem dann völlig egal sein, ob der Track vorher durch XOR Kommandos behandelt wurde bzw. ob die Pakete beim Versender wieder 5-mal aus- und eingepackt wurden.
M.b.M.n. ist dann letztlich alles ein Problem von HF-Noise auf der Masseleitung. Die Masse-Impedanz ist leider nicht unendlich klein. Passende Entstörmassnahmen sollten hier aber definitiv mehr bringen.
Just my 2 cents
Grüsse
Uli
-
nihil.sine.causa
- Aktiver Hörer
- Beiträge: 1507
- Registriert: 28.07.2011, 12:31
- Wohnort: Bonn
Bedeutung der Zeitrichtigkeit bei räumlicher Schallwahrnehmung
Hallo zusammen,
die Ausführungen von Horst möchte ich zum Anlass nehmen, die Wirkmechanismen des Improvefile-Verfahrens einzugrenzen. Auch mir liegt keine vollständige Erklärung vor, aber ich habe eine Reihe von Beobachtungen (durch Tests und ausgiebige Hörsitzungen), aus denen ich meine Schlüsse ziehe.
Das Improvefile-Verfahren wirkt besonders gut bei digitalen Musikdateien mit folgenden Eigenschaften:
Nun wissen wir, dass die räumliche Schallwahrnehmung durch zwei unterschiedliche Effekte zustande kommt. Zum einen durch Zeitdifferenzen zwischen den Ohrsignalen und zum anderen durch die Richtungsempfindlichkeit der Ohren. Bei Stereoaufnahmen können wir beide Effekte ausnutzen (Laufzeitdifferenzsterofonie und/oder Pegeldifferenzsterofonie).
Da wir hier ein Zeitproblem vermuten, geht es hier um Laufzeitdifferenzsterofonie. Der räumliche Effekt kommt so zustande: Beide Signale links und rechts ertönen gleich laut aus den Lautsprechern, wir hören die Phantomschallquelle aber links, wenn der linke Lautsprecher zuerst erschallt. Es wird unmittelbar klar, dass es hier nur um Einschwingvorgänge gehen kann. Wenn wir ein eingeschwungenes Signal (im Extremfall einen Sinus) haben, können wir von Interferenz sprechen, aber nicht mehr sinnvoll von Richtungslokalisation aufgrund von Laufzeitunterschieden. Unser Gehör reagiert also sehr empfindlich auf Einschwing-Vorgänge. Oder anders gesagt: Ein Knacksen von halblinks können wir sofort räumlich zuordnen, bei einem eingeschwungenen Brummen ist es schwieriger. Es kommt also auf Einschwing-Vorgänge, auf sog. Transienten an.
Nun stellt sich die Frage, wie empfindlich unser Gehör gegen Zeitfehler bei den Transienten ist. Hierzu versuche ich eine Abschätzung. Die klassische Literatur zum Thema Stereofonie gibt Hinweise:
Nun verschiebt sich durch das Improvefile-Verfahren nicht die Phantomschallquelle um mehrere Grad, sondern es geht darum, dass die Phantomschallquellen klarer im Raum stehen, besser in der Tiefe gestaffelt sind u.s.w., also geht es offenbar um Feinheiten die mehrere Größenordnungen unter dieser Lokalisierungsschwelle 1 µs liegen müssen. Wenn diese Argumentation stimmt, liegt die Empfindlichkeit unseres Gehörs bei Zeitfehlern (mindestens) im Nanosekunden-Bereich.
Viele Grüße
Harald
die Ausführungen von Horst möchte ich zum Anlass nehmen, die Wirkmechanismen des Improvefile-Verfahrens einzugrenzen. Auch mir liegt keine vollständige Erklärung vor, aber ich habe eine Reihe von Beobachtungen (durch Tests und ausgiebige Hörsitzungen), aus denen ich meine Schlüsse ziehe.
Das Improvefile-Verfahren wirkt besonders gut bei digitalen Musikdateien mit folgenden Eigenschaften:
- Der Raum, in dem die Aufnahme gemacht wurde, wird in zusammenhängender "natürlicher" Weise dargestellt.
- Die Aufnahmen wurden mit Laufzeitdifferenz-Stereofonie-Anteil ausgeführt. D.h. AB-Hauptmikrofon, Decca Tree oder zumindest Groß-AB Raummikrofon.
- "Nativ" hochauflösende Aufnahmen zeigen größere Effekte als Aufnahmen in einfacher CD-Qualität
- Phantomschallquellen sind klarer im Raum hörbar, körperhafter und besser in der Tiefe gestaffelt, wenn die Aufnahme das hergibt.
Nun wissen wir, dass die räumliche Schallwahrnehmung durch zwei unterschiedliche Effekte zustande kommt. Zum einen durch Zeitdifferenzen zwischen den Ohrsignalen und zum anderen durch die Richtungsempfindlichkeit der Ohren. Bei Stereoaufnahmen können wir beide Effekte ausnutzen (Laufzeitdifferenzsterofonie und/oder Pegeldifferenzsterofonie).
Da wir hier ein Zeitproblem vermuten, geht es hier um Laufzeitdifferenzsterofonie. Der räumliche Effekt kommt so zustande: Beide Signale links und rechts ertönen gleich laut aus den Lautsprechern, wir hören die Phantomschallquelle aber links, wenn der linke Lautsprecher zuerst erschallt. Es wird unmittelbar klar, dass es hier nur um Einschwingvorgänge gehen kann. Wenn wir ein eingeschwungenes Signal (im Extremfall einen Sinus) haben, können wir von Interferenz sprechen, aber nicht mehr sinnvoll von Richtungslokalisation aufgrund von Laufzeitunterschieden. Unser Gehör reagiert also sehr empfindlich auf Einschwing-Vorgänge. Oder anders gesagt: Ein Knacksen von halblinks können wir sofort räumlich zuordnen, bei einem eingeschwungenen Brummen ist es schwieriger. Es kommt also auf Einschwing-Vorgänge, auf sog. Transienten an.
Nun stellt sich die Frage, wie empfindlich unser Gehör gegen Zeitfehler bei den Transienten ist. Hierzu versuche ich eine Abschätzung. Die klassische Literatur zum Thema Stereofonie gibt Hinweise:
- Die Ortungsgenauigkeit ist in Richtung der Kopfsymmetrieachse am größten
- Als Wahrnehmbarkeitsschwelle einer Mittenabweichung werden 30 µs angegeben entsprechend einem Unterschied im Schalleinfallswinkel von ca. 8°.
- Geübte Hörer sollen bereits Zeitunterschiede von 1 µs als Richtungsänderung feststellen können.
Nun verschiebt sich durch das Improvefile-Verfahren nicht die Phantomschallquelle um mehrere Grad, sondern es geht darum, dass die Phantomschallquellen klarer im Raum stehen, besser in der Tiefe gestaffelt sind u.s.w., also geht es offenbar um Feinheiten die mehrere Größenordnungen unter dieser Lokalisierungsschwelle 1 µs liegen müssen. Wenn diese Argumentation stimmt, liegt die Empfindlichkeit unseres Gehörs bei Zeitfehlern (mindestens) im Nanosekunden-Bereich.
Viele Grüße
Harald
-
nihil.sine.causa
- Aktiver Hörer
- Beiträge: 1507
- Registriert: 28.07.2011, 12:31
- Wohnort: Bonn
Hallo Uli,
Viele Grüße
Harald
Wie erklärst du dann, dass zwei Dateien auf ein und derselben Festplatte, die eine Datei improved die andere "nur" ganz nomal kopiert, unterschiedlich gut klingen? Ceteris paribus, kann man hin und herschalten. Der HF Noise ist mehr oder weniger gut entstört, beeinflusst aber doch immer in gleicher Weise, oder?uli.brueggemann hat geschrieben: ↑07.12.2023, 14:47 M.b.M.n. ist dann letztlich alles ein Problem von HF-Noise auf der Masseleitung. Die Masse-Impedanz ist leider nicht unendlich klein. Passende Entstörmassnahmen sollten hier aber definitiv mehr bringen.
Viele Grüße
Harald
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Dass identische Daterien auf einer Festplatte unterschiedlich klingen können ist ja schon länger bekannt. Da gab es IIRC schon Diskussionen ob es anders klingt je nach Anzahl Unterordner etc. Man kann sich natürlich klar machen, dass wenn ein Stück zusammenhängend geschrieben ist, der Lesekopf einer Festplatte andere Positionierungen macht als wenn das Stück beliebig partitioniert ist. Und schon gibt es unterschiedlichste Ströme (und damit Rückwirkungen auf die groundplane). Bei einer SSD haben wir keinen Motor aber je nach Lage der Daten (Stichwort wear leveling) und der damit verbundenen logischen Auswertung mag es wiederum damit verknüpften HF-Noise ergeben.nihil.sine.causa hat geschrieben: ↑07.12.2023, 15:48 Wie erklärst du dann, dass zwei Dateien auf ein und derselben Festplatte, die eine Datei improved die andere "nur" ganz nomal kopiert, unterschiedlich gut klingen? Ceteris paribus, kann man hin und herschalten. Der HF Noise ist mehr oder weniger gut entstört, beeinflusst aber doch immer in gleicher Weise, oder?
Dein Energieverbrauch ändert sich ja auch je nachdem ob Du die Flasche Bier aus dem Kühlschrank holst oder aus dem Keller
Für Interessierte macht es sicher Sinn sich einmal das Buch High Speed Digital Design - A Handbook of Black Magic anzuschauen. Das beschreibt was da so alles passiert.
Nichtsdestotrotz ist das alles aber eher zufällig. Das man Unterschiede hört und auch wiederholbar kann ich mir also gut vorstellen. Dass man das dann aber durch ein kleines Programm so easy gezielt beeinflußt will sich mir aber nicht erschliessen.
Grüsse
Uli
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4007
- Registriert: 04.05.2010, 19:37
Hallo Uli,
ich tendiere stark zu Horsts Denkansatz,
Es grüßt
Bernd Peter
ich tendiere stark zu Horsts Denkansatz,
da wie Gert bestätigt, es auf einer SLC SSD noch besser wird als auf einer üblichen MLC SSD.Das heißt dass aufgrund von unterschiedlicher Spannung der Speicherzelle die Flipflop Triggerflanke der Speicherzelle mal eher und mal später ausgelöst wird.
Es grüßt
Bernd Peter
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo Bernd Peter,Bernd Peter hat geschrieben: ↑07.12.2023, 16:20 ich tendiere stark zu Horsts Denkansatz,
Das heißt dass aufgrund von unterschiedlicher Spannung der Speicherzelle die Flipflop Triggerflanke der Speicherzelle mal eher und mal später ausgelöst wird.
ich könnte da zustimmen, wenn die Daten bei der Wiedergabe genauso seriell ausgegeben würden wie sie denn gelesen werden. Nun wird aber normalerweise zwischengepuffert (die SSD Firmware schickt die Daten nicht Bit für Bit einzeln zum DAC), stereo links/rechts ist dabei ebenfalls gemultiplext, das wird dann erst später in die beiden Kanäle zerpflückt. Horst verwendet wohl einen USB -> AES Konverter mit eigener Clock, auch der fordert sich die Daten paketweise an und macht damit größere Zeitscheiben bein Einlesen. Wie soll das Flipflop Triggerflanke der Speicherzelle über diese Strecke die OCXO im Takt verändern?
Grüsse
Uli
Hallo Uli,
keiner von uns hat bisher eine schlüssige oder gar vollständige Erklärung, es sind alles Mutmaßungen. Was alle eint, die Improvefile verwendet haben ist, dass die gleichen Verändungen übereinstimmend festgestellt werden. Der Klangeindruck ist repruduzierbar.
Ich empfinde die Fileproblematik schon allein deshalb sehr seltsam, wenn man sich überlegt, was noch alles mit den Daten passiert,
wenn sie von dem Datenträger gelesen sind, auf den Improvefile gewirkt hat.
Bei mir geht es dann noch durchs Netzwerk mit Switches, in den Renderer, der einen Puffer hat, über AES an den Dac.
Rein verstandesgemmäß sträubt sich da bei mir alles, wenn da nur die Ohren nicht wären.
Grüsse Jürgen
keiner von uns hat bisher eine schlüssige oder gar vollständige Erklärung, es sind alles Mutmaßungen. Was alle eint, die Improvefile verwendet haben ist, dass die gleichen Verändungen übereinstimmend festgestellt werden. Der Klangeindruck ist repruduzierbar.
Ich empfinde die Fileproblematik schon allein deshalb sehr seltsam, wenn man sich überlegt, was noch alles mit den Daten passiert,
wenn sie von dem Datenträger gelesen sind, auf den Improvefile gewirkt hat.
Bei mir geht es dann noch durchs Netzwerk mit Switches, in den Renderer, der einen Puffer hat, über AES an den Dac.
Rein verstandesgemmäß sträubt sich da bei mir alles, wenn da nur die Ohren nicht wären.
Grüsse Jürgen
Hallo Uli und Roland,
ich kann Eure Skepsis gut nachvollziehen. Es ist ja, zumindest bei mir, noch viel schlimmer als Uli aufgezeigt hat: Die Datei, die ich mit 'improvefile' neu schreibe ist meist eine flac-Datei. Zum Musikspielen wird die ausgepackt und dann rechne ich massiv damit herum - resamplen, 512 kTaps - Korrekturfilter - MS - LoCo - und erst das Ergebnis wird über einen DDC zum DAC geschickt. Und alles geht durch diverse Controller, Speicher, Caches, und die physikalische Repräsentation der Daten wird mehrfach gewandelt.
Da ist es doch unglaublich, dass verschiedene Repräsentationen (informationstechnisch) identischer Daten auf der gleichen Festplatte zu hörbaren Unterschieden führen sollen. (Ähnlich unglaublich wie verschiedene Laufwerke zum Rippen oder Ethernetkabel bei Kopieren auf die Festplatte, oder, oder, oder ... zu hörbaren Unterschieden führen können.)
Das Gute bei der Diskussion an dieser Stelle ist, dass es vergleichweise leicht und sehr kostengünstig jeder Interessierte selbst ausprobieren kann (gerne mit Blindtests, und dann hier bitte berichten). Auch wenn etwa Harald und Gert hier aufwändige (und durchaus sinnvolle) Setups vorgestellt haben: Zum Evaluieren der Effekte kann auch ein nicht audiophiles Notebook genügen. Vielleicht können Windows-Nutzer das sogar im Windows-Subsystem for Linux zum Laufen bringen?
Wenn Ihr die Berichte hier für unglaubwürdig haltet: schüttelt den Kopf oder lacht und lest in einem anderen Thread weiter.
Wenn Ihr neugierig seid: probiert es einfach aus.
Viele Grüße,
Frank
ich kann Eure Skepsis gut nachvollziehen. Es ist ja, zumindest bei mir, noch viel schlimmer als Uli aufgezeigt hat: Die Datei, die ich mit 'improvefile' neu schreibe ist meist eine flac-Datei. Zum Musikspielen wird die ausgepackt und dann rechne ich massiv damit herum - resamplen, 512 kTaps - Korrekturfilter - MS - LoCo - und erst das Ergebnis wird über einen DDC zum DAC geschickt. Und alles geht durch diverse Controller, Speicher, Caches, und die physikalische Repräsentation der Daten wird mehrfach gewandelt.
Da ist es doch unglaublich, dass verschiedene Repräsentationen (informationstechnisch) identischer Daten auf der gleichen Festplatte zu hörbaren Unterschieden führen sollen. (Ähnlich unglaublich wie verschiedene Laufwerke zum Rippen oder Ethernetkabel bei Kopieren auf die Festplatte, oder, oder, oder ... zu hörbaren Unterschieden führen können.)
Das Gute bei der Diskussion an dieser Stelle ist, dass es vergleichweise leicht und sehr kostengünstig jeder Interessierte selbst ausprobieren kann (gerne mit Blindtests, und dann hier bitte berichten). Auch wenn etwa Harald und Gert hier aufwändige (und durchaus sinnvolle) Setups vorgestellt haben: Zum Evaluieren der Effekte kann auch ein nicht audiophiles Notebook genügen. Vielleicht können Windows-Nutzer das sogar im Windows-Subsystem for Linux zum Laufen bringen?
Wenn Ihr die Berichte hier für unglaubwürdig haltet: schüttelt den Kopf oder lacht und lest in einem anderen Thread weiter.
Wenn Ihr neugierig seid: probiert es einfach aus.
Viele Grüße,
Frank
Hallo Horst,Trinnov hat geschrieben: ↑07.12.2023, 14:18
Möglicherweise liegt der Unterschied gar nicht in der physikalischen Position der Audio File Daten auf dem Datenträger, sondern im absoluten Spannungswert der 0 oder 1 Information in der jeweiligen Speicherzelle. Das Aufladen von Kondensatoren erfolgt immer nach einer e-Funktion.
Auch eine Speicherzelle besteht unter anderem aus einem oder mehreren winzig kleinen Kondensatoren. Zum Beispiel die MOS-Kondensatoren.
Somit macht es einen Unterschied wie lange und vor allen Dingen wie gleichmäßig ich in der Zeit die einzelnen Speicherzellen beschreibe. Natürlich werden alle Pegel im jeweils spannungsmäßig sicheren Spannungsbereich geschrieben, aber beim Auslesen entstehen durch die leicht variierenden Pegel der Zellen wieder minimale Zeitvariationen in der nachfolgenden seriellen Pegelauswertung.
Das heißt dass aufgrund von unterschiedlicher Spannung der Speicherzelle die Flipflop Triggerflanke der Speicherzelle mal eher und mal später ausgelöst wird. Das ist aber nur meine These. Wer da mehr weiß, darf das gerne hier kundtun.
[...]
Das DeltaWave Tool kann man kostenlos hier downloaden.
https://deltaw.org/
danke für Deine Überlegungen. Ich bin auch kein Speicherzellen-Entwickler und habe nur eine vage Vorstellung von den physikalischen Details. Ich vermute auch, genau wie Du es beschreibst, dass die Speicherzellen in der kopierten Datei irgendwie gleichmäßiger geladen sind. Bevor es genügend große SSDs gab, habe ich ja ähnliche Effekte auch mit einer herkömmlichen Festplatte beobachtet. Dort habe ich mir vorgestellt, dass die Daten in der Kopie mit einer gleichmäßigeren Magnetisierung abgelegt werden. Vor Jahren hatte ich mir mal eine Visualisierung dazu ausgedacht, die ich auf meiner Webseite (Abschnitt "Description of the problem") verwendet habe.
Testen, ob zwei Dateien bit-identisch sind, kann man übrigens auf jedem Linux/Unix mit dem Kommando:
cmp datei1 datei2
Wenn es keine Ausgabe gibt, sind die Dateien gleich.
Viele Grüße,
Frank
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4007
- Registriert: 04.05.2010, 19:37
Hallo Bernd-Peter,
Daten im Sinne der EDV haben keinen Datenzeitcode. Was soll das sein?
Bei der Übermittlung der Datenpakete spielt natürlich eine Taktung eine Rolle, um die einzelnen Werte auszulesen bzw. zu interpretieren.
Womöglich sind aber stabile Spannungsniveaus im Speicher ausschlaggebend!?
Es ist besonders bei QLC schon faszinierend, dass das überhaupt funktioniert, dort ist ja nix mehr nur noch 0 oder 1. das gleiche gilt für Gigabit Lan mit (ich glaube) 3 Zuständen. Der Datentransport dort wird dann auch wieder geclockt.
Mit einfachen Modellen scheint mir hier keine Erklärung gelingen zu können.
Grüsse Jürgen
Daten im Sinne der EDV haben keinen Datenzeitcode. Was soll das sein?
Bei der Übermittlung der Datenpakete spielt natürlich eine Taktung eine Rolle, um die einzelnen Werte auszulesen bzw. zu interpretieren.
Womöglich sind aber stabile Spannungsniveaus im Speicher ausschlaggebend!?
Es ist besonders bei QLC schon faszinierend, dass das überhaupt funktioniert, dort ist ja nix mehr nur noch 0 oder 1. das gleiche gilt für Gigabit Lan mit (ich glaube) 3 Zuständen. Der Datentransport dort wird dann auch wieder geclockt.
Mit einfachen Modellen scheint mir hier keine Erklärung gelingen zu können.
Grüsse Jürgen
-
lukivision
- Aktiver Hörer
- Beiträge: 282
- Registriert: 07.03.2014, 09:38
- Wohnort: Bochum
Hallo zusammen, mit Freude verfolge ich diese Diskussion. Ich kann mir da keinen Zufall vorstellen, dazu ist das Prinzip von Ursachen und Wirkung einfach zu universell. Nur weil wir diese Gesetzmäßigkeiten (noch) nicht kennen, bedeutet es nicht, daß es keine gibt. Total spannend ist es, herauszufinden was nun die Ursache dafür ist, dass Franks Erfindung funktioniert. Persönlich konnte ich das vor, ich glaube mehr als 10 Jahren ist das inzwischen her, in Franks Hörraum erleben. Es war damals nur ein ganz beiläufiger Hinweis von Frank, dass er ein Verfahren entwickelt habe, mit denen die Daten kopiert werden und ob ich nicht Lust hätte, mir das anzuhören. Weitere Erklärungen sind mir nicht erinnerlich. Seine Anlage entsprach damals bestimmt nicht den Stand von heute. Ich würde mir auch nicht zuschreiben, ein Goldohr zu sein, aber nach wenigen Sekunden war der Unterschied hörbar. Es ist eines von diesen vielen, vielen Merkwürdigkeiten, die unser Hobby umgibt und denen hier in diesem Forum technisch/wissenschaftlich nachgegangen wird und da freue ich mich immer wieder, Mitglied dieses ehrenwerten Clubs zu sein.
Schönes Wochende wünscht
Luki
Schönes Wochende wünscht
Luki
-
music is my escape
- Aktiver Hörer
- Beiträge: 1535
- Registriert: 03.07.2012, 10:56
- Wohnort: Leipzig
Hallo an alle,
Eine tolle Diskussion; danke.
Meine kurzen laienhaften Einwürfe:
1. zu Ulis These HF-Noise auf Masseleitung:
Das erklärt meiner Erfahrung nach unglaublich viele Klangeinflüsse, auch in der hier beschriebenen Richtung und es lohnt sich sehr, penibel darauf zu achten. Aber es kann nicht die Lösung für alles sein, da etwaige Klangunterschiede auch problemlos durch Lichtleiterstrecken etc... weitergegeben werden, selbst wenn man diese vom Stromnetz getrennt betriebt, es also keinerlei elektr. Verbindungsleitung, weder auf Daten- noch auf Stromversorgungsebene, gibt.
Mein schon öfter beschriebenes, unglaublich simples und jederzeit einfach und überall reproduzierbares Totschlagbeispiel bei diesem Thema: mein Questyle DAP (ein ziemlich ausgefuchster portabler NoNonsenseAudioplayer im unteren vierstelligen Bereich) macht Unterschiede bspw. je nach Firmware, flac oder wav oder auch zwischen versch. SD-Karten in gleicher Weise hörbar, egal ob er direkt an Kopfhörern hängt, per LineOut mit dem Vorverstärker vebunden ist oder aber, und das ist der eigentliche Punkt, im Akkubetrieb per optischem Ausgang einen externen DAC füttert (alle übrigen Verbindungen sind dabei selbstverständlich getrennt).
Selbiges wurde auch in anderen vergleichbaren Konfigurationen, aber auch bspw. bei WLAN-Verbindungen (ebenfalls akkubetrieben) dutzendfach von versch. Musikfreunden beschrieben.
Es muss also etwas ins 'digitale' Signal gelangen, was auch in elektrischen Verbindungen Einfluss ausübt, unabhängig etwaiger Masseverbindungen bzw. elektr. Leitungen ganz allgemein.
2. die Hörbarkeit etwaiger Einflüsse auch über etliche Verarbeitungsschritte, von denen jeder einzelne nach 'offizieller' Lesart alles davor passierte 'unhörbar' machen müsste:
Hier kommt mir immer wieder der von Horst @trinnov geprägte Begriff des 'Fehlerbudgets' in den Sinn, nach dem gewisse Dinge erst in Summe durchschlagen.
So, wie beispielsweise in der Medizin (bzw. beinah allen praktischen Ursache-Wirkungs-Relationen) das Meiste multifaktoriell begründet ist, halte ich das auch hier für plausibel und es ist immer noch am besten, egal auf welcher Ebene erst garkeine Fehler entstehen zu lassen, um sie hinterher nicht ausbügeln zu müssen bzw. darauf zu hoffen, dass sie eh keine Rolle spielen.
Freundliche Grüße,
Thomas
Eine tolle Diskussion; danke.
Meine kurzen laienhaften Einwürfe:
1. zu Ulis These HF-Noise auf Masseleitung:
Das erklärt meiner Erfahrung nach unglaublich viele Klangeinflüsse, auch in der hier beschriebenen Richtung und es lohnt sich sehr, penibel darauf zu achten. Aber es kann nicht die Lösung für alles sein, da etwaige Klangunterschiede auch problemlos durch Lichtleiterstrecken etc... weitergegeben werden, selbst wenn man diese vom Stromnetz getrennt betriebt, es also keinerlei elektr. Verbindungsleitung, weder auf Daten- noch auf Stromversorgungsebene, gibt.
Mein schon öfter beschriebenes, unglaublich simples und jederzeit einfach und überall reproduzierbares Totschlagbeispiel bei diesem Thema: mein Questyle DAP (ein ziemlich ausgefuchster portabler NoNonsenseAudioplayer im unteren vierstelligen Bereich) macht Unterschiede bspw. je nach Firmware, flac oder wav oder auch zwischen versch. SD-Karten in gleicher Weise hörbar, egal ob er direkt an Kopfhörern hängt, per LineOut mit dem Vorverstärker vebunden ist oder aber, und das ist der eigentliche Punkt, im Akkubetrieb per optischem Ausgang einen externen DAC füttert (alle übrigen Verbindungen sind dabei selbstverständlich getrennt).
Selbiges wurde auch in anderen vergleichbaren Konfigurationen, aber auch bspw. bei WLAN-Verbindungen (ebenfalls akkubetrieben) dutzendfach von versch. Musikfreunden beschrieben.
Es muss also etwas ins 'digitale' Signal gelangen, was auch in elektrischen Verbindungen Einfluss ausübt, unabhängig etwaiger Masseverbindungen bzw. elektr. Leitungen ganz allgemein.
2. die Hörbarkeit etwaiger Einflüsse auch über etliche Verarbeitungsschritte, von denen jeder einzelne nach 'offizieller' Lesart alles davor passierte 'unhörbar' machen müsste:
Hier kommt mir immer wieder der von Horst @trinnov geprägte Begriff des 'Fehlerbudgets' in den Sinn, nach dem gewisse Dinge erst in Summe durchschlagen.
So, wie beispielsweise in der Medizin (bzw. beinah allen praktischen Ursache-Wirkungs-Relationen) das Meiste multifaktoriell begründet ist, halte ich das auch hier für plausibel und es ist immer noch am besten, egal auf welcher Ebene erst garkeine Fehler entstehen zu lassen, um sie hinterher nicht ausbügeln zu müssen bzw. darauf zu hoffen, dass sie eh keine Rolle spielen.
Freundliche Grüße,
Thomas
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Für mich ist die Diskussion zum Thema Speicherlevel zielführend genau eben am Ziel vorbei. Ein jeder von uns hat mit Sicherheit andere Speicherbausteine im Rechner.
Was tut das bufhrt?
Es alloziert einen Speicherbeich (Buffer), löscht den erst einmal indem alle Bits angeknipst und danach zweimal ausgeknipst werden. Das wäre soweit ok bzgl. sicheres Löschen.
Danach wird die Quelldatei in den Buffer eingelesen. Gut, da könnten die jeweiligen Bits noch wacklig sein. Insofern wird 3mal hintereinander jedes Datenwort ins CPU-Register kopiert und invertiert. Der Buffer wird wieder gelöscht, das Datenwort nochmal negiert und dann in den Buffer zurückgeschrieben.
Die Erklärung mit den wackligen Speicherzellen könnte man so annehmen, aber wieso sind nur die Speicherzellen wacklig aber nicht die CPU-Register?
Am Ende werden die nunmehr so "gefestigten" Speicherzellen per fwrite auf den Datenträger ausgegeben. Dahinter steckt ein reichlich aufwändiger Prozess (siehe die diversen Dateisysteme bei Linux) wo wiederum reichlich Speicher verwendet wird. Der dann seltsamerweise nicht wackelt. Und die Firmware der SSD schreibt dann wiederum "beliebig" auf unterschiedlichste Adressen, splittet also das Ganze auf.
Und im Ergebnis gibt es dann zwei Files, die beim Auslesen und Vergleichen bitidentisch sind. Obwohl bei der ersten Datei die Speicherzellen beliebig wackeln und bei der zweiten Datei ein mystisches Verfestigen passiert.
Seltsam alles. Und dann übersteht das alles noch weitere Bearbeitungsschritte, siehe Franks flac auspacken, resampeln, Korrektur, MS, Loco ...
Da passiert ja weiterhin all das im nachhinein, was Frank bei seinem "Description of the problem" aufführt.
Fragen über Fragen. Seid mir nicht allzu böse wenn ich den advocatus diaboli spiele.
Grüsse
Uli
Was tut das bufhrt?
Es alloziert einen Speicherbeich (Buffer), löscht den erst einmal indem alle Bits angeknipst und danach zweimal ausgeknipst werden. Das wäre soweit ok bzgl. sicheres Löschen.
Danach wird die Quelldatei in den Buffer eingelesen. Gut, da könnten die jeweiligen Bits noch wacklig sein. Insofern wird 3mal hintereinander jedes Datenwort ins CPU-Register kopiert und invertiert. Der Buffer wird wieder gelöscht, das Datenwort nochmal negiert und dann in den Buffer zurückgeschrieben.
Die Erklärung mit den wackligen Speicherzellen könnte man so annehmen, aber wieso sind nur die Speicherzellen wacklig aber nicht die CPU-Register?
Am Ende werden die nunmehr so "gefestigten" Speicherzellen per fwrite auf den Datenträger ausgegeben. Dahinter steckt ein reichlich aufwändiger Prozess (siehe die diversen Dateisysteme bei Linux) wo wiederum reichlich Speicher verwendet wird. Der dann seltsamerweise nicht wackelt. Und die Firmware der SSD schreibt dann wiederum "beliebig" auf unterschiedlichste Adressen, splittet also das Ganze auf.
Und im Ergebnis gibt es dann zwei Files, die beim Auslesen und Vergleichen bitidentisch sind. Obwohl bei der ersten Datei die Speicherzellen beliebig wackeln und bei der zweiten Datei ein mystisches Verfestigen passiert.
Seltsam alles. Und dann übersteht das alles noch weitere Bearbeitungsschritte, siehe Franks flac auspacken, resampeln, Korrektur, MS, Loco ...
Da passiert ja weiterhin all das im nachhinein, was Frank bei seinem "Description of the problem" aufführt.
Fragen über Fragen. Seid mir nicht allzu böse wenn ich den advocatus diaboli spiele.
Grüsse
Uli