Software-Experimente mit Linux

[frankl]

Hallo Forenten,

ich habe jetzt mal meine Audio-Software für Linux, über die in diesem Thread schon einiges diskutiert wurde, auf den neuesten Stand gebracht und ein neues Release gemacht (Version 0.8 ).

Die Programme sind jetzt in diesem github-Repository zu finden:

https://github.com/frankl-audio/frankl_stereo

Enthalten ist die Datei INSTALL mit deren Hilfe die Installation hoffentlich nicht so schwierig ist.

Auch die Webseite mit weiteren Informationen und Erklärungen habe ich aktualisiert. Von dort können alternativ die Programme der Version 0.8 als auch als Archiv heruntergeladen werden.

Stichpunkte zu den Änderungen in dieser Version sind in der Datei CHANGES aufgeführt.

Insbesondere gehört jetzt das Programm 'resample_soxr' zum Resamplen zur Sammlung, das hier im Forum schon verschiedentlich diskutiert wurde. Ich benutze das bei mir zum Lesen von Musikdateien, resamplen, für die Lautstärkeregelung und den RACE Effekt (die Funktionalitäten sind separat auch als 'cat64' und 'volrace' verfügbar).

Sonst hat sich im Prinzip an den vorher existierenden Programmen nicht viel geändert, es gibt kleinere Korrekturen und ein paar neue Optionen.

Klanglich am interessantesten ist vermutlich neuer Code zum 'refresh' von Daten im Arbeitsspeicher und in den CPU-Registern, den ich vor ca. 2 Jahren geschrieben habe. Hier habe ich insbesondere für zwei Architekturen etwas Assembler-Code geschrieben, um Compiler-"Optimierungen" zu umgehen: Das ist für x86_86, also PCs und andere Rechner mit Intel oder AMD CPU, und für aarch64, also neuere ARM Rechner wie Raspberry Pi 4.

Dieses 'refresh' wird in fast allen Programmen der Sammlung benutzt und hat in meinem Setup einen wichtigen Anteil am Klang beim Musik abspielen. Ich benutze auch eine veränderte Version des Convolver-Programms 'brutefir', das auf die Daten vor der Ausgabe ein 'refresh' anwendet.

Eine Anwendung des Programms 'bufhrt' ist in dem zur Sammlung gehörenden Skript 'improvefile' zu finden, mit dem Kopien von (Musik-)Dateien erstellt werden können. Ich benutze das seit Jahren, um die Musikdateien auf der SSD in meinem optimierten Audio-Rechner (zur Zeit ein Raspi 4 mit Farad-Netzteil und SSD hinter USB Regen) neu zu schreiben. Die kopierten Dateien klingen - für meine Ohren - so viel besser, dass das für mich ein wichtiger Baustein ganz vorne in der Wiedergabekette ist. Durch die erwähnten neuen Versionen der 'refresh' Routinen hat sich hier nochmal etwas getan. Aktuell gibt es hierzu auch Berichte anderer Forenten, etwa in diesen Beiträgen von Harald, Bernd Peter und Jürgen. Das Thema wurde hier im Forum schon ausführlich diskutiert, etwa in den Threads "Bit-identische Musik-Dateien auf derselben Festplatte" und "Rewrite Data".

Ach ja, die Programmsammlung enthält auch noch zwei experimentelle Programme 'clreg86' (für x86_64) bzw. 'clreg' (für aarch64), die -soweit ich das verstanden habe- etwas ähnliches wie 'MinorityClean' auf Windows-Rechnern machen. Ich starte das einmal auf jedem CPU-Core meines Audio-Rechners. Die Auswirkung ist nicht riesig, aber ich bilde mir ein, dass damit noch etwas mehr Ruhe in die Wiedergabe kommt.

Viele Grüße,
Frank

[Trinnov]

Hallo Bernd,
welchen Zeitaufwand erfordert die Beabeitung eines Albums etwa?

Viele Grüße
Martin

Hallo Martin,

bei mir sind das ca. 2 Minuten pro 44.1/16 Track
Ausgeführt mit dem kompakten DietPi Linux (ohne grafische Benutzeroberfläche) auf meinem optimierten Audio-PC.
Allerdings bei 2,0 GHz CPU Takt. Ich werde den Rechner noch etwas runtertakten, so dass es dann sicherlich noch länger dauern wird.
In den CPU Governor Einstellungen des DietPi ist das Einstellen möglich. Aber es greift (noch) nicht so, wie ich es möchte.

Das kleine DietPi, das ich vom Büro-PC aus per SSH Server Remote bediene, verbraucht verglichen mit einem großen grafischen Ubuntu sehr wenig Systemressourcen und dürfte die Files vermutlich noch etwas perfekter "improven".

Die Audio-Tracks werden auf den internen Datenträger improved. Das Linux ist auf einem USB Datenträger und wird nur bei Bedarf angesteckt.
Normal bootet ohne Bootstick meine Server 2016 Ramdisk. Dessen Bootblock befindet sich auf dem internen Datenträger und somit ist booten ohne den ursprünglich benötigten Ramdisk Bootstick möglich. Bei angestecktem Linux Datenträger bootet das DietPi und improved ausgewählte Tracks auf dem internen netzteilmäßig optimierten Datenträger auf dem sich auch das Windows OS (VHD) befindet. Ein praktikabler Workflow war mir sehr wichtig. Daher habe ich auch ein paar Tage beißen müssen, bis es so lief wie ich das wollte.
Eine DietPi Installation auf dem internen Datenträger geht nicht, da Grub4DOS einen Error meldet und das Ramdisk booten abbricht, sobald er die EXT4 Parttion des Linux sieht. Da ich mit einer USB-Stick Installation des DietPi dann auch Fehlermeldungen beim Linux booten hatte, habe ich kurzerhand eine kleine SLC Compact Flash Card genommen und diese über einen Cardreader per USB angesteckt. Damit funktioniert es perfekt. Eine 4 GB SLC CF Card reicht.

Der "Improve"-Effekt ist deutlich. Die Bühnentiefe / Bühnenstaffelung nimmt deutlich zu, bei Aufnahmen in denen dies aufnahmetechnisch vorhanden ist.
Obwohl ich vorher auch eine wie ich meinte gute Bühnentiefen-Darstellung hatte, ist es nach dem "improven" im Vergleich, wie wenn vorher alle Vögel nebeneinander auf einer Stange saßen. Jetzt gibt es etliche Einzelsitzplätze hintereinander / nebeneinander.

Viele Grüße
Horst

[frankl]

Hallo Horst,

schön zu lesen, dass Du das Diet-Pi Setup zum Laufen gebracht hast! Und es freut mich natürlich auch, dass Du den Effekt von 'improvefile' jetzt auch bei Dir nachvollziehen kannst. Deine Beschreibung mit den Vögeln ist nett und trifft es für mich ganz gut.

Die CPU-Rechenzeit des vom Skript aufgerufenen 'bufhrt' Programms ist übrigens sehr gering. Die Dauer des Kopierens hängt nicht von der CPU-Geschwindigkeit ab. In der Standardeinstellung des Skriptes aus meinem Repository wird ein großer Puffer beim Lesen der Daten gefüllt und dann wird in sehr genauem Takt 2000 Mal pro Sekunde ein Block von 3072 Bytes in die Ausgabedatei geschrieben. Das macht ca. 6MB pro Sekunde oder 368MB pro Minute.

Wie ich schon irgendwo erwähnt hatte, könnte man jetzt mit den Parametern herumspielen. Bei mir funktioniert die Standardeinstellung aber sehr gut und besser als andere Einstellungen, die ich probiert habe (nicht sehr viele).

Ich benutze bei mir ein Skript, das neu aufgespielte Dateien auf der SSD zuerst mit improvefile in eine RAM-Disk kopiert, dann die Originaldatei umbenennt, dann die Kopie in der RAM-Disk mit improvefile auf den Original-Dateinamen kopiert und am Ende die umbenannte Originaldatei löscht. (Eine Weile lang habe ich die Originaldatei nicht gelöscht zum Vergleichshören, aber das habe ich oft genug gemacht.)

Bei Feintuning des Diet-Pi könnten vielleicht auch einige Details etwas bringen, die ich auch auf meiner Webseite erwähne. Zum Beispiel, den bufhrt Prozess mit 'isolcpus=...' Boot-Parameter und 'taskset -c ...' auf einen exklusiven CPU-Core zu legen. Oder die CPU-Frequenz mit dem CPU governor "userspace" auf eine bestimmte Frequenz fest einstellen.

Viele Grüße,
Frank

[Fortepianus]

Hallo zusammen,

auch ich habe erfolgreich mit Improvefile experimentiert. Dafür zunächst mein ganz herzlicher Dank an Frank (frankl) für seine Programme und Harald (nihil.sine.causa) für die umfangreiche Unterstützung bei der Installation. Ich habe mich da bei Harald drangehängt, deshalb läuft das jetzt bei mir ganz ähnlich wie bei ihm:

- Ein eigens zu diesem Zweck angeschaffter und aufgesetzter NUC i5 mit 16GB RAM und einer internen M.2 SSD
- Auf der internen SSD läuft DietPi
- Der NUC ist runtergetaktet
- Die Versorgung erfolgt durch ein externes ziemlich kräftiges Linearnetzteil
- Dieses G-LNT hat zusätzlich einen 5V-Ausgang, der intern mit meiner Supercap-Technik mit Stromreglern ausgestattet ist
- An einem USB-Port des NUC hängt die zu behandelnde SSD, versorgt von diesen 5V
- Der NUC hängt über ein kurzes LAN-Kabel an einem LWL-Umsetzer, der ebenfalls von einem G-LNT versorgt wird
- Gesteuert wird der NUC i5 aus der Ferne von meinem Werkstattrechner mit dem Terminalprogramm MobaXterm

Ein Bild sagt mehr als 1000 Worte, aber derzeit kann man bei abload.de keine Bilder hochladen - weiß jemand, was dort los ist?
Ich habe bei abload.de eine E-Mail-Anfrage gestartet, aber bislang keine Antwort erhalten. Gruß, Rudolf

Meine Versuche (ermöglicht durch Harald) ergaben, dass man zwar schon einen deutlichen Klangfortschritt erzielt, wenn man Files auf der 8TB-Platte improved, aber der Genuss wird dann nochmal gesteigert, wenn man das auf einer SLC-SSD macht. Danke, Bernd Peter, für den Tipp.

Hallo Horst,

Der "Improve"-Effekt ist deutlich. Die Bühnentiefe / Bühnenstaffelung nimmt deutlich zu, bei Aufnahmen in denen dies aufnahmetechnisch vorhanden ist.
Obwohl ich vorher auch eine wie ich meinte gute Bühnentiefen-Darstellung hatte, ist es nach dem "improven" im Vergleich, wie wenn vorher alle Vögel nebeneinander auf einer Stange saßen. Jetzt gibt es etliche Einzelsitzplätze hintereinander / nebeneinander.

das ist bei mir ganz ähnlich. Zusätzlich bemerke ich noch eine verbesserte Transientenwiedergabe und eine Zunahme der Körperhaftigkeit. Ein Flügel steht da vorne in seiner natürlichen Ausdehnung, wenn die Aufnahme was taugt.

Der Wermutstropfen: Abgesehen vom Material- und Zeitaufwand muss man sich genau überlegen, welche Alben (die für die Insel) man in bestmöglicher Qualität möchte, denn 60GB sind ruckzuck voll. Aber auch die behandelten Alben von der großen Platte sind schon nicht schlecht. Wollte man aber die ganze Sammlung damit behandeln, wäre der Rechner damit ewig beschäftigt. Und bei weniger guten Aufnahmen lohnt sich der Aufwand nicht.

Aber schon interessant, dass bitidentische Dateien sogar von derselben SSD so unterschiedlich klingen können.

Viele Grüße
Gert

[Fortepianus]

Hallo Rudolf,

danke für die Anfrage. Ich habe jetzt Gabriels Hinweis

Vielleicht ist es Zeit für einen Wechsel?

https://picr.de/
Gibt es seit 20 Jahren.

umgesetzt und liefere hier das Bildchen nach, auf dem man die kleine Gerätesammlung für Roon und Improvefile sieht:



Das ist das Kabuff direkt hinter der Anlage, erreichbar über eine ausklappbare Treppe. Im Bild sieht man rechts hinten meine 8TB-SSD mit eigenem SCap-Netzteil und in der Mitte unten die SLC, die ebenfalls am Roon-NUC angeschlossen ist und vom schwarzen Linear-Netzteil links versorgt wird. Dazu habe ich jeweils ein USB-Kabel gemacht, bei dem die 5V aufgetrennt sind und extern eingespeist werden können.

Will man den Improve-Vorgang starten, stöpselt man eine der beiden Platten um auf den i5, schaltet den ein und kann dann über das Terminalprogramm damit arbeiten. MS-DOS lässt grüßen, aber mit etwas Übung klappt's. Die Installation auf dem i5 ist allerdings nichts für den DAU im IT-Bereich.

Viele Grüße
Gert

[Trinnov]

Hallo Frank,

vielleicht habe ich mich etwas falsch ausgedrückt.

Mit Fehlerkorrektur verbinde ich auch das Verfahren bei schlecht lesbaren Bits - Stichwort Signal Integrity - diese einer Überprüfung zu unterziehen.

Es grüßt

Bernd Peter

Hallo,
ich habe den Beitrag obigen Beitrag aus Bernds Vorstellungsthread aufgegriffen und möchte hier endlich mal etwas zu dem Mysterium sagen, weil das Thema eigentlich eher hierher gehört.

Der Artikel ist etwas länger geworden, aber vielleicht doch komplett lesen. Könnte gut zum Verständnis beitragen.

Mich stört etwas der Begriff "Fehler". Es gibt keine Fehler und es müssen auch keine korrigiert werden.

Die Audiodaten bleiben immer bitidentisch. Man kann sich ja die Protokollierung der erfolgten ECC Korrekturen des Datenträgers anschauen.
Das habe ich vor längerer Zeit mal gemacht. Meine SLC Industriedatenträger haben das Feature ECC Korrektur. Da gab es aber nichts zu korrigieren. ECC ist also ziemlich arbeitslos.

Statt von Fehlern zu reden, würde ich das als Zeitvariation bezeichnen. Uns ist es mit üblicher Messtechnik nicht möglich diese Zeitvariationen zu messen. Dafür benötigt man eine ultrapräzise und bis in den Femtosekundenbereich auflösende Messgerätezeitbasis, die zudem nur sehr gering jittern darf. Zudem ist auch noch der richtig Mess-Algorithmus erforderlich. Wer die falschen Parameter misst, wird nichts finden. Da habe ich schon sehr genaue Vorstellungen. Mir fehlt nur die entsprechend teure Messtechnik.

Man kann sich die Zeitvariationen im Audiodatenstrom im Vergleich vorstellen als wenn man eine lange Sinuswelle am Anfang und am Ende mit jeweils einer Hand festhalten könnte um den Schwingungsverlauf dazwischen durch Zusammenschieben und Strecken nach Belieben zu dehnen und zu stauchen würde. Exakt das passiert mit einem seriellen Signal. Verwendet wurde so etwas übrigens absichtlich bei unserem FM Rundfunk. Da wird tatsächlich eine Frequenzmodulation der Trägerwelle ausgeführt.

Zurück zur Computertechnik.
Die Datenintegrität bleibt trotz Zeitvariation in jedem Fall logischerweise immer erhalten. Das kann und darf auch nicht anders sein, sonst würde jeder Admin die Hände über dem Kopf zusammenschlagen aufgrund von zufälligen Datenfehlern. Als weitere datenkritische Beispiele möchte ich da die Rechner in Banken und auch beim Militär usw. nennen. Es kommen immer alle Daten korrekt an. Aber in der Zeitachse gibt es kleine Variationen.

Die Zeitvariationen liegen beim Auslesen des Datenträgers während des Track Abspielens möglicherweise nur im Femtosekundenbereich. Aber der Effekt ist, dass die richtigen Sample Daten zur falschen Zeit beim DAC ankommen. Das sind also keine falschen Daten sondern nur ein winziger Sample Audiopegel Shift in der Zeitachse und somit nach dem DAC eine minimal andere Audiosignalform. Warum soll das auch nicht hörbar sein. Wie hören ja auch klangliche Unterschiede von Clocks, die statt hervorragenden 50 Femtosekunden Jitter eben 500 oder 1000 Femtosekunden oder mehr jittern.
1000 Femtosekunden (fs) = 1 Pikosekunde (ps) = 0,001 Nanosekunden (ns) = 0,000001 Mikrosekunden (µs) = 0,000000001 Millisekunden (ms) = 0,000000000001 Sekunden.
Wer einen Kommafehler findet darf ihn behalten …

Die zeitlichen Variationen sind bei Audio deswegen so kritisch und somit hörbar, weil wir Stereo hören. Bei einer Wiedergabe eines einzelnen Kanals über einen einzigen Lausprecher ist das alles viel unkritischer, also kaum oder gar nicht wahrnehmbar.
Aber wir wollen die perfekte Stereo-Illusion. Die digitale Konserve soll den zum Zeitpunkt der Aufnahme vorhanden Aufnahmeraum mit allen seinen durch feinen Reflektion entstandenen Rauminformationen perfekt ins Wohnzimmer projizieren, als ohne das es von der Bühnentiefe und Staffelung her flach wirkt und vielleicht auch noch verwischt und nervig spielt.

Noch ein Bespiel zum Thema Zeitvariation:
Du erwartest vom Paketzusteller DHL 10 Pakete. Diese Pakete soll DHL bitte einzeln an 10 aufeinanderfolgenden Tagen exakt jeweils um 12 Uhr mittags auf die Sekunde genau ausliefern. Jetzt hat aber der Postbote auch noch etwas anderes zu tun, weil er auch noch andere Pakete ausliefern muss, oder telefonieren muss oder eine Pause macht usw. Du wirst dein Paket also nicht täglich exakt zur gleichen Zeit bekommen.
Aber da ist die Zeitvariation egal. Du wirst nach 10 Tagen deine 10 Pakete vollständig zuhause liegen haben. Bei Computerdaten würde man sagen, dass die Datenintegrität erfüllt ist.

So etwas passiert auch in einem Betriebssystem. Es schaut so aus, als ob Windows anscheinend alles gleichzeitig erledigt, weil es so rasend schnell geht. Aber das ist wie wir wissen nicht der Fall. Das ist immer eine sequentielle Abarbeitung.
Dein PC spielt also Audio aus. Gleichzeitig macht das OS im Hintergrund noch hunderte andere Sachen. Man schaue nur mal in den Ressourcenmanager von Windows. Diese vielen anderen Aufgaben stören aber die Zeitrichtigkeit der Audio-Daten beim Abspielen eines Audio-Tracks. Bringst du also das Betriebssystem dazu im Hintergrund so gut wie nichts anderes zu machen als Audio auszuspielen, wird es weniger Zeitvariationen im Audiodatenstrom geben. Deswegen sucht man auch eine Verbesserung des Audiodatenstroms, also eine Verringerung der Zeitvariation, indem man die Aufgabenbereiche auf jeweils einzelne CPU Cores aufteilt. Denn physikalische Kerne können tatsächlich zeitgleich Aufgaben abarbeiten. Suboptimal wird es aber schon wieder, weil sie sich teileweise physikalischen Speicher teilen müssen (z.B. L3 Cache und Arbeitsspeicher). Also auch nicht des Rätsels Lösung.
Das ist so wie wenn du für die zeitrichtige Zustellung von mehreren Paketen an dich mehrere DHL Mitarbeiter gleichzeitig beauftragst, diese sich aber ein Fahrzeug teilen müssen.

Sehr nützlich ist natürlich die Kombination der Ramdisk für das Betriebssystem und zusätzlich noch das „Abspecken“ des Systems, also reduzieren von Diensten und Prozessen.
Sobald sich das komplette OS im RAM befindet, gibt es auch keinen den Audiodatenstrom immens störenden, weil langsamen Datenaustausch mehr zwischen RAM und der Betriebssystem-SSD. Leicht beweisbar über den Windows Ressourcenmanager in z.B. Server 2016 Ramdisk Installationen.
Nicht vergessen zu erwähnen sollte man der Vollständigkeit halber natürlich die optimierten Netzteile der Audio-PCs. Insbesondere auch an der SSD ist der Einsatz eines top Netzteils immens hörbar. Datenflanken sind niemals unendlich steil. Deren Steilheit würde man als endlich bezeichnen. Es gibt also eine sogenannte Anstiegszeit. Jede nicht unendliche steile Flanke ist für über das Netzteil eingebrachten Noise empfänglich. Die Flanke wird mit dem Noise des Netzteils überlagert und somit variiert ein klein wenig die zeitlichen Position der Flanke. Die Auswirkungen sind wie gehabt.
Bei einer unendlich steilen Flanke (die nicht möglich ist) würde nur das Impulsdach mit Noise beaufschlagt, was dann für die Zeitrichtigkeit nicht von belang ist. Es zählt nur die Flanke.

Das i-Tüpfelchen darauf ist nun Franks geniales „File Improve“ Verfahren, weil somit auch die Zeitvariationen beim Auslesen des Audiotracks aus dem Datenträger während des direkten Musik Ausspielens oder dem vorab in den Arbeitsspeicher noch kleiner gemacht werden können.
Es geht also um den Flaschenhals von ansonsten bereits sehr gut optimierten Audio-PCs.

Da ich kein Speicherchip- bzw. Datenträger-Entwickler bin, kann ich nur vage Vermutungen anstellen, was da im Datenträger bei der „improved“ Datei anders ist, nachdem sie Franks Software sehr langsam mittels eines sehr „abgespeckten“ Linux Systems in die in Cluster aufteilten Speicherzellen geschrieben hat. Das sehr langsame Schreiben und Refreshen scheint mit entscheidend zu sein. Würde man den Schreibvorgang also das Schreiben der Kopie in den C_Improved Ordner nur sehr viel schneller erledigen und alle anderen Schreibparameter gleich halten, würde vermutlich bereits ein Großteil der klanglichen Vorteile verlorengehen.

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.

Man kann übrigens sehr sicher sagen, dass die beiden File Versionen (ich meine Franks Verfahren) absolut bitidentisch sind. Ich habe das kritisch mit dem Tool DeltaWave ohne vorheriges Matchen der beiden zu vergleichenden Files geprüft.

Trotzdem kenne ich mittlerweile 5 Personen mit sehr guten Hörfähigkeiten, die mir glaubhaft versichern, dass die beiden zueinander bitidentischen Audiofile Varianten unterschiedlich klingen. Also muss es da etwas geben, was noch nicht ausreichend erforscht ist.

Das DeltaWave Tool kann man kostenlos hier downloaden.
https://deltaw.org/

Viele Grüße
Horst

[tinnitus]

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

[uli.brueggemann]

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

[nihil.sine.causa]

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:

• 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.

Diese Beobachtungen weisen darauf hin, dass es um das Thema Zeitrichtigkeit geht, u.z. wie Horst sehr richtig sagt, ausschließlich bei Stereo-Aufnahmen.

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.

(Quelle: Hoeg und Steinke: Stereofonie-Grundlagen, Berlin 1972, S. 19)

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]

Hallo Uli,

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.

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?

Viele Grüße
Harald

[uli.brueggemann]

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?

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.
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]

Hallo Uli,

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.

da wie Gert bestätigt, es auf einer SLC SSD noch besser wird als auf einer üblichen MLC SSD.

Es grüßt

Bernd Peter

[uli.brueggemann]

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.

Hallo Bernd Peter,

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

[h0e]

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

[frankl]

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