Rewrite Data

[Ohrpfropf]

Hallo miteinander,
seit ca. zwei Wochen gibt es neben den Playern (Audioplayer Bug Head Emperor) noch ein Tool auf der Seite zum Download: "Rewrite data", momentan als Version 1.16. Hat außer mir damit schon Erfahrungen? Interessantes Teil: Laut Yokota soll es den Jitter der involvierten Laufwerke reduzieren (mein Englisch ist allerdings nicht so gut). Wie das funktionieren soll bzw. funktioniert ist mir unklar, aber es verändert die Qualität der Wiedergabe, und das gilt auch für andere Player als den Bug Head (z. B. Foobar). Die jetzige Software bietet die Optionen entweder die Player zu "rewriten" oder die Musikdaten. Ersteres zeigt bei mir keine große Wirkung, Letzteres dagegen schon. Bei einem Neustart des OS muss das Prozedere immer wiederholt werden(?). Beim Start des Tools öffnet sich ein Datei-Browser, in dem man zum betreffenden Musikordner wechseln kann.
Der Effekt lässt sich gut nachvollziehen:
- Im bevorzugten Player Dateien laden und abspielen,
- Rewrite data starten, dort dieselben Dateien auswählen,
- Playerwiedergabe stoppen (nicht pausieren),
- Dateien von Rewrite data bearbeiten lassen,
- Playerwiedergabe wieder starten.
Klingt jetzt anders ... Ob das beim Abspielen von Dateien, die auf dem selben Laufwerk wie der Player liegen auch Auswirkungen zeigt, habe ich nicht getestet. Bei mir liegen die Dateien auf einem separaten LW.
Grüße,
Lutz

[Bernd Peter]

Hallo Lutz,

Gordon spricht in diesem Zusammenhang von "non temporal instructions".

Das hat lt. google mit dem L1, L2 und L3 Cache zu tun.

Könnte sein, daß diese auf bypass gestellt werden.

Frank schrieb dazu in einem anderen Zusammenhang:

.....dass beim Transport von Daten noch ein bis drei Level von Cache-Speicher mitspielen, die intern anders funktionieren.

Ist aber alles nur eine Vermutung.

Gruß

Bernd Peter

[frankl]

seit ca. zwei Wochen gibt es neben den Playern noch ein Tool auf der Seite zum Download: "Rewrite data", momentan als Version 1.13. Hat außer mir damit schon Erfahrungen? Interessantes Teil: Laut Yokota soll es den Jitter der involvierten Laufwerke reduzieren (mein Englisch ist allerdings nicht so gut). Wie das funktionieren soll bzw. funktioniert ist mir unklar, aber es verändert die Qualität der Wiedergabe, und das gilt auch für andere Player als den Bug Head (z. B. Foobar). Die jetzige Software bietet die Optionen entweder die Player zu "rewriten" oder die Musikdaten. Ersteres zeigt bei mir keine große Wirkung, Letzteres dagegen schon. Bei einem Neustart des OS muss das Prozedere immer wiederholt werden(?). Beim Start des Tools öffnet sich ein Datei-Browser, in dem man zum betreffenden Musikordner wechseln kann.
Der Effekt lässt sich gut nachvollziehen:
- Im bevorzugten Player Dateien laden und abspielen,
- Rewrite data starten, dort dieselben Dateien auswählen,
- Playerwiedergabe stoppen (nicht pausieren),
- Dateien von Rewrite data bearbeiten lassen,
- Playerwiedergabe wieder starten.
Klingt jetzt anders ... Ob das beim Abspielen von Dateien, die auf dem selben Laufwerk wie der Player liegen auch Auswirkungen zeigt, habe ich nicht getestet. Bei mir liegen die Dateien auf einem separaten LW.

Hallo Lutz, hallo Forenten,

was Du hier beschreibst, klingt nach einem Überschreiben der Musikdateien auf der Festplatte.
Warum ein dadurch bewirkter Effekt durch Reboot des Rechners hinfällig werden soll, erschließt sich mir nicht.

Andererseits habe ich einen Blog-Eintrag des BHE-Autors gefunden, in dem sich "Rewrite data" auf Musikdateien bezieht, die schon im RAM liegen. Da werden die Daten in Prozessorregister geladen und
wieder an die gleiche Stelle zurückgeschrieben. Im Kommentar wird angemerkt, dass die Daten am Cache vorbei kopiert werden, aber dem Code kann ich dies nicht ansehen.

Zufälligerweise habe ich selbst zu beiden Punkten Experimente gemacht - mit sehr erfolgreichem Ausgang. Ich kann also bestätigen, das dies kein Unsinn sein muss (die "Bit ist Bit" Fraktion kann das ja einfach ignorieren oder herzlich drüber lachen).

Auf meiner Festplatte kann ich nun aus Musikdateien "verbesserte Kopien" erstellen. Im Gegensatz zu meinen ersten Experimenten, die ich im "Bitidentische Dateien auf der Festplatte" Thread geschildert habe, ist der Effekt gar nicht subtil; ich konnte das auch einigen Leuten schon nachvollziehbar vorführen.

Experimente mit dem Speicher sind technisch schwierig. Man muss da aufpassen, dass vom Compiler für ihn unnötig aussehende Kopiervorgänge nicht wegoptimiert werden. Mit C-Programmen habe ich auch nur marginale Effekte erzielen können. Deshalb habe ich etwas über Assembler für ARM-Prozessoren gelernt und damit schon nach wenigen Versuchen sehr gute Erfolge erzielt (noch bessere Detailaufzulösung, räumliche Abbildung, usw.). Meine Strategie ist es da nicht, wie oben beschrieben, die Ausgangsdaten im RAM zu behandeln, sondern die Daten, die kurz vor dem Verlassen des Rechners stehen (um vom Convolver-Rechner an den Audio-Rechner geschickt zu werden, bzw. vom Audio-Rechner an den DAC). Da ist noch Raum für weitere Experimente.

Wenn ich dazu komme, meine Programmsammlung mal wieder in einen Release-fähigen Zustand mit passender Dokumentation zu bringen, werden die Programme wieder frei verfügbar sein, und ich werde die entsprechenden Linux- und Festplatten-Threads updaten.

Viele Grüße,
Frank

[Ohrpfropf]

was Du hier beschreibst, klingt nach einem Überschreiben der Musikdateien auf der Festplatte.
[...] Auf meiner Festplatte kann ich nun aus Musikdateien "verbesserte Kopien" erstellen. [...]

Hallo Frank,
das wird einem bei dem Tool von Yokota auch "suggeriert". Irgendwo schreibt er dann aber, dass durch das Verschieben bearbeiteter Dateien/Ordner der Effekt verloren geht, was "Gott sei Dank" stimmt, denn das ist auch die Tücke des Programms: Es gibt keine Rückstellungsmöglichkeit einmal bearbeiteter Dateien/Ordner . Selbst wenn diese durch Sicherungskopien ersetzt werden, bleibt der Effekt erhalten. Erst eine Veränderung von Ordner- oder Dateinamen stellt den ursprünglichen Klangcharakter wieder her. Alternativ schiebt man das Ganze an einen anderen Ort. Das betrifft modifizierte Player wie Musikdateien gleichermaßen. Also Vorsicht! Die Deinstallation des Programms hilft ebenfalls nicht. Ich denke, dass von "Rewrite data" eine Datei angelegt wird, in der die Pfade zu den Dateien stehen, die ausgewählt wurden. Was dann geschieht bleibt erstmal ein Rätsel.

Warum ein dadurch bewirkter Effekt durch Reboot des Rechners hinfällig werden soll, erschließt sich mir nicht.

Mittlerweile weiß ich, die Änderungen sind permanent ...
Grüße,
Lutz

[lukivision]

Auf meiner Festplatte kann ich nun aus Musikdateien "verbesserte Kopien" erstellen. Im Gegensatz zu meinen ersten Experimenten, die ich im "Bitidentische Dateien auf der Festplatte" Thread geschildert habe, ist der Effekt gar nicht subtil; ich konnte das auch einigen Leuten schon nachvollziehbar vorführen.
Frank

Ja, das kann ich bestätigen. Frank hatte mir mal 2x das gleiche Stück vorgespielt, einmal die "normale" Version, einmal die nach seinem Verfahren speziell kopierte Version. Der Unterschied war alles andere als subtil, er war sogar für mich sofort hörbar - mehr Klarheit.

Gibt es denn nirgendwo eine Forschungsstelle, die sowas mal systematisch untersucht? Dieser und viele andere Effekte in der Signalübertragung sind doch so dermaßen frappierend, daß es für mich Laien mit dem erlernten Halb-Wissen über Elektrizität nicht mehr zu verstehen ist.

Luki

[Fujak]

Liebe Rewriter,

ich habe heute nachmittag das Programm eingehender ausprobiert. Setup ist Windows 2012R2 in der WinRam-Version (mit AO 1.3). Player MQn 3.87/8.92. Da MQn Flac-Files vor dem Abspielen zunächst in WAV konvertiert und dann in das MQn-Verzeichnis (Cache) schreibt, nützt die Behandlung von FLAC-Files mit Rewrite Data wenig, weil damit der Effekt verlorengeht. Er basiert ja darauf, dass die Filestruktur neugeordnet wird. Das geht verloren, wenn der File oder das übergordnete Verzeichnis umbenannt oder an einen anderen Speicherort verschoben wird. Das Ganze funktioniert also nur mit Files in WAV, wenn man MQn einsetzt.

Der Effekt mit WAV-Files ist auf jeden Fall deutlich hörbar: Der Klang ist weicher, räumlicher und präziser. Das Konvertieren geht erstaunlich schnell über die Bühne. Allerdings eine Musiksammlung mit 1TB kann hier durchaus Stunden in Anspruch nehmen. Da der Prozess unbeaufsichtig laufen kann, kann man das auch über Nacht machen. Es lohnt sich auf jeden Fall.

Ich werde das auch noch mit anderen Playern testen.

Grüße
Fujak

[Hans-Martin]

Ich entnehme diesem Thread eine allgemeine Zustimmung, dass bitidentische Dateien durchaus unterschiedlich klingen können.
Grüße Hans-Martin

[Fujak]

Ich entnehme diesem Thread eine allgemeine Zustimmung, dass bitidentische Dateien durchaus unterschiedlich klingen können.

Hallo Hans-Martin,

ja und nein. Denn (ähnlich wie bei Kabeln): Files klingen ja nicht. Aus meiner Sicht hat die Art und Weise, wie der bitidentische File auf der Platte liegt, eine Auswirkung darauf, wie der File in den Rendervogang der Playersoftware eingelesen wird. Das hat offenkundig klangliche Auswirkungen.

Grüße
Fujak

[frankl]

ich habe heute nachmittag das Programm eingehender ausprobiert. Setup ist Windows 2012R2 in der WinRam-Version (mit AO 1.3). Player MQn 3.87/8.92. Da MQn Flac-Files vor dem Abspielen zunächst in WAV konvertiert und dann in das MQn-Verzeichnis (Cache) schreibt, nützt die Behandlung von FLAC-Files mit Rewrite Data wenig, weil damit der Effekt verlorengeht. Er basiert ja darauf, dass die Filestruktur neugeordnet wird. Das geht verloren, wenn der File oder das übergordnete Verzeichnis umbenannt oder an einen anderen Speicherort verschoben wird. Das Ganze funktioniert also nur mit Files in WAV, wenn man MQn einsetzt.

Hallo Fujak und andere Rewrite-Interessierte,

ich habe mir das "Rewrite Data" mal angesehen. Was hier gemacht wird, hat nichts mit "Neuordnung der Filestruktur" zu tun. Eine Umbenennung oder Verschiebung innerhalb der gleichen Partition (des gleichen Laufwerkes) ändert auch nichts an der abgespeicherten Datei und damit nichts am Effekt. Er geht erst verloren, wenn die Daten wirklich kopiert werden.

Das Programm macht folgendes: Es ließt die Datei blockweise in den RAM, kopiert die Daten zwischen RAM und gewissen Prozessorregistern hin und her, und schreibt den Block in die (bitidentische) Ausgabedatei.

Die (sehr grobe) Idee ist wohl die folgende: Auf der Festplatte werden Bits gespeichert, indem Partikel magnetisiert werden. Zur zuverlässigen Speicherung muss diese Magnetisierung gerade stark genug sein, um 0 und 1 voneinander unterscheiden zu können. Die tatsächliche Magnetisierung kann dabei aber von Bit zu Bit sehr unterschiedlich sein. Im RAM werden die Bits im Prinzip durch Laden von winzigen Kondensatoren gepeichert, die auch noch ständig ihre Ladung verlieren, so dass sie von der Hardware regelmäßig ausgelesen und neugeschrieben werden müssen (Refresh des RAM), damit die Information nicht verloren geht. Auch hier gibt es eine große Bandbreite von Ladungszuständen, die als 0 bzw als 1 interpretiert werden. Da ist es vielleicht nicht unplausibel, dass ein schwach magnetisiertes Bit auf der Festplatte beim Lesen der Daten in den RAM zu einen schwach geladenen Kondensator führt, und umgekehrt beim Schreiben der Daten. Die nächste Vermutung/Beobachtung ist, dass die Bits in einem Datenwort, dass in ein Prozessorregister geladen wurde, in dem Register "physikalisch gleichmäßiger" repräsentiert werden (unterschiedlich gut, je nach Typ des Registers). Wenn dieses Modell einigermaßen richtig ist, dann erscheint der oben beschriebene Algorithmus sinnvoll: Ungleichmäßig magnetisierte Bits auf der Festplatte werden in den RAM geladen und durch unterschiedlich deutliche Ladungen repräsentiert, durch das Kopieren und Überschreiben mittels Prozessorregistern werden die Bits durch viel gleichmäßigere Ladungszustände repräsentiert, was beim Zurückschreiben auf die Festplatte zu Bits führt, die durch gleichmäßigere Magetisierung repräsentiert werden. Zum Abspielen der Datei müssen die Daten ja wieder über den RAM und eventuell diverse Bearbeitungsschritte in ein (zum Beispiel USB-)Ausgangssignal verwandelt werden. Bei dem beschriebenen Modell des RAM erscheint es dann auch plausibel, dass das Ausgangssignal weniger Jitter hat, wenn alle Bits durch möglichst gleichmäßige Ladungszustände im Speicher repräsentiert werden.

Mir ist natürlich klar, dass dies ein extrem vereinfachendes Modell ist, und es ist nicht offensichtlich, wie signifikant diese Effekte im Hinblick auf beteiligte Cache-Speicher auf Festplatte und im RAM, physikalische Bedingungen, Kabel, Stromversorgung usw. sein können. Um das herauszufinden, muss man eben Experimente machen!

Ich entnehme diesem Thread eine allgemeine Zustimmung, dass bitidentische Dateien durchaus unterschiedlich klingen können.

Und da haben schon eine ganze Reihe von Leuten in verschiedenen Foren berichtet, dass sie einen Effekt durch das "Rewrite data" Programm feststellen konnten. Grundsätzlich kann die Anwendung auch für flac-Dateien oder sogar für die Programmdateien des Abspielprogramms oder der beteiligten Treiber interessant sein. Es scheint mir auch plausibel, dass der Effekt nach längerer Zeit nachlassen kann, etwa wenn Nachbarspuren einer kopierten Datei beschrieben werden.

Wie sinnvoll oder signifikant die Anwendung ist, muss aber wohl jeder im eigenen Setup herausfinden.
Da ich keine Windowsrechner habe, kann ich das "Rewrite data" Programm selbst nicht testen.

Viele Grüße
Frank

PS: Wie ich in einem Beitrag oben schon geschrieben habe, habe ich ein eigenes Programm ("improvefile"), das Ähnliches macht und das bei mir reproduzierbar deutliche Effekte hat. Bei meinem Modell berücksichtige ich auch noch, dass auf der Festplatte die Bits auch recht unterschiedlich weit auseinander gespeichert sein können. Deshalb erzeuge ich einen sehr gleichmäßig getakteten Datenstrom beim Schreiben der kopierten Datei, in der Hoffnung, dass auch das Timing beim Abspielen verbessert wird.

[Fujak]

Hallo Frank,

danke für Deine Erläuterungen und daraus folgernden Hypothesen. Das macht es für mich zumindest nachvollziehbarer, was ich an Unterschieden hören kann.

Grüße
Fujak

P.S. auf die Vorstellung Deines Programms "improvefile" bin ich sehr gespannt. Ich nehme an, Du wirst es zu gegebener Zeit im Linux-Thread oder in Deinem Vorstellungsthread näher erläutern.

[Ohrpfropf]

... nützt die Behandlung von FLAC-Files mit Rewrite Data wenig, weil damit der Effekt verlorengeht.

Hallo Fujak,
probiere doch alternativ den MQn-Player von Rewrite data bearbeiten zu lassen ("User select"). Vielleicht ist es dazu besser, Du kopierst MQn an eine andere Stelle, um später den ursprünglichen Zustand wieder herstellen zu können. Die Unterschiede bei Dir wären mal interessant - wenn vorhanden. So gering, wie beim ersten Kontakt mit dem Programm erwähnt, sind sie nicht, sondern doch deutlich. Getestet mit Foobar und BHE.
Grüße,
Lutz

[MichaNRW]

PS: Wie ich in einem Beitrag oben schon geschrieben habe, habe ich ein eigenes Programm ("improvefile"), das Ähnliches macht und das bei mir reproduzierbar deutliche Effekte hat. Bei meinem Modell berücksichtige ich auch noch, dass auf der Festplatte die Bits auch recht unterschiedlich weit auseinander gespeichert sein können. Deshalb erzeuge ich einen sehr gleichmäßig getakteten Datenstrom beim Schreiben der kopierten Datei, in der Hoffnung, dass auch das Timing beim Abspielen verbessert wird.

Ein kleiner Gedanke von mir
Heutige Betriebssysteme bieten eine Defragmentierung der Platte garnicht mehr an (unter Linux und anderen unixodiden Betriebssystemen ist und war mir keines bekannt).
Es liegt also offenbar primär am verwendeten Dateisystem (NTFS, vor allem alte FAT16/32, usw.), ob es überhaupt notwendig ist, zu defragmentieren? Seit NTFS, welches dem Windows 2000 zugrunde liegt, fällt so was weg, denke ich. Im alltäglichen Leben, wo der Schreib-/Lesekopf der HD so oft hin und her wedelt, weil während der Programmlaufzeit ettliche Dateien geöffnet, verändert, geschlossen werden (filemon), sehe ich keinen wirklichen Sinn dahinter. Aber wenn man es hören kann, ist es ja gut

[Fujak]

Hallo Michael,

wie Frank weiter oben dargelegt hat, handelt es sich bei dem Programm nicht um eine bloße Defragmentierung.

Grüße
Fujak

[frankl]

Ein kleiner Gedanke von mir
Heutige Betriebssysteme bieten eine Defragmentierung der Platte garnicht mehr an (unter Linux und anderen unixodiden Betriebssystemen ist und war mir keines bekannt).
Es liegt also offenbar primär am verwendeten Dateisystem (NTFS, vor allem alte FAT16/32, usw.), ob es überhaupt notwendig ist, zu defragmentieren? Seit NTFS, welches dem Windows 2000 zugrunde liegt, fällt so was weg, denke ich.

Hallo Micha,

Fragmentierung kann auf der (Software-)Ebene des Dateisystems auftreten. Ein Dateisystem verwaltet einen durchgängig adressierten Speicherbereich. Wenn mit der Zeit immer mal wieder Daten geschrieben und gelöscht werden, entstehen Lücken darin. Je nach Dateisystem werden auch schon mal für große Dateien zu kleine Lücken genutzt, so dass am Ende der Lücke eine Adresse angegeben werden muss, wo es weitergeht. So eine Datei, die über mehrere Bereiche des durchgängigen Speichers verteilt ist, heißt fragmentiert.
In modernen Dateisystemen sind aber gute Heuristiken eingebaut, um diese Fragmentierung sehr gering zu halten, insbesondere bei den heutigen riesigen Festplatten. Während früher dieser logisch durchgängig adressierte Speicher in engem Zusammenhang mit den physikalischen Speicherstellen auf dem Speichermedium standen, ist das heute nicht mehr der Fall. Das Betriebssystem adressiert das Speichermedium auf einem abstrahierten Level, und im Controler des Mediums (Festplatte, SSD, Speicherkarte) wird erst intern die physikalische Zuordnung verwaltet. Insbesondere bei Flashspeichern (wie SSD oder Speicherkarte) ist es wichtig, dass alle Speicherzellen statistisch gleichmäßig genutzt werden, weil die nicht so oft neu beschrieben werden können. Aus diesen Gründen ist die Defragmentierung im Dateisystem heutzutage kein großes Thema mehr. Die tatsächliche physikalische Fragmentierung entsteht unterhalb dieser Ebene in der Hardware mit ihren eigenen Controlern.

Meiner Meinung nach ist die Fragmentierung auf der physikalischen Ebene auch nur geringfügig, wenn überhaupt, relevant unter audiophilen Gesichtspunkten. Dafür sind die "Fragmente" viel zu groß.

Im alltäglichen Leben, wo der Schreib-/Lesekopf der HD so oft hin und her wedelt, weil während der Programmlaufzeit ettliche Dateien geöffnet, verändert, geschlossen werden (filemon), sehe ich keinen wirklichen Sinn dahinter.

Auf Rechnern zum Musik abspielen, wie sie in verschiedenen Varianten hier im Forum diskutiert werden, sollten das ja nicht mehr "etliche" Dateien sein, die ständig geöffnet und geschlossen werden.
Auf meinen Audiorechnern wird jedenfalls während des Musikabspielens keine Datei im Dateisystem angesprochen (Ausnahme: eine vorgefaltete Musikdatei, die nicht in den RAM passt). Bei Windows ist es wohl etwas mehr, sonst könnte das Windows im RAM ja nicht punkten.

Aber wenn man es hören kann, ist es ja gut

Hier weiß ich jetzt nicht, auf welche Hörtests Du Dich beziehst. Das hier diskutierte Programm und was ich im Beitrag weiter oben beschrieben habe, hat mit Defragmentierung gar nichts zu tun.

Viele Grüße,
Frank