Hallo Uli,
die enorme Verbesserung durch das Improven kann ich mir nur in Zusammenhang mit exacterem Timing erklären.
Wenn aus einem bisherigen Klang eine Mehrzahl von Einzelklängen heraushörbar werden, wenn die Klänge sauber getrennt im Raum stehen ohne an Schärfe zuzulegen, dann dürfte das mit einer Verbesserung der Auslesequalität zu tun haben, die sich in Zeitkorrekturen im Nanobereich äußert, welche unser Gehörsinn erstaunlicherweise wahrnehmen und verarbeiten kann.
Das technisch nachvollziehbar zu begründen muss ich schuldig bleiben.
Es grüßt
Bernd Peter
Software-Experimente mit Linux
-
Bernd Peter
- Aktiver Hörer
- Beiträge: 4007
- Registriert: 04.05.2010, 19:37
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Wir haben beim Improven nicht unmittelbar ersichtlich ebenfalls zwei Partner im Spiel. Ich nenne sie mal Erzeuger und Verbraucher, also E und V.
E bekommt irgendwo Daten her und speichert sie auf der Festplatte. Dort könnten sie Jahre liegen, solange sich nichts dran ändert liegt ein status quo vor. Bis dann irgendwann V kommt und die Daten verwendet, in unserem Fall also um Musik draus zu machen.
Wenn es nun neben der Korrektheit der Daten um das Timing geht, so wissen wir, dass zumindest beim Lagern der Daten das Timing keine Rolle spielt. Es findet statt zum Schreiben und beim Auslesen. Dazwischen aber ist das Timing definitiv nicht vorhanden und vergessen. Wir können die Daten auch zeitlich völlig unanhängig voneinenader schreiben und lesen, um einen beliebigen Faktor x unterschiedlich im Tempo oder in der genauen Taktung.
Wir können so ja auch alle dasselbe Buch lesen, der eine in einer Nacht und der andere über ein paar Wochen gestreckt.
Was aber auch klar sein sollte: in unserem Fall erzeugt E eine strikt geordnete Folge an Informationen und V muss auch dieselbe Reihenfolge beibehalten. Wenn nun z.B. E die Zahlen 1 bis 100 in einzelnen Schächtelchen sortiert hintereinander ins Regal legt (mit beliebigem Timing) kann V sie auch prima mit einem sauberen Takt wieder herausnehmen. Sie liegen ja geordnet. Würde E die Schachteln beliebig verteilen hat V mehr Aufwand und muss jeweils suchen (Stichwort Adventskalender). Damit wäre der unmittelbare kontinuierliche Verarbeitungstakt gestört.
Die logische Schlussfolgerung: man muss dafür sorgen, dass eine kontinuierliche Reihenfolge der Daten vorliegt. So dass es ohne Sucherei möglich ist, sie zu verwenden. Das wird genau dann möglich, wenn zwischen E und V noch ein Dritter mitspielt. Den nennen wir praktischerweise Sortierer oder S.
Wann S arbeitet ist eigentlich egal, solange es so rechtzeitig passiert, dass V eben sein Timing präzise einhalten kann.
Ich sehe nun das Thema improven klar so, dass anscheinend S bereits tätig wird, wenn die Schächtelchen ins Regal abgelegt werden resp. die Daten auf die Platte geschrieben werden. In unserem Fall immer noch ein bisschen problematisch, als dass S nicht die volle Kontrolle hat, was das "Regal" tut (sprich OS odder SSD-Firmware).
Prinzipiell könnte S aber auch wirksam werden wenn V die Daten verarbeitet. Die Schachteln werden von E beliebig abgelegt, S ordnet und übergibt an V eben dann korrekt.
Gibt es kein S kütt et wie et kütt. V taktet eben wahrscheinlich weniger genau.
Natürlich haben da auch schon andere drüber nachgedacht. Insofern sei als Beispiel als Player das JRiver Mediacenter genannt. Da weiss ich genau, dass ich da vorgeben kann dass der komplette Musiktrack in den Speicher gelesen wird. Dann könnten die Daten auf der Festplatte ungeordnet liegen, spätestens im Speicher wäre eine Ordnung drin. Fals jemand den Gedanken hat dass nicht, dann könnte das improve ja auch nicht sauber schreiben, es verwendet ja ebenfalls den Speicher..
Und dann kann V die Daten sauber getaktet rauslesen mit wahrscheinlich sauberem Timing aufgrund der Ordnung und der kurzen Zugriffszeit.
In Fachchinesisch heisst das übrigens Pufferung. Und wir haben ja mehrfach Zwischenpuffer, sei es im Player, in der ASIO-Ausgabe (ALSA macht bestimmt auch nicht Bit für Bit), im USB-Datenpaket, im Ethernet-Datenpaket usw.
Und so würde mich sehr interessieren ob entsprechende Puffer in der Wiedergabekette nicht den einen Puffer ganz am Anfang (=Festplatte) konterkarieren.
Unabhängig davon wird das Geschehen durch weitere Faktoren beeinflußt, welche sich aber dann auch zufällig verhalten. Werkeln x Prozesse parallel bei der Wiedergabe so verändern sie das Echtzeitverhalten der Datenausgabe. Und das nicht nur hinsichtlich der Zuteilung von Zeitscheiben durch das Betriebssysten sondern auch hinsichtlich Konkurrenz bein Zugriff auf dieselben Ressourcen, z.B. Speicher. Und natürlich gibt es auch noch die Möglichkeit der Beeinflussung durch HF-Noise, der sich ausgehend von einer nichtidealen Masse im System ausbreitet und wiederum Schwellwerte in der Schaltungslogik beeinflusst, sprich Timing.
Ich rätsel insofern immer noch herum, wieso sich das "improven" durch die ganze komplexe Wiedergabekette bin nach hinten auswirken können soll.
Es sei denn V macht unmittelbar aus den "ungeordneten" Daten ein direktes i2s-Signal, was aber eher weniger der Fall sein dürfte.
Grüsse
Uli
PS: für sachdienliche Hinweise die zur Aufklärung des Falles führen fragen wir am besten nicht den Arzt oder Apotheker. Sie sind aber immer willkommen ... die Hinweise
E bekommt irgendwo Daten her und speichert sie auf der Festplatte. Dort könnten sie Jahre liegen, solange sich nichts dran ändert liegt ein status quo vor. Bis dann irgendwann V kommt und die Daten verwendet, in unserem Fall also um Musik draus zu machen.
Wenn es nun neben der Korrektheit der Daten um das Timing geht, so wissen wir, dass zumindest beim Lagern der Daten das Timing keine Rolle spielt. Es findet statt zum Schreiben und beim Auslesen. Dazwischen aber ist das Timing definitiv nicht vorhanden und vergessen. Wir können die Daten auch zeitlich völlig unanhängig voneinenader schreiben und lesen, um einen beliebigen Faktor x unterschiedlich im Tempo oder in der genauen Taktung.
Wir können so ja auch alle dasselbe Buch lesen, der eine in einer Nacht und der andere über ein paar Wochen gestreckt.
Was aber auch klar sein sollte: in unserem Fall erzeugt E eine strikt geordnete Folge an Informationen und V muss auch dieselbe Reihenfolge beibehalten. Wenn nun z.B. E die Zahlen 1 bis 100 in einzelnen Schächtelchen sortiert hintereinander ins Regal legt (mit beliebigem Timing) kann V sie auch prima mit einem sauberen Takt wieder herausnehmen. Sie liegen ja geordnet. Würde E die Schachteln beliebig verteilen hat V mehr Aufwand und muss jeweils suchen (Stichwort Adventskalender). Damit wäre der unmittelbare kontinuierliche Verarbeitungstakt gestört.
Die logische Schlussfolgerung: man muss dafür sorgen, dass eine kontinuierliche Reihenfolge der Daten vorliegt. So dass es ohne Sucherei möglich ist, sie zu verwenden. Das wird genau dann möglich, wenn zwischen E und V noch ein Dritter mitspielt. Den nennen wir praktischerweise Sortierer oder S.
Wann S arbeitet ist eigentlich egal, solange es so rechtzeitig passiert, dass V eben sein Timing präzise einhalten kann.
Ich sehe nun das Thema improven klar so, dass anscheinend S bereits tätig wird, wenn die Schächtelchen ins Regal abgelegt werden resp. die Daten auf die Platte geschrieben werden. In unserem Fall immer noch ein bisschen problematisch, als dass S nicht die volle Kontrolle hat, was das "Regal" tut (sprich OS odder SSD-Firmware).
Prinzipiell könnte S aber auch wirksam werden wenn V die Daten verarbeitet. Die Schachteln werden von E beliebig abgelegt, S ordnet und übergibt an V eben dann korrekt.
Gibt es kein S kütt et wie et kütt. V taktet eben wahrscheinlich weniger genau.
Natürlich haben da auch schon andere drüber nachgedacht. Insofern sei als Beispiel als Player das JRiver Mediacenter genannt. Da weiss ich genau, dass ich da vorgeben kann dass der komplette Musiktrack in den Speicher gelesen wird. Dann könnten die Daten auf der Festplatte ungeordnet liegen, spätestens im Speicher wäre eine Ordnung drin. Fals jemand den Gedanken hat dass nicht, dann könnte das improve ja auch nicht sauber schreiben, es verwendet ja ebenfalls den Speicher..
Und dann kann V die Daten sauber getaktet rauslesen mit wahrscheinlich sauberem Timing aufgrund der Ordnung und der kurzen Zugriffszeit.
In Fachchinesisch heisst das übrigens Pufferung. Und wir haben ja mehrfach Zwischenpuffer, sei es im Player, in der ASIO-Ausgabe (ALSA macht bestimmt auch nicht Bit für Bit), im USB-Datenpaket, im Ethernet-Datenpaket usw.
Und so würde mich sehr interessieren ob entsprechende Puffer in der Wiedergabekette nicht den einen Puffer ganz am Anfang (=Festplatte) konterkarieren.
Unabhängig davon wird das Geschehen durch weitere Faktoren beeinflußt, welche sich aber dann auch zufällig verhalten. Werkeln x Prozesse parallel bei der Wiedergabe so verändern sie das Echtzeitverhalten der Datenausgabe. Und das nicht nur hinsichtlich der Zuteilung von Zeitscheiben durch das Betriebssysten sondern auch hinsichtlich Konkurrenz bein Zugriff auf dieselben Ressourcen, z.B. Speicher. Und natürlich gibt es auch noch die Möglichkeit der Beeinflussung durch HF-Noise, der sich ausgehend von einer nichtidealen Masse im System ausbreitet und wiederum Schwellwerte in der Schaltungslogik beeinflusst, sprich Timing.
Ich rätsel insofern immer noch herum, wieso sich das "improven" durch die ganze komplexe Wiedergabekette bin nach hinten auswirken können soll.
Es sei denn V macht unmittelbar aus den "ungeordneten" Daten ein direktes i2s-Signal, was aber eher weniger der Fall sein dürfte.
Grüsse
Uli
PS: für sachdienliche Hinweise die zur Aufklärung des Falles führen fragen wir am besten nicht den Arzt oder Apotheker. Sie sind aber immer willkommen ... die Hinweise
Linux
Hallo zusammen
Also mit Logik scheint man dem Thema wirklich schwer beizukommen. Irgendwas fehlt uns da, um es zu verstehen.
Habe eine Frage:
Finde das Thema sehr spannend. Bin aber leider total dumm im Thema Linux. Wird es vielleicht irgendeine Möglichkeit geben, dass der Vorgang auch für Noobs umsetzbar ist? Vielleicht sowas wie ein bootfähiges Image, mit einer Art GUI darauf, oder was Explorer-ähnliches, nur zum "richtigem" kopieren? Unter Windows ist es gar nicht machbar?
Gruß
Stephan
Also mit Logik scheint man dem Thema wirklich schwer beizukommen. Irgendwas fehlt uns da, um es zu verstehen.
Habe eine Frage:
Finde das Thema sehr spannend. Bin aber leider total dumm im Thema Linux. Wird es vielleicht irgendeine Möglichkeit geben, dass der Vorgang auch für Noobs umsetzbar ist? Vielleicht sowas wie ein bootfähiges Image, mit einer Art GUI darauf, oder was Explorer-ähnliches, nur zum "richtigem" kopieren? Unter Windows ist es gar nicht machbar?
Gruß
Stephan
Hallo,
hm, nach meinem laienhaften Verständnis ist es doch so, dass, wenn eine Datei auf einen Datenträger D geschrieben werden soll, der dafür zuständige Teil des OS nachschaut, wo Platz für diese Datei auf D ist. Und wenn es sich nicht um eine kleine Datei handelt, dürfte die in in aller Regel gestückelt auf D gelagert werden, weil in aller Regel schon recht viel auf dem viel genutzten D rum- und damit im Weg liegt. Wenn ich die Datei also am Stück auf dem Datenträger ablegen möchte, dann geht das am besten auf einem neuen, noch nicht genutzten D. Dann sollten doch die Dateien in der Reihenfolge, wie sie angeliefert werden, am Stück nacheinander abgelegt werden können. Wie beim Laden in den RAM. Frage: Ist meine Erinnerung korrekt? Dann nächste Frage: Was macht dann das improven zusätzlich? Sorry, wenn ich den Thread jetzt nicht mehr en detail nachverfolgt habe.
Viele Grüße
Jochen
hm, nach meinem laienhaften Verständnis ist es doch so, dass, wenn eine Datei auf einen Datenträger D geschrieben werden soll, der dafür zuständige Teil des OS nachschaut, wo Platz für diese Datei auf D ist. Und wenn es sich nicht um eine kleine Datei handelt, dürfte die in in aller Regel gestückelt auf D gelagert werden, weil in aller Regel schon recht viel auf dem viel genutzten D rum- und damit im Weg liegt. Wenn ich die Datei also am Stück auf dem Datenträger ablegen möchte, dann geht das am besten auf einem neuen, noch nicht genutzten D. Dann sollten doch die Dateien in der Reihenfolge, wie sie angeliefert werden, am Stück nacheinander abgelegt werden können. Wie beim Laden in den RAM. Frage: Ist meine Erinnerung korrekt? Dann nächste Frage: Was macht dann das improven zusätzlich? Sorry, wenn ich den Thread jetzt nicht mehr en detail nachverfolgt habe.
Viele Grüße
Jochen
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo Jochen,
Das improven hat übrigens darauf keinerlei Einfluss, die Fragmentierung macht nicht das OS sondern die Firmware.
Bei einer neuen Festplatte sollte es unfragmentiert zugehen. Eine Neuformatierung hilft dagegen nicht. Ein Defragmentieren funktioniert, erzeugt aber wiederum neue Löcher.
Grüsse
Uli
Demzufolge wird immer auf einen leeren Platz geschrieben. Wo genau entscheidet nicht das OS sondern die Firmware der SSD. Bei einer neuen Platte möglicherweise dann sequentiell. Werden nun aber auch mal Dateien gelöscht ist das zuerst kein wirkliches Löschen. Das passiert anscheinend irgendwann später. Und wenn, dann entstehen auch Löcher. Ich habe gerade in den letzten Tagen ein komplettes Re-Install eines Rechners mit OS und Programmen gemacht. Mittlerweile zeigt mir der Defraggler, dass von 634 GB belegtem Platz 19.7 GB fragmetiert sind. Damit gibt es also eine Fragmentierung.https://www.ibm.com/docs/en/zos/2.5.0?topic=data-writing-erasing-hdd-versus-ssd hat geschrieben:
When you write to a data set that resides on a hard disk drive (HDD), whatever data that previously existed is replaced with the new write data. Data written to HDDs is saved in fixed-size sectors and these sectors can be rewritten repeatedly. When you delete a data set or release space, the data remains accessible on the HDD. The only way to prevent access to residual data on HDDs is to overwrite the sectors.
Solid state drives (SSD) work differently. The media is arranged in fixed-size (4 kilobyte) pages, and pages are grouped into blocks. Writes are only permitted to a blank page. Pages can never be overwritten. When you write a flash device, the device must allocate a new blank page for the new data. The new page is noted as the current location in the logical block address (LBA) table. The original page is marked as invalid.
When you delete a data set, the data remains accessible on the SSD. You might overwrite with zeros; however, this would result in a potentially large data transfer and cause the device to allocate additional pages. This is not desirable because flash devices have a finite number of “program/erase” (P/E) cycles before they need to be replaced.
Flash drives provide an UNMAP command which is a more efficient solution to prevent access to residual data. UNMAP is a SCSI command that mark pages as invalid. It requires no allocation of SSD pages and zero data transfer. By marking the pages as invalid, they cannot be read by any program running under control of an IBM operating system.
Periodically, the device erases an entire block of invalid pages which makes these pages available for new writes.
Das improven hat übrigens darauf keinerlei Einfluss, die Fragmentierung macht nicht das OS sondern die Firmware.
Bei einer neuen Festplatte sollte es unfragmentiert zugehen. Eine Neuformatierung hilft dagegen nicht. Ein Defragmentieren funktioniert, erzeugt aber wiederum neue Löcher.
Grüsse
Uli
Hallo Ulli,uli.brueggemann hat geschrieben: ↑09.01.2024, 18:31 Werden nun aber auch mal Dateien gelöscht ist das zuerst kein wirkliches Löschen. Das passiert anscheinend irgendwann später.
das stimmt zumindest für Linux-Dateisysteme (ext). (Wenigstens war das früher so, ich denke aber, dass es immer noch so ist.) Denn das Löschen in dem Umfeld beschränkt sich zunächst auf das Löschen des Verweises auf die Daten im "Inhaltsverzeichnis". Die Daten selbst sind davon zunächst nicht betroffen.
Edit: Und ich meine mich zu erinnern, dass die Daten auch nicht explizit gelöscht werden, sondern bei Bedarf einfach überschrieben werden.
Viele Grüße
Jochen
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Was mir gerade noch zu meinem vorherigen Beitrag einfällt: es ist völlig egal wie der Zeitverlauf war um ein Buch zu schreiben. Wenn mir vorgegeben wird, dass ich das Buch gleichmässig in einer bestimmten Zeit lese, sollten natürlich Buchstaben, Sätze und Kapitel in der richtigen Reihenfolge stehen.
Grüsse
Uli
Grüsse
Uli
Linux
Hallo zusammen
So hatte ich es irgendwann mal gelernt. Bei einer HDD oder SSD bestimmt der Controller, wo geschrieben wird. Früher bei HDDs war es doch noch Gang und Gebe, sie zu de-fragmentieren, damit größere Dateien an einem Stück geschrieben werden können, und nicht mehrmals zerteilt dort, wo noch Platz ist. Wie kann es ein externes Kopiertool diesen Umstand ändern ? Oder arbeiten die Controller heutzutage anders ?
Bei SSDs erinnere ich mich, das diese nicht de-fragmentiert wurden, da die Blöcke nur eine bestimmte Anzahl an Schreibvorgängen an Lebensdauer haben. Werden nicht auch defekte Blöcke "markiert" und umgangen ? Vielleicht ist auch der Denkansatz falsch, um die Lösung zu finden.
Gruß
Stephan
So hatte ich es irgendwann mal gelernt. Bei einer HDD oder SSD bestimmt der Controller, wo geschrieben wird. Früher bei HDDs war es doch noch Gang und Gebe, sie zu de-fragmentieren, damit größere Dateien an einem Stück geschrieben werden können, und nicht mehrmals zerteilt dort, wo noch Platz ist. Wie kann es ein externes Kopiertool diesen Umstand ändern ? Oder arbeiten die Controller heutzutage anders ?
Bei SSDs erinnere ich mich, das diese nicht de-fragmentiert wurden, da die Blöcke nur eine bestimmte Anzahl an Schreibvorgängen an Lebensdauer haben. Werden nicht auch defekte Blöcke "markiert" und umgangen ? Vielleicht ist auch der Denkansatz falsch, um die Lösung zu finden.
Gruß
Stephan
Hallo Jochen,
bei Flash-Speichern, etwa SSDs, arbeitet das Betriebssystem zwar formal mit einem zusammenhängeden Stück Speicher und verwaltet dieses, aber das ist nur eine Abstraktionsstufe. Welche Speicherzellen zu einem Stück virtuellen Speichers gehören, entscheidet der Controller und das ändert sich auch, wenn Daten überschrieben werden - das Betriebssytem sieht davon nichts. (Das ist ein echtes Problem, wenn Daten aus Sicherheitsgründen physikalisch gelöscht werden sollen, was bei einer klassischen Festplatte durch Überschreiben möglich war.)
Deswegen gibt es das Konzept der Fragmentierung hier im Grunde gar nicht mehr. Aber auch bei älteren Festplatten, waren die Fragmente immer so groß, dass das auch da im Zusammenhang mit 'improvefile' meiner Meinung nach völlig irrelevant war.
Viele Grüße,
Frank
bei Flash-Speichern, etwa SSDs, arbeitet das Betriebssystem zwar formal mit einem zusammenhängeden Stück Speicher und verwaltet dieses, aber das ist nur eine Abstraktionsstufe. Welche Speicherzellen zu einem Stück virtuellen Speichers gehören, entscheidet der Controller und das ändert sich auch, wenn Daten überschrieben werden - das Betriebssytem sieht davon nichts. (Das ist ein echtes Problem, wenn Daten aus Sicherheitsgründen physikalisch gelöscht werden sollen, was bei einer klassischen Festplatte durch Überschreiben möglich war.)
Deswegen gibt es das Konzept der Fragmentierung hier im Grunde gar nicht mehr. Aber auch bei älteren Festplatten, waren die Fragmente immer so groß, dass das auch da im Zusammenhang mit 'improvefile' meiner Meinung nach völlig irrelevant war.
Viele Grüße,
Frank
Hallo Stephan,SolidCore hat geschrieben: ↑09.01.2024, 17:56
Habe eine Frage:
Finde das Thema sehr spannend. Bin aber leider total dumm im Thema Linux. Wird es vielleicht irgendeine Möglichkeit geben, dass der Vorgang auch für Noobs umsetzbar ist? Vielleicht sowas wie ein bootfähiges Image, mit einer Art GUI darauf, oder was Explorer-ähnliches, nur zum "richtigem" kopieren? Unter Windows ist es gar nicht machbar?
auf die Frage zu einer Version für Noobs hatte ich ein paar Seiten vorher schonmal etwas geschrieben. Das Problem ist, das unterschiedliche Leute sehr unterschiedliche Setups haben. Bei dem hier diskutierten Verfahren müssen ja die Musikdateien an dem Rechner angeschlossen sein, der das "improven" machen soll. Wer von einem Audiorechner mit Musik-Festplatte abspielt, ist da grundsätzlich schon mal in einer guten Position. Auch wenn man eine NAS benutzt, die oft intern sowieso ein Linuxrechner ist, könnte das improvefile direkt darauf laufen. Wenn die Daten aber auf irgendeinem Streamer mit Festplatte liegen, worauf man nur mit einem proprietären Benutzerinterface zugreifen kann, ist unklar, wie man vorgehen kann.
Im Prinzip müsste man, was Dir vorschwebt in einige der bekannten Benutzerinterfaces zum Musik abspielen als zusätzliche Funktion einbauen können. Aber das muss halt jemand machen, der sich mit dem jeweiligen Interface auskennt. (Ich gehöre nicht dazu und benutze auch kein solches Programm.)
Viele Grüße,
Frank
Hallo Frank,
zunächst einmal vielen Dank für deine Ausführungen. Jetzt nur eine Frage, aus notabene reiner Neugier: Wie umgehen deine/eure Tools das Problem des offenbar eigenständig handelnden Controlers? Der lässt dann doch wohl letztlich auf den Datenträger schreiben, oder? Ich bin zu wenig Programmierer als dass ein Blick auf euren Code mir helfen könnte.
Viele Grüße
Jochen
Hallo Jochen,
das Speichermedium mit seinem Controller ist sozusagen eine Black Box, die man so nehmen muss, wie sie ist. Auf die interne Arbeit hat man vom Betriebssytem aus keinen Einfluss. (Ähnlich wie elektronische Bauteile, die in einer Schaltung gerade gut passen oder eben nicht.)
Entsprechend gibt es ja noch die Nebendiskussion, welche Speichermedien besonders gut geeignet sind (solche mit SLC Flashzellen, die nur ein Bit speichern, scheinen allgemein für unsere Zwecke hier von Vorteil zu sein).
Im Prinzip könnte es auch sein, dass ein bestimmtes SSD Modell für uns besonders geeignet ist, im Internet finden sich auch Berichte über Klangvergleiche verschiedener SSDs. Das ist dann natürlich reiner Zufall, da SSDs nicht für optimalen Klang entwickelt werden, sondern auf schnelles Schreiben und Lesen und billige Herstellung oder lange Lebensdauer oder spezielle technische Anforderungen hin optimiert werden.
Viele Grüße,
Frank
das Speichermedium mit seinem Controller ist sozusagen eine Black Box, die man so nehmen muss, wie sie ist. Auf die interne Arbeit hat man vom Betriebssytem aus keinen Einfluss. (Ähnlich wie elektronische Bauteile, die in einer Schaltung gerade gut passen oder eben nicht.)
Entsprechend gibt es ja noch die Nebendiskussion, welche Speichermedien besonders gut geeignet sind (solche mit SLC Flashzellen, die nur ein Bit speichern, scheinen allgemein für unsere Zwecke hier von Vorteil zu sein).
Im Prinzip könnte es auch sein, dass ein bestimmtes SSD Modell für uns besonders geeignet ist, im Internet finden sich auch Berichte über Klangvergleiche verschiedener SSDs. Das ist dann natürlich reiner Zufall, da SSDs nicht für optimalen Klang entwickelt werden, sondern auf schnelles Schreiben und Lesen und billige Herstellung oder lange Lebensdauer oder spezielle technische Anforderungen hin optimiert werden.
Viele Grüße,
Frank
Hallo Frank,
verstehe ich es dann so richtig: Eure Programme sortieren die Daten so neu, dass sie für die Musikwiedergabe optimal sortiert sind, vorausgesetzt der Conroler des verwendeten Datenträgers spukt euch nicht in die Suppe? Dann wären eben Datenträger optimal, deren Controler nicht für sonstige Speicherzwecke optimiert sind, sondern entspannt die von euch angelieferten optimierten Daten "durchrutschen" lassen? Dann hätte man ja eine Erklärung auch dafür, warum der eine Hörer das Resultat anders wahrnimmt als ein anderer Hörer und/oder die Programme unterschiedliche Werte auswerfen? Liegt dann nicht nur an den eigenen Controlern namens Gehör, sondern auch am Zufall des verwendeten Datenträgers und seines Controlers?
Viele Grüße
Jochen
verstehe ich es dann so richtig: Eure Programme sortieren die Daten so neu, dass sie für die Musikwiedergabe optimal sortiert sind, vorausgesetzt der Conroler des verwendeten Datenträgers spukt euch nicht in die Suppe? Dann wären eben Datenträger optimal, deren Controler nicht für sonstige Speicherzwecke optimiert sind, sondern entspannt die von euch angelieferten optimierten Daten "durchrutschen" lassen? Dann hätte man ja eine Erklärung auch dafür, warum der eine Hörer das Resultat anders wahrnimmt als ein anderer Hörer und/oder die Programme unterschiedliche Werte auswerfen? Liegt dann nicht nur an den eigenen Controlern namens Gehör, sondern auch am Zufall des verwendeten Datenträgers und seines Controlers?
Viele Grüße
Jochen
Hallo Jochen,
Um ein Sortieren der Daten geht es wohl eher nicht. Nach den bisherigen Erkenntnissen klingen die Files dann am besten, wenn wir keine Abbrechen beim Schreiben bekommen. Dazu müssen die Daten je Datenträger entsprechend langsam in Blöcken geschrieben werden.
Dazu kommt das SLC nur 1 Bit (quasi 0 oder 1) und moderne QLC sogar 4 Zustände in einer Zelle speichern, man hat also 4 Spannungslevel, die sauber geschrieben und gelesen werden müssen. Spannend bleibt auch, ob durch die Flüchtigkeit der Spannungslevel das Improveergebnis evtl. über die Zeit verloren geht.
Grüsse Jürgen
Grüsse Jürgen
Um ein Sortieren der Daten geht es wohl eher nicht. Nach den bisherigen Erkenntnissen klingen die Files dann am besten, wenn wir keine Abbrechen beim Schreiben bekommen. Dazu müssen die Daten je Datenträger entsprechend langsam in Blöcken geschrieben werden.
Dazu kommt das SLC nur 1 Bit (quasi 0 oder 1) und moderne QLC sogar 4 Zustände in einer Zelle speichern, man hat also 4 Spannungslevel, die sauber geschrieben und gelesen werden müssen. Spannend bleibt auch, ob durch die Flüchtigkeit der Spannungslevel das Improveergebnis evtl. über die Zeit verloren geht.
Grüsse Jürgen
Grüsse Jürgen
-
uli.brueggemann
- Aktiver Hersteller
- Beiträge: 4663
- Registriert: 23.03.2009, 15:58
- Wohnort: 33649
- Kontaktdaten:
Hallo Jürgen,
wie die Daten letztendlich auf der SSD landen ist nicht unter unserer Kontrolle. Letztlich hoffen wir es.
Und wie ich versucht habe zu schildern kommt es letztlich darauf an dass beim Lesen der Daten der Datenfluß möglichst kontinuierlich und ungestört stattfindet. Dabei ist es egal, ob der Track in Millisekunden oder über einen Monat geschrieben wurde. Hauptsache beim Auslesen fliesst es schön.
Das wäre ja dann der Fall wenn die Daten sauber hintereinander liegen. Was prinzipiell ja auch eine Sortierung ist. Klarer wird das am Beispiel einer Fragmentierung wo die Daten beliebig verteilt sein können. Bei der guten alten Festplatte wird in der file allocation table nachgeschaut und dann bewegt sich der Lesekopf zur entsprechenden Stelle. Was eben unterschiedlich dauert. Nun erwartet man das bei der SSD nicht so, es gibt aber evtl. ständig irgendwelche Adressänderungen. Und wir schauen hier ja immer nur auf die Daten selbst. Der SSD-Controller muss ja auch die Adresstabellen mitpflegen und für die gilt das wear leveling ja genauso. Insofern sind auch diese Tabellen nicht ortsfest. Was da wirklich stattfindet bleibt das Geheimnis der SSD-Hersteller.
Da die Daten ja beim Vergleich zwischen Original und impreoved identisch sind spielen Spannungslevel eher weniger die Rolle, allenfalls wiederum beim Timing.
Wenn nun eine nicht optimale Datei durch das improven verbessert wird, ist das ja derzeit unabhängig davon, wann die verbesserte Datei gespielt wird. Das kann jetzt, heute oder auch morgen der Fall sein. Würde diese Datei in den Specher gelesen, kann auch dieser wieder irgendwann verwendet werden. Wenn es dann bitgenau ist kommt es nur auf das Timing des Auslesens an. Und genauso wie das mehrfache Improven logisch eine Stufe nach der anderen ist, kann dann auch noch später im Speicher improved werden. Für mich gibt es kein Argument dagegen. Also, Datei komplett in den Speicher einlesen und später (was auch immer das ist) eben an den DAC weitergeben. Natürlich sollte das dann wiederum "geordnet" stattfinden. Auch beim Speicher kennt man eine Fragmetierung.
Grüsse
Uli
wie die Daten letztendlich auf der SSD landen ist nicht unter unserer Kontrolle. Letztlich hoffen wir es.
Und wie ich versucht habe zu schildern kommt es letztlich darauf an dass beim Lesen der Daten der Datenfluß möglichst kontinuierlich und ungestört stattfindet. Dabei ist es egal, ob der Track in Millisekunden oder über einen Monat geschrieben wurde. Hauptsache beim Auslesen fliesst es schön.
Das wäre ja dann der Fall wenn die Daten sauber hintereinander liegen. Was prinzipiell ja auch eine Sortierung ist. Klarer wird das am Beispiel einer Fragmentierung wo die Daten beliebig verteilt sein können. Bei der guten alten Festplatte wird in der file allocation table nachgeschaut und dann bewegt sich der Lesekopf zur entsprechenden Stelle. Was eben unterschiedlich dauert. Nun erwartet man das bei der SSD nicht so, es gibt aber evtl. ständig irgendwelche Adressänderungen. Und wir schauen hier ja immer nur auf die Daten selbst. Der SSD-Controller muss ja auch die Adresstabellen mitpflegen und für die gilt das wear leveling ja genauso. Insofern sind auch diese Tabellen nicht ortsfest. Was da wirklich stattfindet bleibt das Geheimnis der SSD-Hersteller.
Da die Daten ja beim Vergleich zwischen Original und impreoved identisch sind spielen Spannungslevel eher weniger die Rolle, allenfalls wiederum beim Timing.
Wenn nun eine nicht optimale Datei durch das improven verbessert wird, ist das ja derzeit unabhängig davon, wann die verbesserte Datei gespielt wird. Das kann jetzt, heute oder auch morgen der Fall sein. Würde diese Datei in den Specher gelesen, kann auch dieser wieder irgendwann verwendet werden. Wenn es dann bitgenau ist kommt es nur auf das Timing des Auslesens an. Und genauso wie das mehrfache Improven logisch eine Stufe nach der anderen ist, kann dann auch noch später im Speicher improved werden. Für mich gibt es kein Argument dagegen. Also, Datei komplett in den Speicher einlesen und später (was auch immer das ist) eben an den DAC weitergeben. Natürlich sollte das dann wiederum "geordnet" stattfinden. Auch beim Speicher kennt man eine Fragmetierung.
Grüsse
Uli