Software-Experimente mit Linux

[nihil.sine.causa]

Hallo liebe Experimentierfreudige,

es gibt allerlei Neuigkeiten zum Thema Improvefile-Verfahren.

Zunächst hat Frank vor wenigen Tagen einige fundamentalen Änderungen publiziert. Insbesondere gibt es jetzt eine Option --number-copies=k von bufhrt im --interval Modus. Damit werden die Daten - ich sage mal mit meinen Worten - k-mal in einen separaten Bereich im RAM improvt, bevor die Daten (bei unserer Anwendung) auf den Datenträger geschrieben werden. Die Organisation der Daten im RAM hat Frank programmiert und nutzt dabei nicht die üblichen Filesysteme.

Es war also interessant, die neue --number-copies Option gegen unsere bisherigen RAM Verfahren zu testen. Mit Details will ich euch nicht aufhalten. Fazit ist: Was Frank hier gebaut hat, schlägt klanglich alle Improvement-Verfahren im RAM, wie wir es bisher gemacht habe. Daher habe ich mein Scriptset modifiziert, die neue --number-copies Option eingebaut und die bisherigen RAM-Optionen entfernt.

Unabhängig von dieser Änderung gibt es einige Verbesserungen in meinem Scriptset:

• Das Hauptscript ermittelt die Dateigrößen und prüft, ob der Datenträger genügend Speicherplatz für eine Bearbeitung besitzt. Die resultierenden Daten werden ausgegeben. Die Bearbeitung wird nur gestartet, wenn der Speicherplatz ausreicht. Sowohl das Hauptscript als auch das Steuerscript "nsc.sh" lassen sich mit der Option "-check" aufrufen. In diesem Fall wird lediglich eine Statusinfo über die Speicherinformation ausgegeben und keine Bearbeitung durchgeführt.
• Das Hauptscript kann nun so konfiguriert werden, dass bereits improvte Dateien aus dem Quellordner gelöscht werden. Die Steuerung dazu erfolgt mit der Variablen DELETE_SOURCE in der _config.txt Datei.
• Das Hauptscript kann jetzt gezielt mit dem Hilfsscript "nsc_kill.sh" abgebrochen werden. Dabei werden alle umount Befehle ordnungsgemäß ausgeführt. In Kombination mit DELETE_SOURCE=1 kann so die Bearbeitung jederzeit gestoppt und zu einem späteren Zeitpunkt wieder angestartet werden.
• Das Schreiben von Dateien ist – was das Timing betrifft – deutlich verbessert. Das betrifft insbesondere das Unmounten und Mounten des externen Datenträgers, um das Schreiben zu erzwingen.
• Im Fall von Bit-Identitätsverletzung wird das Improven bis zu 10 mal durchgeführt, bevor das Script abgebrochen wird. Die Settings werden nicht nur in die Log-Datei sondern auch in die _improved.txt auf dem Zieldatenträger geschrieben.

Das mag nach vielen Details klingen, aber in Summe ergibt sich ein für mich wichtiger Anwendungsfall, der den einen oder anderen von euch auch interessieren könnte. Ich speichere mittlerweile wichtige Musikdateien ("best of" musikalisch wie aufnahmetechnisch) auf spezielle Datenträger (z.B. SLC CF Karten). Natürlich möchte ich die Sammlung improven und weil mehrfaches Improven das Ergebnis verbessert, dies bei Gelegenheit immer wieder tun.

Hierzu gehe ich wie folgt vor: In einem ersten Durchlauf auf dem Datenträger aus dem Quellverzeichnis in das Zielverzeichnis improven. Danach ist das Quellverzeichnis geleert (sofern die automatisierte Datenlöschung eingeschaltet ist) und kann gelöscht werden. Nun benenne ich das Zielverzeichnis um und nutze es als neues Quellverzeichnis. Ich lege ein neues Zielverzeichnis an und starte den nächsten Durchlauf ggf. mit langsamem Improven.

Dieses Re-Improven kann ich durchführen, wann immer ich die betreffenden Datenträger nicht brauche. Auf diese Weise werden besonders gute Aufnahmen der Sammlung immer weiter verbessert.

Das veränderte SW-Paket steht wieder als Image für einen Boot-Stick bereit (Live-System, das per default nur im RAM arbeitet). Wer das probieren möchte (und sich noch nicht bei mir gemeldet hat) sollte mir eine kurze PN schicken.

Viele Grüße
Harald

[Bernd Peter]

Hallo Harald,

läuft perfekt, sehr gute Ergebnisse schon mit den default Werten.

Probiere das noch mit einem registered ECC RAM PC.

Es grüßt

Bernd Peter

[Fortepianus]

Hallo Harald,

auch bei mir ist eine deutliche Verbesserung zu hören. Die neue Möglichkeit, eine früher bereits bearbeitete Datei nochmal mit dem neuen Verfahren zu improven, habe ich mal mit einem ersten Album gemacht. Ein beachtlicher Zuwachs an Präzision und Raumabbildungsgenauigkeit ist das Ergebnis. Ich mache das nochmal ein bisschen anders: Ich verschiebe ein Album zur nochmaligen Bearbeitung einfach aus dem Ordner _IMPROVED nach _A_SOURCE - dabei werden ja keine Daten kopiert, was kontraproduktiv wäre, sondern es wird lediglich der Pfad zur Datei umbenannt. Ist im Grunde das Gleiche wie die Umbenennung des Ordners, nur muss ich so nicht den ganzen Inhalt von _IMPROVED neu rechnen lassen, sondern kann einzelne Alben rauspicken. So kann das Verfahren partiell erneut gestartet werden, und meine ziemlich volle SLC SSD dankt die Möglichkeit, mit dem neuen Parameter

DELETE_SOURCE=1

das Quellverzeichnis zu leeren, so dass man nur den zusätzlichen Platz auf dem Datenträger braucht, den der größte Einzelfile benötigt.

Danke für die hervorragende Arbeit an Dich und Frank!

Viele Grüße
Gert

[frankl]

Hallo Forenten,

hier auch von mir ein Update. Durch die Diskussion über 'improvefile' habe ich den letzten Wochen mal wieder meine Programme und auch die Skripte angeschaut, mit denen ich bei mir Musik abspiele. Nachdem ich da einige Jahre nicht viel dran geändert habe, war es interessant, viele Details kritisch zu hinterfragen und einige frühere Tests mit meinem jetzigen Setup zu wiederholen. Das hat zu einigen erfreulichen Verbesserungen bei mir geführt.

Unter anderem habe ich natürlich versucht, auch das 'improvefile' noch weiter zu verbessern. Dabei sei hier ruhig mal erwähnt, dass es etliche Versuche gab, die schließlich wieder verworfen wurden. Dabei haben die unermüdlichen und systematischen Tests von Harald, Horst und einigen anderen sehr geholfen! Vielen Dank dafür.

Es freut mich auch, dass der von Harald und Horst erdachte Boot-Stick zur Anwendung von 'improvefile' schon einigen anderen Forenten ermöglicht hat, das Konzept im eigenen Setup auszuprobieren.

Wer selbst einen Linux-Rechner hat, kann natürlich auch die Programme direkt aus meinem Repository runterladen oder aktualisieren und benutzen. Ich habe unter anderem das 'scripts/improvefile' Beispielskript aktualisiert, und einige Kommentare für Alternativen eingefügt.
Die Parameter sind so, wie ich sie im Moment auch für meine SSD verwende, außer dass ich das zugrunde liegende 'bufhrt' Programm noch mit 'taskset' auf einer isolierten CPU starte. Ähnlich zu den Berichten in den vorstehenden Beiträgen, ist die neueste Version auch bei mir eine merkliche weitere Verbesserung (so dass ich die Markierungen für bereits improvete Dateien gelöscht habe, damit alles vor dem nächsten Anhören nochmal improved wird).

Ich hatte in einem früheren Beitrag über den Vergleich von Musikdateien auf unterschiedlichen Filesystems (ext4, NTFS, VFAT usw.) berichtet. Horst hat noch viel gründlicher mit verschiedenen Filesystems und den möglichen Parametern, z.B. die Größe der verwalteten Blöcke, Versuche gemacht. Auch wurden unterschiedliche Methoden verglichen, Dateien im RAM abzuspeichern. Da hier alle möglichen Kleinigkeiten Einfluss auf den Klang der abgespeicherten Musikdateien haben, habe ich mir überlegt, wie man zumindest teilweise, diese Einflüsse eliminieren kann. Die oben erwähnte neue Option '--number-copies' von 'bufhrt' (und anderen Programmen) ersetzt jetzt zum Beispiel ganz mehrfache Aufrufe von 'improvefile' mit Dateien, die im RAM gespeichert sind (stattdessen wird eben zwischen Datenpuffern innerhalb des Programms kopiert, so dass gar keine Dateien und keine Filesystems benötigt werden.

Dann möchte ich noch eine Idee beschreiben, die zunächst mal nur in meinem eigenen Setup eingesetzt wird. Der Code dafür ist aber auch im aktuellen Repository enthalten. Und zwar habe ich mich gefragt, ob es nicht auch von Vorteil wäre, Musikdateien auf einem Speichermedium (SSD, Flashkarte,...) ohne Filesystem abzulegen, also den gesamten Overhead des Betriebssystems mit Verwaltung der Dateien (Inhalt und Metadaten), Cachen der Dateien im RAM, und Fragmentierung der Daten zu vermeiden. Klar, wenn die Daten von herkömmlichen Programmen etwa zum Abspielen der Musik gelesen werden sollen, dann geht das nicht. Die Dateien sind ja gerade dazu da, Daten zwischen Programmen austauschen zu können. Bei mir allerdings benutze ich meine eigenen Programme, um Musik abzuspielen, und denen kann ich beibringen, die Musikdaten auf andere Weise zu finden. Ich skizziere mal mein neues System, dass ich so wohl erstmal eine Weile benutzen werde.

Ich habe einen neuen Mini-Rechner (Odroid C4 statt Raspi 4), der eine schnelle eMMC Karte mit dem Betriebssystem hat und einen Einschub für eine interne MicroSD Karte. In letzterem steckt jetzt eine 64 GB SD Karte mit SLC Speicher. Diese SD Karte hat keine Partitionen und kein Filesystem! Ich habe ein Hilfsprogramm, mit dem ich (im Prinzip beliebige Dateien) Musikdaten darauf abspeichere. Die Daten werden in einen zusammenhängenden Adressbereich (also prinzipiell unfragmentiert) auf die Karte geschrieben. Um sie wiederzufinden merke ich mir, an welchem Speicherblock die Daten anfangen, wie lang sie sind, und ein paar Meta-Infomationen, die ich für Sample-Typ, Bittiefe und Samplerate nutze. Diese Information steht in einer einfachen Textdatei im Betriebssystem.
Neue Dateien werden einfach immer hinter die letzte geschrieben; wenn der restliche Platz auf der Karte nicht mehr groß genug ist, kommt die nächste Datei wieder an den Anfang. Alle schon gespeicherten Daten, die sich mit den neuen überschneiden würden, werden zuerst als gelöscht markiert. Auf diese Weise habe ich einen Puffer für ca. 50 Stunden hervorragend abgespeicherter Musik. Es versteht sich von selbst, dass das Programm zum Schreiben dieser Daten die gleiche Technik wie 'improvefile' benutzt. Im Hinblick auf die gleichmäßige Nutzung der Speicherzellen (wear levelling) wird die SD Karte so optimal genutzt. Meine Programme 'resample_soxr' und 'writeloop' können jetzt die Musikdaten aus diesem Container ohne Filesystem auslesen. Klanglich ist das nochmal ein ordentlicher Schritt vorwärts. Im Moment schreibe ich hauptsächlich vorgefaltete Daten auf die SD Karte, so dass der Rechner beim Abspielen fast keine Rechenzeit mehr braucht.

Viele Grüße,
Frank