Fischen im Trüben

Von der Freude, Files im Hexeditor aufzumachen

So banal es klingen mag, im Kern finde ich immer noch endlos faszinierend, das jedes digitale File - ob Langfilm, Klingelton oder PDF - am Schluss doch nur aus Bausteinen von 1 und 0 zusammengesetzt sind, die anhand von Headers, die am Anfang des Files stehen erst interpretiert werden können, wie DNA oder ein fremdsprachiger Text mit einem Wörterbuch.

Oft sind die ersten 4 Bytes einer Datei ein Hinweis, mit welchem Codec/Format diese Datei daherkommt, und liefert damit dem Mediaplayer einen Hinweis, wie die nachfolgenden 4 oder mehr Bytes zu interpretieren sind, die wiederum Hinweise darauf geben, wie der Rest des Files, in dem die “eigentlichen” Bilder oder Töne gespeichert sind, abzuspielen sind, die ohne den Fileheader nichts als digitales Rauschen in 0 und 1 wären.

Das Programm, das selbst aus Nullen und Einsen besteht, muss also aus einer Liste von Nullen und Einsen, mit einer Anleitung, die ebenfalls nur aus Nullen und Einsen besteht, die Dateien darstellen, und ich muss an die goldene Platte auf Voyager denken, die Instruktionen an eine unbekannte Lebensform geben muss, wie die Platte zu lesen ist.

Während uns die Schnittprogramme und Mediaplayer die Interpretationsarbeit normalerweise abnehmen und uns die Dateien für Menschen verständlich als Töne oder Bilder präsentieren, gibt es auch Tools, die uns erlauben, eine Schicht tiefer zum Denken des Computers vorzudringen.

Für meine Arbeit am ZHdK-Archiv fasse ich die einzelnen Audiodateien einer 5.1-Mischung (L R C LFE Ls Rs) zu einem einzelnen wav zusammen, das 6 Spuren enthält. Dafür benutze ich das Kommandozeilenprogramm sox.

Mir fiel nach etwa 100 Filmen auf, dass die hergestellten WAVs von Langfilmen manchmal viel zu kurz waren - bei einem 84minütigen Film 2 Minuten, bei einem 90minütigen Film 18min. Wie wenn die ersten 82 Minuten vergessen wurden.

Nach erfolglosem Durchstöbern der sox-Foren kam ich auf die Idee, dass weder sox, noch direkt die 82 Minuten das Problem sind, sondern die Filegrösse. Ein sechsspuriges 24bit 48kHz wav ist nämlich bei 82 Minuten rund 4.2 GB (4 GiB) gross. Längere Filme wurden zwar grösser als 4.2 GB, aber - egal in welchem Player - es wurden nur so viele Minuten abgespielt, wie sie länger als die 82 Minuten waren. Wie wenn der längste Teil des Files zwar vorhanden wäre, aber nicht gelesen; nicht interpretiert wird.

Die Lösung lag in der Filespezifikation des WAVE-Formats selbst.

Die ersten 4 Bytes werden von den Buchstaben “RIFF” belegt, die dem Player angeben, dass jetzt eine Tondatei zu erwarten ist. Dies kann man anschauen, wenn man ein beliebiges WAV in einem Hexeditor wie 0xED aufmacht. Der Hexeditor versucht nicht wie ein Mediaplayer, den Zeichensalat abzuspielen und zu interpretieren, sondern lässt uns direkt in den Bauplan blicken - die binäre Information stellt er als hexadezimale Zahlen dar, die wiederum als Buchstaben dargestellt werden können. Die ersten 4 Bytes “01010010 01001001 01000110 01000110” werden als “52 49 46 46” dargestellt und das wiederum lässt sich in ASCII als “RIFF” lesen.

Die nächsten 4 Bytes beschreiben die Grösse der nachfolgenden Datei - die Anzahl Bytes der Datei*. Alle Player rechnen damit, dass Byte 4-8 einer wav-Datei die insgesamte Grösse beschreibt und alles nach Byte Nr. 8 andere Informationen enthält, wie Audioformat, die tatsächlichen Töne, etc.

Weil der Platz, wo die Grösse der gesamten Datei beschrieben wird, standartmässig eben auf 4 Bytes limitiert ist, ist die maximal grösste positive Zahl, die sich in 4 Bytes (= 32 bit) darstellen lässt, 2³², also 4’294’967’296. Und deshalb können WAVs eben maximal 4’294’967’296 bit (+ die 32bit für “RIFF” und die Filesizeangabe) oder eben 4GiB gross sein, and I think that’s beautiful.

Das erklärt auch, dass zu grosse WAVS einen Overflow dieser 4 Bytes erleben. Eine grössere Zahl als binär 11111111 11111111 11111111 11111111 (hex FF FF FF FF oder dezimal eben 4’294’967’296) lässt sich im vorhanden Platz, ohne weitere Stellen, nicht darstellen, genau wie ein alter Taschenrechner mit einem zu kleinen Display. Ein Byte mehr, und der Platz wird mit Nullen gefüllt.

Während dem Schreiben der Datei wird die Filegrösse hochgezählt, überläuft, und so wird im Fileheader schlussendlich nur notiert, was über die 4.2 GB heraushängt (bei einem 84min-Langfilm also nur wenige Minuten) - obwohl die Datei als Ganzes viel grösser ist. Die eigentlichen Töne wurden also festgehalten, aber die Anleitung dazu, wie diese Bytes zu interpretieren sind, dass sie auch tatsächlich als Töne gehört werden können, ist nicht korrekt. Durch gezieltes Manipulieren von Byte 4-8 können darum auch verloren geglaubte Töne wieder hervorgeholt werden, wenn man FF FF FF FF reinschreibt und plötzlich 82min des Filmes anhören kann statt zwei.

Die Programme interpretieren den Zeichensalat einer Datei anhand von festgelegten Konventionen - im Hexeditor herumstochern und durch herumtippen andere Töne zu produzieren, quasi auf diesen Konventionen herumzusurfen, wenn man sie mal verstanden hat - fühlt sich an wie verbotenes Zaubern.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

liebe Grüsse
Fabienne

PS: Um das Problem zu umgehen, hat Sony ein neues Format, Wave64, erfunden. Damit kann bei CD-Qualität eine theoretische Abspieldauer von 3 Millionen Jahren erreicht werden.

*Eigentlich: Filesize minus 8 (= die ersten 4 Bytes für ”RIFF” und die 4 Bytes der Filesize-Angabe selber).

Dieser Newsletter wird zu folgenden Themen erscheinen: Avid, Schnittassistenz, Programmieren, Nischenthemen, Hardware, Datensicherung, Datenrettung, Workflows, Brancheninfos, Lohnverhandlungen.