Software-Experimente mit Linux

[frankl]

Hallo Uli,

hier ein paar Kommentare zur vorhergehenden Diskussion.

Im Deinem letzten Beitrag sehe ich, dass Du auf NTFS Dateisystemen (Windows) arbeitest. Ich erinnere mich, dass es ziemlich lange gedauert hatte, bis Linux die überhaupt lesen konnte und noch länger, bis darauf von Linux auch geschrieben werden konnte. Vielleicht liegt es auch an diesem Interface, dass Du so große Ausreißer beim Timing beobachtest (viel größer, als ich bei mir nachvollziehen kann - bei mir sind auf allen Datenträgern ext4 oder ext2 Dateisysteme).

Dein Schluss, dass nach Deinen Beobachtungen die highres-Timer in Linux Mist sind, ist nicht richtig. Dieses Thema hatten wir ja in diesem Thread schon früher diskutiert. Auf meinem Raspi 4 auf einem isolierten CPU Kern wachen fast alle nanosleeps mit (oft viel) weniger als 250ns Abweichung von der Zielzeit auf, und im Mittel über einige Sekunden mit 0ns. (Ich habe jetzt eine einfache Testschleife in 'highrestest' eingebaut, z.B. mit Argument '500' aufrufen.)

Die Version 0.3 Deines Programs hat das Problem, dass es von einem normalen Linux User nicht aufgerufen werden kann. Du setzt die Realtime (FIFO) Priorität, was normalerweise nur root erlaubt ist. So eine Priorität wird besser außerhalb des Programs gesetzt, die muss ja auch relativ zu anderen laufenden Prozessen gewählt werden. Ich mache das bei mir so, dass ich auf den Audiorechnern das SetUID Bit für 'chrt' setze (einmalig 'sudo chmod 4755 /bin/chrt'). Dann kann jeder User z.B. mit 'chrt -f 70 hrtfilecopy ....' Dein Programm starten. (-f 70 ist übrigens oft eine gute Wahl.)

Ich habe auch einen Hörvergleich, allerdings mit nur wenigen Dateien, gemacht. Dabei funktioniert 'hrtfilecopy' auch sehr gut, das Ergebnis ist ähnlich wie mit der bufhrt Version von vor Weihnachten. Einen großen Unterschied zwischen Version 0.1 und 0.3 konnte ich auf Anhieb nicht feststellen. Ach ja, der "match" ist auf meinem Notebook so 75-80% und auf dem Raspi 4 um die 90%

Viele Grüße,
Frank

[frankl]

Was passiert denn, wenn man für die Arbeit eurer Progamme einen Prozessorkern reserviert und/oder mit der Priorisierung der Prozesse spielt? Oder ist das schon in den Programmen berücksichtigt?

Viele Grüße
Jochen

Hallo Jochen,

dazu habe ich auf meiner Webseite auch ein paar Tipps aufgeschrieben. Am meisten bringt es meiner Erfahrung nach, Linux z.B. mit dem Boot-Parameter 'isolcpus=1,2,3' zu booten. Dann startet das System auf den Kernen 1,2,3 keine Prozesse, man kann aber explizit mit 'taskset -c 2 ...' Programme auf einem solchen Kern starten - bei uns natürlich die Audio-relevanten. Wenn man das macht, dann bringen verschiedene Prioritäten nichts mehr, weil auf den Kernen ja keine Prozesse in Konkurenz laufen. In meiner vorhergehenden Antwort an Uli habe ich aber einen Tipp gegeben, wie man Prozesse mit realtime-Priorität starten kann.

Viele Grüße,
Frank

[frankl]

Moin,

Was ich mich immer wieder frage: Überschreibt der automatisch laufende RAM refresh nicht sowieso alle Speicherzellen neu bevor die Bits an USB- oder Ethernet-Controller weitergegeben werden?

Ein weiterer Gedanke dazu: ich habe hier oft gelesen, dass kleinere Puffer am Ausgangstreiber bevorzugt werden. Bei kleineren Puffern von <32 ms (oder 64 ms, je nach Speicherchip) würden anteilig mehr Speicherzellen vor dem RAM refresh weitergegeben werden -- also im Originalzustand.

Beispiel: Bei einem Puffer von 4 ms werden alle im Schnitt 32 ms 4 ms Daten "RAM refreshed". Die anderen 28 ms Daten bleiben unangetastet.

Morgendliche Grüße,
Andree

Hallo Andree,

die DRAM Zellen im RAM werden, soweit ich das rausgefunden haben, ca. alle 64 ms refresh'ed, das Refresh einer RAM Zeile dauert wohl nur wenige ns, es ist also ziemlich unwahrscheinlich, dass ein Lese- oder Schreibzugriff zufällig genau mit so einem Refresh kollidiert (was wohl nur zu einer geringen Verzögerung führt). Im Allgemeinen habe ich keine große Angst, dass die regelmäßigen Refresh die "Qualität" (im hier diskutierten Sinn) der Daten im RAM stark verschlechtert, die stehen ja etwa bei mir beim Musik abspielen ca. 1 Stunde im Speicher. Allerdings will ich schon, dass die Daten möglichst zeitnah vor dem Schreiben auf den Datenträger (oder die Soundkarte beim Abspielen mit 'playhrt') mit meinen Routinen neu geschrieben werden. Am besten sollten Sie dabei in den L1 Cache passen (dieser und die Prozessor Register bestehen aus SRAM Zelllen, die ohne refresh auskommen).

Viele Grüße,
Frank

[frankl]

Hallo Forenten,

angeregt durch die hiesigen Diskussionen, habe ich meine Programme jetzt nochmal etwas überarbeitet und in mein Repository hochgeladen.

Als ich in 'bufhrt' die '--dsync' Option eingeführt hatte, fand ich das eine gute Verbesserung, da vorher nur das Betriebssystem mit seinen üblichen Algorithmen die Daten zum Datenträger geschickt hatte.

Die vorstehenden Diskussionen zu "delayed blocks" und Uli's Variante zeigen, dass dadurch leider das genaue Timing zum Schreiben der neuen Datei schwierig wird und recht stark von der verwendeten Hardware abhängt.

Ich habe jetzt 'bufhrt' so geändert, dass das Synchronisieren der geschriebenen Daten von der mit '--loops-per-second' gesteuerten Hauptschleife entkoppelt wird. Dazu gibt es jetzt den neuen Parameter '--dsyncs-per-second', der statt '--dsync' verwendet werden sollte. Dieser sollte üblicherweise deutlich kleiner als '--loops-per-second' sein. Wählt man zum Beispiel (wie in der neuesten Version von 'improvefile')

--loops-per-second=2000 --dsyncs-per-second=100

so kann die Hauptschleife in sehr gleichmäßigen Zeitabständen (ohne "delayed blocks") die Daten rausschreiben und wird dann nach je 20 Durchläufen unterbrochen für die Synchronisierung mit dem Datenträger. Bei mir funktioniert das so sehr gut mit sehr gutem Ergebnis. Wer möchte, kann es ja mal ausprobieren. (Wer schon eine Kopie meines Repository hat, macht darin einfach wieder 'git pull' und dann 'make REFRESH=X8664' zum Kompilieren.)

Außerdem habe ich mir noch Gedanken gemacht, ob man den Dateizugriff der zu lesenden und der neu zu schreibenden Datei irgendwie verbessern kann und dazu verschiedene Experimente gemacht. Herausgekommen ist dabei ein ganz neu geschriebenes Programm 'cleancp'. Das kann man einfach statt 'improvefile' z.B. so

Code: Alles auswählen

   cleancp  musik.flac improved.flac

aufrufen. Es hat noch zwei optionale Argumente, die ich aber erstmal nicht kommentiere; die Standardeinstellung ist vermutlich fast immer ziemlich gut.

Ich will hier nicht zu technisch werden. Die Hauptunterschiede zu 'improvefile' mit 'bufhrt' sind:

- Auf die Dateien wird nicht mit read und write zugegriffen, sondern diese werden über 'mmap' im Speicher abgebildet.
- Die Daten werden in Blöcken verarbeitet mit der systemweit festgelegten 'page size' (meist 4096 Bytes), die auch für die Verwaltung des Datei-Cache und an vielen anderen Stellen benutzt wird. So ein Block passt wohl immer in den L1-Cache und wird dort direkt vor dem rausschreiben mit 'memrefresh' bearbeitet.
- Die Blöcke der Ausgabedatei werden vor der Schleife komplett vor-allokiert.
- Die oben erwähnte Entkoppelung der Hauptschleife mache ich natürlich auch hier.

Die klangliche Auswirkung ist bei mir etwas anders als mit 'improvefile'. Mir gefällt es und es wird wohl bei mir 'improvefile' überflüssig machen. Auch das kann, wer möchte, gerne ausprobieren.

Viele Grüße,
Frank

[uli.brueggemann]

Uli, jetzt musst du noch die Möglichkeit einbauen die "Bytes per Second" im ulifileopt Script festzulegen.
Von Franks Software wissen wir schon eine Weile, dass je nach möglicher Transferrate des Datenträgers eine gewisser maximal möglicher Wert bei den "loops per second" beachtet werden muss, um "delayed blocks" vollständig zu vermeiden.

Hallo Horst,

zum Verständnis:
bufhrt benötigt die Angaben loopspersec und bytespersec
Es gilt dabei:

Code: Alles auswählen

chunksize = bytespersec / loopspersec
looptime = 1/ loopspersec

Nun kennt der normale Anwender ja nicht die Leistungsfähigkeit des Rechners, das zeigt sich ja später. Alle vier Parameter stehen in Zusammenhang, Man kann die Gleichungen passend umstellen.

Code: Alles auswählen

Messung looptime auf Basis der vorgegebenen chunksize
loopspersec = 1 / looptime
bytespersec = chunksize * loopspersec

Es braucht nur die chunksize als Vorgabewert. Damit ergibt sich abhängig vom gegebenen System die looptime und daraus schlussfolgern loopspersec und bytespersec.

Deine Screendumps zeigen übrigens, dass da immer noch eine max looptime von 163 ms vorkommt. Trotz Vorgabe einer langen Zeit von 90 ms. Warum da dann weitere 73 ms verzögert werden ...
Um es mal drastisch auszudrücken: wir verwenden einen highres-Timer (Nanosekunden), der laut Frank (viewtopic.php?p=234671#p234671) nun ja so sinnvoll ist. Und dann bekommen wir das Ergebnis, dass wir bei der gewünschten looptime um 73 MILLIONEN ! Nanosekunden daneben liegen

Wenn ich nun davon ausgehe, dass das eigentliche Schreiben auf der SSD mal grob übertrieben geschätzt 1 ms benötigt, dann findet das innerhalb der 163 ms statt. Das könnte am Anfang sein oder bei 25 ms oder in der Mitte oder ganz am Ende. Es gibt davor und danach noch irgendeine unbekannte Bearbeitungszeit durch die Linux-Treibersoftware und die Firmware. D.h. das Schreiben der Chunks findet trotz highres-Timer mit fast beliebigen nichtkonstanten Zeitabschnitten statt.

Grüsse
Uli

[uli.brueggemann]

Hallo Frank,

1.
da ich mit Windows arbeite habe ich nun mal NTFS-Laufwerke. Soweit ich weiss verwendet Hort zumindes exFAT, ist vielleicht aber auch nicht Linux kompatibel.

2.
wenn ich mit isolcpus das Programm auf einem Kern laufen lasse, ich habe darüber berichtet, muss ich ja das Programm per taskset aufrufen. Es kann ja nun sein, dass das Hochsetzen der Priorität bewirkt das nachfolgende IO-Prioritäten ebenfalls davon abgeleitet werden. Also habe ich mal mit der realtime-prio gespielt. Klar, dafür gibt es chrt.
Demzufolge müsste ich dann das Prog aufrufen mit z.B.

Code: Alles auswählen

taskset - c 3 chrt -f 99 hrtfilecopy

Was mir bisher so nicht untergekommen ist. Weisst Du es besser? Dann her damit. Insofern habe ich das mit der rt-prio testweise ins Programm genommen.
Unabhängig davon schätze ich dass zumindest alle extra Dietpi Installationen für dieses Programm als root rennen.

3.
Das hrtfilecopy sollte klanglich nicht anders sein als das bufhrt. An memclean und memrefresh ist nichts geändert (oder haben die Funktionen keine Wirkung?). Ebenfalls ist die Schleife zum Schreiben der Daten prinzipiell identisch, es werden dieselben Kommandos verwendet. Du kannst ja die chunksize und die looptime genauso vorgeben wie das bufhrt die aus loopspersec und bytespersec ermittelt.
Mein Ansatz ist doch nur das nachvollziehbar und lesbar zu machen.

Grüsse
Uli

[Trinnov]

Hallo Uli,

das Ergebnis gefällt mir erstmals bei deiner Software klanglich extrem gut.
Sehr saubere und ruhige Bühnenabbildung. Möglicherweise das beste double Improve, das ich bislang gehört habe. Aber vielleicht lohnt da die lange Durchlaufzeit (= kleiner "Bytes per second" Wert). Das müssen wir noch herausfinden.
Verglichen mit dem Original verwischt da jetzt nichts mehr. Sehr gute Präzision und Abbildungsruhe. Das Hören ist somit auch noch langzeittauglicher, einfacher ...

Hallo Uli,

du kannst schon mal den Sekt kalt stellen.

Viele Grüße
Horst

[h0e]

Hallo Uli,

du kannst schon mal den Sekt kalt stellen.

Viele Grüße
Horst

Hallo Uli,

nachdem Du anfangs besonders skeptisch warst hast Du es geschafft, ein wirklich sehr gut klingende Version zu schreiben.
Horst hatte einen Stick mit Files in etwa 20 unterschiedlichen Varianten dabei, Einfach improved, zweifach, mit Franks und Deiner letzen Version, mit der Ur-Version, und und und.
Wir haben da ettliches verglichen. Bei manchen Versionen ist der Unterschied eher klein. Deine letzte Version von Horst sorgssam und langsam auf einen USB Stick angewendet klang aber deutlich und ich glaube für alle Ohren einheitlich besser. Alle (8? ) Ohrenpaare waren hier von der deutlich besseren Bühenabbildung, bessere Detailauflösung und dem unanstrengterem Musikgenuss begeistert.
Das ist natürlich eine Momentaufnahme und wir gehen davon aus, dass die aktuelle Dynamik hier noch einige Erkenntnisse zutage fördert.

So sind wir gestern dem Punkt nachgegangen, ob die verwendete Rechnerhardware einen Unterschied macht.
Horst verwendet ja bekanntlich einen extrem aufwendig modifizierten Audio PC, mit dem er die Files improved hatte.
So hat Horst mit den identischen Einstellungen auf Bernd-Peters Laptop das selbe File improved und wir konnten erlauschen,
was die Hardware ausmacht. Leider muss man feststellen, dass auch dies ein Fakt ist, dass nämlich die Hardware hörbar ist.
Die Unterschiede sind jedoch eher klein und ein auf minderwertiger Hardware improvetes File allemal Klassen besser als das "Original".

To be continued...

Grüsse Jürgen

[Bernd Peter]

Hallo,

nun zum Bericht über das Samstagstreffen, das jedem der Teilnehmer nachhaltig in Erinnerung bleiben dürfte.

Beide Schwerpunkte des Treffens kamen aus Haralds Ecke: die grundsätzliche Beurteilung von analoger und digitaler Musikwiedergabe sowie die verbesserte Abspeicherung der digitalen Musikdaten - sprich das Improven.

Den Vorführpart beim Improven hat Horst übernommen, der zwischenzeitlich selbst sehr tief in der Materie verankert ist.

Haralds Wissen über analoge Studiotechnik stammt aus der Zusammenarbeit mit hauptberuflichen Toningenieuren und seinem Forscherdrang, wie er wohl Physikern zu eigen ist.

Das erworbene Studiotonband aus der guten alten Zeit wurde von Gert aufwändig modifiziert, man sollte somit wissen, dass die damaligen Benutzer die jetzige Wiedergabequalität - leider - nie kennenlernen durften. Und doch wurden damit die Masterbänder erstellt, was man nur mit größtem Respekt zur Kenntnis nehmen darf.

Abgespielt wurden am Samstag "alte" Masterbänder mit klassischer Musik (kleinere Streicherbesetzungen), die Harald über einen direkten Anschluss zwischen Tonband und AD/DA Wandler aus dem Hause Acousence auch sofort digital ausgeben konnte.

Samplingraten von 192, 96 und 48 im Links/Rechts- bzw. Mitte/Seite-Modus standen zur Auswahl.

Einen Aufbau dieser Art in dieser technischen Qualität wird es kaum ein zweites Mal geben.

Das Hörergebnis war - was analog/digital betrifft - eindeutig, bei der digitalen Wandlung kommt es zu Verlusten, die sich mMn vor allem in der Lebendigkeit und Natürlichkeit des Klangbildes zeigen.

Uneinig war man sich dagegen in der Wahl der besten Samplingrate, während der Mitte/Seite-Modus immer besser gegenüber dem üblichen Links/Rechts klang.

Als Resumee kann festgehalten werden, dass die alte Tontechnik immer noch ganz oben steht, aus vielerlei Gründen aber keine Zukunft im harten Musikgeschäft mehr haben kann.

Beim Vergleich der Improvefiles wurden das Original und 2-3 improvte Versionen vorgespielt und danach eifrig diskutiert, welche Variante für das weitere Rennen um den Gesamtsieg dabeibleiben durfte.

Das zog sich bei der Menge der Varianten natürlich hin, interessanterweise gab es aber am Schluß keine große Diskussion, was am besten abeschnitten hat.

Doppeltes Improven mit der neuesten Software von Uli konnte alle überzeugen.

Das bedeutet aber nicht, dass Franks Entwicklung da stark abfällt, allein die Originalversionen wollte keiner der Teilnehmer mehr länger hören.

Es grüßt

Bernd Peter

PS: ein besonderer Gruß an Dirk, der sich mit fundierten Wissen nahtlos in den Hörerkreis eingefügt hat

[frankl]

Hallo Forenten,

ich bin immer noch etwas erstaunt über das plötzliche Interesse an 'improvefile', das ich ja schon seit vielen Jahren nutze. Aber ich bin auch erfreut darüber, da das neue Interesse ja auch Ansporn ist, über weitere Verbesserungen nachzudenken.

Vielen Dank für die Berichte zu dem Treffen bei Rene, das war bestimmt eine tolle Veranstaltung.

Vielleicht darf ich zu den vorhergehenden Beiträgen noch herausstellen, dass hier nicht die Version von 'improvefile' in meinem Repository und Ulis Variante in Konkurenz antreten. Der Code, der die eigentliche Arbeit macht, ist ja nahezu identisch (Version meines Programms von vor Weihnachten); nur die Art wie die möglichen Parameter angegeben werden, ist unterschiedlich. Die vielen verglichenen Varianten, von denen berichtet wurde, unterscheiden sich durch verschiedene Wahlen dieser Parameter und die Anzahl der Iterationen des Verfahrens. Diese Parameter sind: Größe der Daten, die pro Sekunde geschrieben werden und mit wievielen Schleifendurchläufen (jeweils Block rausschreiben und an das Speichermedium schicken) pro Sekunde das gemacht wird. Wenn ich das richtig verstanden habe, wurde hier die Version, die die meiste Zeit benötigt, im Vergleich als Testsieger gekürt.

Ich habe inzwischen noch einige weitere Tests gemacht.

Dateisysteme

Ich habe mal eine microSD-Karte, von der die in meinem Setup abgespielten Dateien sehr gut klingen, in verschiedene Partitionen aufgeteilt und diese mit verschiedenen Dateisystemen formatiert: ext2, ext4, FAT32, NTFS, exFAT.
Hierbei habe ich festgestellt, dass Linux auf NTFS und exFAT nur Dateien schreiben kann, indem ein Programmlevel zwischen Nutzer und Betriebssystemkern zwischengeschaltet wird (FUSE Filesystem), während in den ersten drei Fällen ein Treiber im Betriebssytem direkt die Arbeit übernimmt.

Dann habe ich für einen Vergleich dieselbe Musikdatei von meiner SSD mit demselben improvefile Programm (also gleichen Parameters, ca 8MB/s) auf diese Partitionen (derselben Speicherkarte) kopiert. Bei Abspielen klang die Datei von NTFS tonal sehr merkwürdig, nicht besser als das Original. Auch vom simplen FAT32 hatte der Klang eine nervöse Komponente. Besser gefallen hat mir die Kopie vom exFAT, besser als das Original. Klar besser klangen die Dateien vom ext2 und ext4, die ich ja normalerweise bei mir nutze (zwischen ext2 und ext4 konnte ich keinen Unterschied ausmachen, das wollte ich schon seit Ewigkeiten immer mal ausprobieren).

Das ist natürlich nur ein Vergleich in meinem Setup, bei anderen, insbesondere wenn die Dateien am Ende von Windows oder einem ganz anderen Gerät abgespielt werden, fällt der vielleicht anders aus.

Parameter, die sehr wenig Daten pro Sekunde schreiben

Diese Vergleiche habe ich mit meinem neuen Programm 'cleancp' gemacht, das noch zwei optionale Parameter hat: die Anzahl der page size Blöcke (meist 4096 Bytes), die pro Sekunde rausgeschrieben werden und eine kleine Zahl, die bestimmt, wie häufig die Daten mit dem Datenträger synchronisiert werden sollen (0: jedes Mal, 1: nach je zwei Pages, 2: nach je 4 Pages, usw.). Ich habe die momentane Standardeinstellung (2000 Pages/Sekunde, zweiter Parameter 5, also nach je 32 Pages wird synchronisiert) mit der Extremeinstellung 100 Pages/Sekunde und nach je 2 Pages wird synchronisiert verglichen (da werden nur 400kB pro Sekunde geschrieben). Das Kommando ist also dann:

Code: Alles auswählen

cleancp datei kopie 100 1

Leider musste ich da feststellen, dass das Ergebnis in der langsamen Version auch bei mir hörbar noch besser wird. Wenn man es auf die Spitze treiben will, ist also Geduld gefordert.

Schießlich habe ich auch mit der langsamen Variante nochmal eine Datei auf die verschiedenen Dateisysteme kopiert. Dabei habe ich alle Kopien, auch auf NTFS, als besser als das Original empfunden.

Viele Grüße,
Frank

[Trinnov]

Hallo Frank,

es ist unbestritten, dass du der Entwickler der Software bist. Dir gebührt die Anerkennung.
Wenn du die Software nicht vor Jahren geschrieben hättest, müssten wir aktuell auf jeden Fall ohne File Improve hören. Der nicht unerhebliche Flaschenhals bestünde weiterhin.
Das möchte ich hier unbedingt nochmals in aller Deutlichkeit sagen.
Uli benutzt deine Software Idee im Detail etwas abgewandelt, aber er sagte ja schon selbst, dass er im Prinzip genau das gleiche macht wie du und es deswegen identisch klingen müsste.
Das sehr langsame Schreiben der Datei macht möglicherweise einen Teil des Unterschieds aus.

Ich habe mittlerweile ganz gut verstanden wie ich die Loops / Blöcke bzw. Loop time und Block Größe sowie Bytes per Second hin und her multiplizieren und dividieren kann. Somit kann ich noch ein paar konkrete Tests fahren, um vielleicht doch noch etwas mehr Licht ins Dunkel zu bringen.

Deine beiden neuen Software Versionen habe ich bisher nur mit den Default Einstellungen genutzt. Bei cleancp ging das ja eh nicht anders.
Ich glaube aber, dass auch da die Einstellungen, insbesondere die Schreibgeschwindigkeit ein Thema bleiben werden.
Das tatsächliche Potential lässt sich somit möglicherweise nur herauskitzeln, wenn die Parameter jeweils an den Ziel-Datenträger angepasst werden.
Desweiteren stellt sich mir die Frage ob langsames Beschreiben vielleicht immer einen klanglichen Vorteil bringt auch wenn es sich um einen Datenträger mit hoher R/W Performance geht.

Delayed blocks treten im aktuellen bufhrt, wie du sagst, nicht mehr auf. Kann man das sicher für alle gängigen Datenträger sagen?
Ich fände trotzdem Indikatoren also z.B. weiterhin die Ausgabe bei delayed blocks oder andere Infos hilfreich, um nicht nur auf das Vergleichshören beschränkt zu sein. Bei den delayed blocks würden mir auch Punkte reichen, so wie Uli das macht. Somit bekommt man viel Information in einer Zeile. Man bekommt sehr schnell eine Aussage, ob man im korrekten Timing schreibt um notfalls den Durchlauf zwecks Parameteranpassung abbrechen.

Viele Grüße
Horst

[Schorsch]

Hallo Frank,

ich bin immer noch etwas erstaunt über das plötzliche Interesse an 'improvefile', das ich ja schon seit vielen Jahren nutze. Aber ich bin auch erfreut darüber, da das neue Interesse ja auch Ansporn ist, über weitere Verbesserungen nachzudenken.

Klasse, dass Du dieses Thema hier schon vor Jahren eingebracht hast und jetzt so unaufgeregt weiterverfolgst. Good things take time.

Hallo Horst,

es ist unbestritten, dass du der Entwickler der Software bist. Dir gebührt die Anerkennung.
Wenn du die Software nicht vor Jahren geschrieben hättest, müssten wir aktuell auf jeden Fall ohne File Improve hören. Der nicht unerhebliche Flaschenhals bestünde weiterhin.

Bin froh, dass Du das in dieser Klarheit schreibst. Ich betrachte uns als ein Forum mit Qualitätsansprüchen und dazu gehören Quellenangaben - insbesondere von Ideen und Umsetzungen.

Euch allen - Frank, Horst, Harald, Uli, Daniel, Gert, Bernd-Peter, ... Danke fürs Improven von improvefile.

Viele Grüße
Georg

[Bernd Peter]

Hallo,

weiter geht es:

Schallereignisse werden physikalisch in der Hauptsache durch drei Größen charakterisiert:

• Die Frequenz oder Tonhöhe des Tonsignals in Schwingungen pro Sekunde in Hertz (Hz) angegeben
•
• Die Intensität oder der Schalldruckpegel des Tonsignals, zumeist in Dezibel (dB) angegeben
•
• Der zeitliche Verlauf von beiden

Wichtig für uns ist hier das zeitliche Auflösungsvermögen unseres Hörsinns, womit Richtung und Entfernung des Schallereignisses in Zusammenhang stehen.

Der eigentliche Vorteil eines hochauflösenden Digitalsignals mit hohen Abtastraten liegt nicht primär in der Erweiterung des Übertragungsbereichs, sondern erst ein sekundärer Effekt bringt den entscheidenden Vorteil.
Je höher die Übertragungsbandbreite eines technischen Übertragungssystems, desto besser sein zeitliches Auflösungsvermögen.

Und damit kommt nun das Improven ins Spiel.

Es grüßt

Bernd Peter

[uli.brueggemann]

Der eigentliche Vorteil eines hochauflösenden Digitalsignals mit hohen Abtastraten liegt nicht primär in der Erweiterung des Übertragungsbereichs, sondern erst ein sekundärer Effekt bringt den entscheidenden Vorteil.
Je höher die Übertragungsbandbreite eines technischen Übertragungssystems, desto besser sein zeitliches Auflösungsvermögen.

Und damit kommt nun das Improven ins Spiel.

Hallo Bernd-Peter,

das solltest Du mir (bzw. uns) dann doch mal näher erläutern. Ralf begründet den Sinn hoher Abtastraten damit, dass sich die zetiliche Auflösung verbessert. Wir hören ja nicht wirklich Fledermausfrequenzen.

Nun wird beim "improven" ja nicht hinsichtlich der Abtastraten beeinflußt, eine 44/16 Datei bleibt eine 44/16 Datei. Wie ich nun schon öfter aufgezeigt habe ist der als verbessernd vermutete Ansatz, die Daten gleichmäßig getaktet zu schreiben, ja nicht so wirklich gleichmäßig. Das Betriebssystem macht da quasi seine eigene Bielebigkeit damit. Wenn das Schreiben von 4096 Bytes z.B. 1 ms dauert dann könnten gleichmäßig 1000 loops/s stattfinden. Wenn dann eine Zeitmessung ergibt, dass im schlechtesten Fall der Loop aber 150 ms dauert, ist man nun genötigt zumindest größere Zeittoleranzen zu akzeptieren indem man z.B. 90 ms looptime vorgibt (siehe Beispiel Horst). Das entspricht dann nur noch 11.1 loops/s.
Der niedrigere Parameter bedeutet aber nun nicht, dass das Schreiben nun 90 ms dauert. Es wäre prinzipiell weiterhin ca. 1 ms. Oder irgendwas Beliebiges zwischen 1 ms und 90 ms. Wenn dann trotzdem 150 ms vorkommen, dann ist das Zeitraster auch dahin.
Das improven macht also mit der Nanosekundenclock nichts anderes als den Beginn des Schreibens gleichmäßig anzustossen. Ob es genau dann stattfindet und wie lage es dann dauert ist ausser Kontrolle. Es könnte z.B. ab real ab 78 ms beginnen und 8 ms dauern und ist dann immer noch im gültigen Raster von 90 ms.

Und mir ist da nun wirklich nicht klar, wie das improven damit das zeitliche Auflösungsvermögen des Musiksignals beeinflußt.

Viele Grüsse
Uli

[Trinnov]

Hallo Uli,

du hast natürlich recht. Das Improven verbessert nicht das zeitliche Auflösungsvermögen des Musiksignals. Aber das hat Bernd eigentlich auch gar nicht so behauptet.

Warum ich jetzt aber auf deinen Beitrag schreibe.
Du bringst mein Beispiel. Sehr langsamer USB Datenträger.
Automatik deaktiviert. Sehr hohe loop time (ms) händisch gewählt = top Ergebnis.
Die Frage ist, warum ist das Ergebnis top.
Vorab muss ich sagen, dass mir in der Findungsphase der optimalen Einstellungen die vielfältigen Ausgaben deiner SW sehr gut gefallen.
Absolut top

Für mich steht fest, dass viele Loops (Blöcke) pro Sekunde für die Improve Klangqualität sehr schlecht sind. Punkt.
Bei dem genutzten Datenträger kann ich erst bei ca. 15 oder weniger loops/s delayed blocks vermeiden.
Mir ist aktuell noch nicht einmal klar ob man mit einem schnellen Datenträger die Loop time ohne Klangeinbußen stark verkürzen darf.
Das wird man testen müssen.
Jetzt könnte man natürlich annehmen dass das Vermeiden von delayed blocks direkt mit dem konfigurierten Datendurchsatz (bytes/s) zusammenhängt.

Ja und nein
Ich habe nun nämlich einen weiteren Test gemacht.
Präferierter Durchsatz ca. 182.000 bytes/s ergibt ein top improve Ergebnis. Siehe Veranstaltung.
Das kann erreicht werden mit 11,1 * 16384 (Blockanzahl * Blockgröße) oder auch mit 22,2 * 8192
Interessanterweise erzeugt letztere Konfiguration bei gleichem Datendurchsatz nun deutlich mehr delayed blocks.
Das Timing ist also schlechter und somit klingt diese Variante auch schlechter. Ich habe mir das angehört.
Vermutlich sind große Blocks (chunk size) nicht klangschädlich. Viele loops/s hingegen schon, weil sie dem Timing schaden.

Was ich oben schon geschrieben hatte. Du zeigst viele Daten im Ausgabefenster. Interessant ist die maximal entstandene loop time. Sind das 150ms, sollte man dies möglicherweise respektieren und die Konfiguration entsprechend anpassen. 1000/150 = 6,67 Loops
Der Datenträger oder der Rechner ? verträgt anscheinend nicht mehr als 6,67 loops/s um im perfekten Timing zu bleiben. Also wähle ich gleich nicht mehr als 150ms (6,67 loops) und passe die Blockgröße an, um weiterhin mindestens 182000 bytes/s zu schreiben. Mit 6 loops/s bleibt man sicher im Timing.
6 * 32768 bytes = 196.000 bytes/s Das werde ich mir anhören müssen.

Ich verwende mittlerweile folgendes Stück um die Qualität des Improvens auch am Büro PC sicher beurteilen zu können.
https://www.youtube.com/watch?v=wexdQ2g5mcU

Die Violinen werden extrem schnell gespielt und ohne File Improve steige ich schnell aus, da sehr anstrengend. Chaotisch!

Improve ich den mir in 44.1/16 zur Verfügung stehenden Track aber, benötigt das Hören mit der besten Improve Variante keine Konzentration. Selbst beim Abhören über den Büro PC. Es ist sogar entspannend. Man kann dem Stück sehr einfach folgen.
Andere Imrove Varianten spielen noch mehr oder weniger nervös.

Um den Vorteil des Improvens einschätzen zu können, benötigt man mit obigem Stück nicht mehr als 3 Sekunden.
Würde man z.B. den Track "Liberty" zum Beurteilen verwenden, benötigt das ein Vielfaches der Zeit.
Die Bach Aufnahme ist für diesen Zweck definitiv ein Glücksfall.


Viele Grüße
Horst