Software-Experimente mit Linux

[Trinnov]

Hallo zusammen,

ich muss schon sagen, dass ich sehr erstaunt bin, wie viel Sprengstoff ich mit meinem Beitrag da ins Feuer gekippt habe.
Meine Aussage bezüglich der Speicherzellen ist als These zu verstehen, so habe ich das auch in meinem Beitrag benannt.
Wer eine andere schlüssige Idee oder gar die Lösung für diese Phänomene hier parat hat, sollte das unbedingt kundtun.
Solange keine zweite glaubhafte These existiert, bleibe ich bei meiner These.
Es gibt ja von meinem Verständnis her gar nicht so viele Möglichkeiten eine Datei anders in einem Halbleiterspeicher abzulegen.
Der "Füllstand" also die tatsächliche Spannung der Speicherkapazitäten ist eine der Möglichkeiten.
Die Datei ist definitiv anders auf dem Datenträger abgelegt, da ich diesen nehmen kann, um ihn in einen anderen Rechner zu stecken und dann immer noch die Unterschiede zu hören. Man profitiert also nicht nur zur Laufzeit kurz nach dem improven.
Einen längeren / kürzeren Pfad ("Lageklang") zur jeweiligen Datei auf der OS Ebene beim Ausspielen / Auslesen schließe ich mal als Ursache aus. Das Thema hat man als Nutzer selbst in der Hand.

Die Wissenschaft weiß leider auch, dass eine Datensicherung auf einem Halbleiterspeicher Datenträger nicht für Jahrzehnte sicher ist, da auch bei Flashspeicher die Speicherzellen genauer gesagt die Speicherkondensatoren / Isolationsschichten ihre Ladung langsam verlieren und irgendwann ein Refresh notwendig ist. Das ist keine These sondern Faktum!

Noch etwas zum File Improve Verfahren. Wer es nicht glaubt, dass es funktioniert, hat die Möglichkeit es selbst zu testen und müsste dann nicht mutmaßen dass es theoretisch gar nicht funktionieren kann, weil es nach aktuellem theoretischen Kenntnisstand der Materie nicht funktionieren darf.

Bitte beim Testen des File Improve Verfahrens das dafür notwendige Linux OS keinesfalls auf einem Windows Rechner in einer WSL Umgebung oder ähnlichem installieren. Der Schuss könnte tatsächlich nach hinten losgehen, da dann nämlich zwei Betriebssysteme gleichzeitig laufen, das leichte ressourcenschonende DietPi (eine Debian Variante) und dann noch zusätzlich das "fette" ressourcenfressende Windows 10 mit vielleicht üblicherweise 150 Prozessen und 1800 Threads.
Einem mit dieser Installationsvariante ausgeführten "File Improve" würde ich deutlich weniger oder gar keine Verbesserung zutrauen.
Installiert wäre ein Debian inkl. aller notwendigen Pakete und Franks Programmen als Windows Subsystem in ca. 15 Minuten. Ich habe das vorhin mal probiert. Habe dann aber abgebrochen als ich feststellte, dass das normale Debian nicht den schönen drive_manager des DietPi mitbringt um den Pfad zum Improve Ordner Datenträger zu erfassen um ihn ins Script einzutragen um dann sofort mit einem einzigen Befehl mit dem "improven" loszulegen. Aber wie gesagt, obwohl es Windows 10 unterstützt, bitte das WSL als Möglichkeit einfach ausschließen. Man sollte direkt eine ressourcenschonende DietPi Distribution booten, um das bestmögliche Ergebnis zu erhalten.

@Thomas (music is my escape)
Ich bin fassungslos, wie gut dein Gedächtnis ist. Großen Respekt!
Den ungewöhlichen Begriff "Fehlerbudget" habe ich tatsächlich vor langer Zeit einmal geprägt.


Viele Grüße
Horst

[uli.brueggemann]

Ich habe mal für Nicht-Linux-Nutzer ein kleines Programm für Windows gemacht.
Download per https://www.audiovero.de/freedownload/i ... vefile.exe.
Zum Angucken der Quellcode mit https://www.audiovero.de/freedownload/i ... /Unit1.txt
Es wird der Ablauf mit memclean und memrefresh nachgebildet. Nicht enthalten ist das Thema mit der Zeitsteuerung, mir ist nicht klar wieso das z.B. auf 2000 Loops/Sekunde begrenzt wird. Vielleicht sagt Frank was dazu. Nichtsdestotrotz wird eben im zugewiesenen Speicher eine Datei reingeladen, der Speicher wird gelöscht, es wird nochmals geladen und refresht.

Vielleicht hört da ja jemand schon was.

FF - viel Vergnügen
Uli

[uli.brueggemann]

Download per https://www.audiovero.de/freedownload/i ... vefile.exe.
Zum Angucken der Quellcode mit https://www.audiovero.de/freedownload/i ... /Unit1.txt

Ich habe in der Zwischenzeit nochmal ein bisschen gespielt und das improvefile für Windows upgedatet. Mein Ziel war es , das Ganze einmal möglichst anschaulich zu programmieren (mit Delphi), ich hasse das Programmieren mit C, da wird der Code schnell verschwurbelt und unleserlich.
Im Gegensatz zur Linux-Version habe ich etwas geändert, das Programm macht nun 1000 Durchläufe je Sekunde (anstelle 2000) mit einer Paketgröße von 6144 Bytes (anstelle 3072). Damit ist der Datendurchsatz derselbe, ich verwende dazu aber die Möglichkeit heutiger CPUs direkt mit 64 bit zu rechnen anstelle mit 32 bits. Ansonsten sollte sich das Programm identisch verhalten.

Grüsse
Uli

[tinnitus]

Hallo Uli,
kannst Du mal einen ABX Test mit einer unbehandelten und einer behandelten Datei machen? Eigentlich sind alle aufgerufen, die klare Veränderungen gehört haben, solch einen Test zu machen.

abxte Grüße Roland.

[tinnitus]

Ich habe mit Ulis Pgm gearbeitet,
hier mein ABX Test

foo_abx 2.1 report
foobar2000 v1.6.3
2023-12-12 16:03:36

File A: November 99.flac
SHA1: b97b9824dd435dc915001c95e68144608fe610a7
Gain adjustment: -0.09 dB
File B: November 99_improve.flac
SHA1: b97b9824dd435dc915001c95e68144608fe610a7
Gain adjustment: -0.09 dB

Output:
UPnP : Audio-1/Keller, 16-bit
Crossfading: NO

16:03:36 : Test started.
16:07:38 : 00/01
16:08:27 : 00/02
16:09:11 : 01/03
16:09:55 : 01/04
16:11:17 : 01/05
16:11:51 : 01/06
16:12:42 : 02/07
16:13:31 : 02/08
16:14:13 : 02/09
16:14:44 : 03/10
16:14:44 : Test finished.

----------
Total: 3/10
p-value: 0.9453 (94.53%)

-- signature --
58e716873544993f230e7a0a32025c155fa5bee0


VG Roland

[uli.brueggemann]

Hallo Uli,
kannst Du mal einen ABX Test mit einer unbehandelten und einer behandelten Datei machen? Eigentlich sind alle aufgerufen, die klare Veränderungen gehört haben, solch einen Test zu machen.

Hallo Roland,
da ich keine klaren Veränderungen höre habe ich auch kein ABX gemacht. Im Prinzip höre ich keinen Unterschied, auch nicht mit mehreren Varianten des Programms.

Ich glaube nicht wirklich an die optimierte "stille Post" von der Datei auf der Festplatte bis zur Soundausgabe. Wenn, dann würde das clean/refresh am meisten am Ausgang vor der Soundkarte Sinn machen, also im Alsa oder Asio-Treiber. Da ja auch dort die Bits richtig sind (sonst würde man schnell Fehler hören) sollte dann dort das Verhalten der Speicherzellen die wesentliche Rolle spielen. Obwohl, dann kommen ja noch die Datenpakete per USB/Ethernet etc. Und so wäre es vielleicht ideal wenn denn der Receiver in der Soundkarte die empfangenen Bits mehrfach in den Speicher "klopft" bevor es per I2S seriell an den Wandlerchip geht.

Grüsse
Uli

[Trinnov]

Hallo,

mit geht es wie Uli.
Bei Einsatz der Windows Variante höre ich keine Unterschiede.
Eben, weil es keine gibt. Somit macht auch der geforderte ABX Test null Sinn.

Viele Grüße
Horst

[tinnitus]

Hallo Horst,
du kannst doch zwei Dateien die mit Franks Version bearbeitet worden sind vergleichen.
Was macht Uli denn anders?

Grüße Roland

[Trinnov]

Hallo Roland,

die Frage ist eher, was Windows anders macht, nicht was Uli anders macht.
Uli gibt alles und das ist sehr lobend zu erwähnen.
Etwas was man mit Linux programmieren und ausführen kann, lässt sich nicht unbedingt exakt so auf der Windows Ebene umsetzen, bzw. erreicht genauer gesagt nicht die zeitliche Präzision.
Frank und Uli können das aber sicherlich viel besser erklären als ich.

Viele Grüße
Horst

[nihil.sine.causa]

Hallo Roland,

dein ABX Test zeigt (wenn ich die Resultate überhaupt richtig lese), dass du mit dem Verfahren von Uli, dem Abspielen eines bestimmten Stücks in 16 Bit auf deiner Abhörkette unter Verwendung von foobar keine Unterschiede hast hören können. Das zeigt aber eben überhaupt gar nicht, dass das Verfahren von Frank zu keinen hörbaren Unterschieden führt.

Was macht Uli denn anders?

Gute Frage. Unterschiedliche Betriebssysteme, unterschiedliche Entwicklungsumgebungen, unterschiedliche Programmiersprachen - schließlich geht es darum, das Betriebssystem eben nicht routinemäßig schreiben und cachen zu lassen. Daher sind bei Frank auch Teile in Assembler geschrieben z.B. für Intel-Rechner. Letzteres habe ich schon mehrfach angemerkt hier im Forum.

Jedenfalls, wenn ich in meinem Setup, Improvefile anwende, dann bekomme ich sehr deutlich hörbare Unterschiede zu den nicht-improvten Musikdateien. Natürlich unter sonst identischen Bedingungen. Und wenn ich bei der Anwendung von Improvefile auch noch meine Akku-Stromversorgung verwende, ein minimalistisches Linux (z.B. DietPi), alle HF-Störquellen entferne, die ich entfernen kann, dann werden die Ergebnisse nochmals deutlich verbessert. Vergleichen kann ich das ja - wiederum unter identischen Bedingungen - jederzeit.

Eine Erklärung habe ich nicht. Ich vermute, dass es um feinste Zeitfehler (im Nanosekundenbereich) geht, die auskorrigiert werden. Die Zusammenhänge dazu habe ich weiter oben hier im Thread skizziert. Aber warum sich das in einer Kette manifestiert, die ziemlich "lang" ist von der Datei auf der Festplatte über den Roon-Rechner, das Netzwerk mit Glasfaser und Umsetzer, den G-Hub als Streamer und schließlich dem arfi-system193 ADDA als DAC, warum sich die Verbesserung also in einer solch langen Kette manifestiert, kann ich nicht sagen. Als ich Ende Oktober anfing mit den ersten Tests, war das eher aus einer Laune heraus: das wolltest du doch schon immer mal ausprobieren. Und dann hat sich halt gezeigt, dass das Verfahren auch in der langen Digital-Kette sehr viel bringt.

Und ist das schlimm, keine Erklärung zu kennen? Also wenn ich Pfeffer an ein Stück Fleisch gebe, dann denke ich nicht daran, was da chemisch genau passiert, wenn das an meinen Gaumen kommt, sondern ich mache es, weil es mir schmeckt. Warum soll ich ausgerechnet in der Audio-Welt immer alles erklären können? Es reicht doch, dass ich es höre. Und hier sprechen wir ausdrücklich von fundamentalen Grenzen der Digitaltechnik. Als Anwender reicht es mir, wenn ich weiß, wie ich gewisse Schwierigkeiten umgehen kann, auch wenn ich nicht alle Wirkmechanismen verstanden habe. Dass es auch in diesem Bereich durchgängige Kausalketten gibt, ist für mich ohne Zweifel (nihil sine causa). Aber ich muss es nicht erklären können, Hauptsache, die Medizin wirkt: Improvefile in meiner Audio-Kette - wie der Pfeffer auf dem Steak.

In diesem Sinne - happy listening!
Harald

[tinnitus]

Hallo Harald,
kannst du in deinem Audio System einen ABX Test durchführen?
Bzw. welche Voraussetzungen benötige ich um die Wirkung von improvefile zu erreichen? Linux habe ich ja auch im Einsatz.
Oder wo kann ich das nachlesen?

VG Roland

[frankl]

Hallo Uli,

so richtig verstehe ich nicht, warum Du ein Programm zum Testen anbietest, mit dem Du selbst die hier diskutierten Effekte gar nicht nachvollziehen kannst. Wie ich schon anderswo angemerkt habe, sind die genauen Parameter, mit denen ich mein Programm im Beispielskript aufrufe, nicht in Stein gemeißelt. Entsprechend habe ich auch keine Begründung, warum die so wie in meinem Beispiel sein sollen.

Ich kenne mich mit Windows und audiophil optimiertem Windows nicht aus, denke aber, dass Windows als solches kein Hindernis darstellt für ein Programm mit der "Funktionalität" wie 'improvefile'.

Hallo Roland,

aus dem Dateinamen in Deinem Test vermute ich, dass Du das erste Stück des Albums "Neighbourhood" von Manu Katché genutzt hast. Für ein ECM-Album finde ich das recht komprimiert und es sollte (auch ungewöhnlich für ECM) invertiert abgehört werden. Bei mir funktioniert 'improvefile' auch mit diesem Album sehr gut. In der kopierten Version klingen zum Beispiel Klavier und Schlagzeug sauberer und akzentuierter und die Abbildung der räumlichen Tiefe (bei korrigierter Polarität) verbessert sich weiter. Ich höre es gerade ...

Ich habe übrigens im früheren Stadium dieses Projektes etliche Blindtests gemacht, weil ich auch zuerst manchmal gedacht habe, dass ich mir die Änderungen vielleicht nur einbilde. Darüber habe ich auch im entsprechenden Thread ("Bitidentische ...") damals berichtet. In der heutigen Version der Programme sehe ich dafür keine Notwendigkeit mehr.

Viele Grüße,
Frank

[frankl]

Die Erklärung mit den wackligen Speicherzellen könnte man so annehmen, aber wieso sind nur die Speicherzellen wacklig aber nicht die CPU-Register?

Hallo Uli,

ich würde nicht den Ausdruck "wackelig" verwenden, aber ich denke, dass Du hier einen relevanten Punkt ansprichst.
Auf Festplatten und SSDs gibt es ja nach den Beobachtungen mehrerer Forenten eine gewisse Bandbreite, wie Daten physikalisch repräsentiert werden, so dass sich Klangunterschiede ergeben können.

Und mein Eindruck ist in der Tat, dass in CPU-Registern und im Level 1 Cache (nahe an der CPU) diese Bandbreite viel kleiner ist. Wenn das nicht so wäre, hätte ich auch keine vage Erklärung, wieso mein Programm die besprochene Wirkung hat.

Zum Beispiel habe ich festgestellt, dass es für den Klang gut ist, wenn der Puffer zur Übergabe der Daten zwischen zwei Programmen (bei mir zur Zeit 'brutefir' und 'playhrt') in den Level 1 Cache passt (also nur ein paar Kilobyte groß ist).

Wenn, dann würde das clean/refresh am meisten am Ausgang vor der Soundkarte Sinn machen, also im Alsa oder Asio-Treiber. Da ja auch dort die Bits richtig sind (sonst würde man schnell Fehler hören) sollte dann dort das Verhalten der Speicherzellen die wesentliche Rolle spielen.

Ja, das mache ich auch in meinem Abspielprogramm; da wird auch ein Refresh gemacht, wenn die Samples in den Speicher des Audiotreibers geschrieben werden. Und zwischendrin mache ich das auch, etwa im Programm zum resamplen und in einem etwas veränderten brutefir.

Trotzdem klingen die verschiedenen Kopien auf der Festplatte unterschiedlich.

Viele Grüße,
Frank

[uli.brueggemann]

Was macht Uli denn anders?

Gute Frage. Unterschiedliche Betriebssysteme, unterschiedliche Entwicklungsumgebungen, unterschiedliche Programmiersprachen - schließlich geht es darum, das Betriebssystem eben nicht routinemäßig schreiben und cachen zu lassen. Daher sind bei Frank auch Teile in Assembler geschrieben z.B. für Intel-Rechner. Letzteres habe ich schon mehrfach angemerkt hier im Forum.

Dass Windows ein anderes Betriebssystem ist als Linux sollte sich ja herumgesprochen haben.
Und was ich da tue habe ich ja nicht versteckt. Bei den von mir angegebenen Links ist neben der exe-Datei ja auch die Quelldatei zu finden, so dass sich jeder das Programm anschauen kann. Und das dann eben mit Franks Programm vergleichen kann, das ebenfalls als Quellcode vorliegt und zwar nicht als Assemblercode. Wenn jemand Verbesserungsvorschläge hat (auch das sind Schläge), dann her damit.
Es werden also beim bufhrt Datenpakete der Größe 3072 Bytes in einen großen Puffer gelesen. Zuvor wird der Puffer an der Adresse des Datenpakets gecleant (Schreiben mit $FF und dann zweimal mit $0). Nach dem Lesen des Pakets aus der Quelldatei wird der Puffer dann dreimal refresht (Lesen und Negieren eines Bytes in ein CPU-Register, Schreiben von $0 im Puffer, Lesen und Negieren des Registers und Schreiben in den Puffer). Dann wird noch eine mehr oder weniger genau (eher weniger) funktionierende Zeitspanne "geschlafen" und zuletzt das Paket in die Zieldatei geschrieben. That's it.
Wo das Programm keinen Einfluß drauf hat: Verwendung CPU-Cache oder RAM, Weiterverarbeitung mit x-mal Zwischenspeichern (der write-Befehl auf die Festplatte löst einen Riesen-Rattenschwanz an Verarbeitungen aus, dabei werden die refreshten Datenpakete unkontrolliert vom Anwender hin- und hergeschoben, zwischenkopiert und z.B. von der Firmware der SSD irgendwohin verteilt). Und überhaupt: der RAM-Speicher als dynamischer Speicher wird durch den Memory-Controller unabhängig vom Betriebssystem sowieso ständig refresht, damit er nicht die Ladung verliert.

Was für mich am meisten logisch erscheint: das Refreshen müsste in dem Puffer stattfinden, wo die parallelen Daten serialisiert werden, also fürs Versenden per USB bzw. Ethernet. Das findet aber im Soundkartentreiber statt, der bei Windows üblich proprietär also unbekannt ist. Inwieweit das bei einem Alsa-Treiber klappt bedeutet ein tiefes Einsteigen in z.B. den generellen USB-Treiber für die Soundkarte.
Wenn der Treiber nicht zugänglich ist, dann kann das Refreshen zumindest unmittelbar davor stattfinden.

Was mir aber am wenigsten klar ist: es ist auch ein Herumstochern im Nebel. Braucht es das memclean und wenn ja wieviele? Muss man bei refreshen den Puffer zwischendurch zu Null setzen oder wäre es nicht besser denselben Wert mehrfach hintereinander reinzuschreiben. Oder ist zwischendurch das Setzen aller Bits dabei hilfreich? Auch hier wieviel und wie oft? Was bewirkt das Schlafen des Programms und wie lange/wie genau ist zwingend?

Ohne saubere Erklärung wird es eben mystisch, die Verschworungstheorie beginnt. ChatGPT hat hierzu übrigens auch keinen verwendbaren Wissensschatz.

Viele Grüsse
Uli

[tinnitus]

Hallo Frank,

ich habe nachgesehen welchen "Test" du gemacht bzw. beschrieben hast.

Dann der Hörtest: Ich habe mir die beiden Versionen der (bit-identischen) Dateien auf der gleichen Festplatte angehört - und sie klangen unterschiedlich! Im allgemeinen halte ich nicht so viel von ABX-Tests oder Ähnlichem. Aber in diesem Fall wollte ich doch sicher gehen, dass ich mir nichts einbilde. Ich habe daher per Zufallszahlengenerator die Kommandos zum Abspielen der beiden Dateien zwei Skripten A und B zuordnen lassen. Nach einmaligem Aufruf von A und B konnte ich immer sagen, welche Version welche ist (eigentlich wusste ich es sogar schon nach Aufruf von A). Das ganze habe ich mit 5 verschiedenen Stücken wiederholt und konnte es verlässlich reproduzieren. (Bei 4 der Stücke klang übrigens für mich die "verbesserte" Datei auch besser, bei einem war es andersherum.)

Warum hast du keinen verfügbaren ABX Test verwendet.

Kannst du dein Testprogramm allen zur Verfügung stellen, damit man den Hörtest machen kann?
Und bitte teile uns noch mit welche Voraussetzungen (Betriebssystem, Software, Stücke) für den Test noch verlangt werden.

Gruß Roland