Nachdem ich selbst Audio-Software entwickle, weiß ich zufällig, was es mit diesem Chunk auf sich hat und wollte mal Licht ins Dunkel bringen. 
Der JUNK-Chunk ist nichts “Cubase-spezifisches”, sondern Bestandteil der ursprünglichen (32-bit) RIFF-Spezifikation von Microsoft, sowie aller gängigen 64-bit Erweiterungen der RIFF-Spezifikation, beispielsweise …
- EBU-Tech 3006-2007
- ITU-R Recommendation BS.2088-1
Das EBU-Format wird auch als “RF64” (RIFF, 64-bit), das ITU-Format als “BW64” (Broadcasting WAVE, 64-bit) bezeichnet.
Diese Spezifikationen sind meist der Grund, weshalb der JUNK-Chunk überhaupt zum Einsatz kommt, wenngleich er, wie bereits erwähnt, auch in der ursprünglichen 32-bit RIFF-Spezifikation vorgesehen war. Die 64-bit Erweiterungen spezifizieren nämlich einen “Kompatibilitätsmodus”, in dem zunächst eine übliche 32-bit RIFF-WAVE-Datei geschrieben wird. Um zusätzlichen Platz für die 64-bit Längenfelder zu reservieren, wird unmittelbar nach dem 32-bit RIFF-Header ein JUNK-Chunk geschrieben. Dann folgen die üblichen “fmt”- und “data”-Chunks.
Nachdem diese Chunks angelegt wurden, kann ganz normal in die Datei aufgezeichnet werden, indem Samples ans Ende der Datei angehängt und anschließend die 32-bit Längenfelder im RIFF-Header und im Header des “data”-Chunks aktualisiert werden.
Spätestens sobald die Länge des RIFF-Chunks den Wert 2^32 - 1, die größte darstellbare 32-bit Ganzzahl, überschreitet, muss die Datei in ein 64-bit Format umgewandelt werden. Dabei wird dann der bisherige 32-bit Header und der darauf folgende JUNK-Chunk mit dem größeren Header des 64-bit Dateiformats überschrieben. Die eigentlichen Sampledaten bleiben dabei an der selben Position in der Datei.
Der JUNK-Chunk reserviert also zusätzlichen Platz in der Datei nach dem üblichen 32-bit RIFF Header, damit man den (größeren) Header einer 64-bit Erweiterung vor die eigentlichen Samples schreiben kann, sobald die Datei größer als ~4 GiB wird und das 32-bit RIFF-WAVE-Format nicht mehr ausreicht. Aus diesem Grund kann dieser Chunk auch nicht nach dem “data”-Chunk kommen. (*) (Nach den oben genannten Spezifikationen muss er sogar unmittelbar nach dem RIFF-Header und somit sogar noch vor dem “fmt”-Chunk kommen.) Der JUNK-Chunk sorgt dafür, dass der “data”-Chunk (und in diesem Fall auch der “fmt”-Chunk) an Ort und Stelle bleiben kann, wenn die Datei einen größeren Header bekommen muss, weil das 32-bit RIFF-WAVE-Format mit einer Datei dieser Größe nicht mehr umgehen kann. Mit einer Ausrichtung an Sektorgrenzen oder ähnlichem hat das ganze in diesem Fall tatsächlich nichts zu tun.
(*) Das ist auch logisch, denn die 64-bit Längeninformation ist ja dafür da, dass darauf folgende Chunks größer als 4 GiB sein können. Wenn beispielsweise der “data”-Chunk größer als 4 GiB ist, dann kann die Längenangabe im Header des Chunks ja nicht stimmen, schließlich ist dafür lediglich ein 32-bit Feld vorgesehen. Wenn ich die 64-bit Längeninformation an diesem Punkt also nicht bereits gelesen hätte, wüsste ich ja überhaupt nicht, wo der “data”-Chunk aufhört und könnte die (hypothetische) Längeninformation “hinter dem ‘data’-Chunk” somit nie finden. Damit ist klar, dass die ganzen Längeninformationen am Anfang der Datei stehen müssen - und somit auch der JUNK-Chunk, der für diese ggf. den Platz freihält.
Die originale (32-bit) RIFF-Spezifikation von Microsoft spezifiziert den JUNK-Chunk, wie bereits erwähnt, ebenfalls.
JUNK (Filler) Chunk: A JUNK chunk represents padding, filler or outdated information. It contains no relevant data; it is a space filler of arbitrary size. The JUNK chunk is defined as follows: <JUNK chunk> → JUNK(<filler>), where <filler> contains random data.
(Wenngleich wohl eher “arbitrary” gemeint sein dürfte, und nicht tatsächlich “random”. )
Und weiter.
Waveform Audio File Format (WAVE): This section describes the Waveform format, which is used to represent digitized sound. The WAVE form is defined as follows. Programs must expect (and ignore) any unknown chunks encountered, as with all RIFF forms. However, <fmt-ck> must always occur before <wave-data>, and both of these chunks are mandatory in a WAVE file.
Damit ist klar, dass es die Brennsoftware ist, die sich “nicht standardkonform verhält” und dort ggf. ein Bug zu melden wäre - sofern die entsprechende Software überhaupt noch weiterentwickelt wird.
Natürlich könnte man den JUNK-Chunk weglassen, allerdings würde dann beispielsweise eine laufende Aufnahme abbrechen, sobald die Datei größer als ~4 GiB wird, oder man müsste sie irgendwie automatisch in mehrere Dateien “splitten”. Weil vor allem ersteres zu Frust bei Usern führen könnte und letzteres ggf. Mehraufwand bei der Implementierung bedeutet, kann ich gut nachvollziehen, dass der JUNK-Chunk per Default geschrieben wird, um beispielsweise während einer Aufzeichnung “on the fly” auf ein anderes Dateiformat, das größere Dateien erlaubt, wechseln zu können. Aber natürlich wäre es gut, dieses Verhalten konfigurieren zu können, falls man mit Tools arbeitet, die (fälschlicherweise) davon ausgehen, dass der “fmt”-Chunk immer an Offset 12 in der Datei beginnt, oder gar der “data”-Chunk an Offset 36. Dann muss man aber ggf. damit leben, dass lange Aufnahmen abbrechen.
Das korrekte Vorgehen, um einen bestimmten Chunk in einer RIFF-Datei zu finden, liegt jedenfalls darin, nach dem RIFF-Header über alle Chunks zu iterieren, bis man auf einen mit dem gesuchten Typ trifft. Das hat nichts mit “Fehlertoleranz”, sondern schlicht mit korrekter Implementierung des Dateiformats zu tun. RIFF-Dateien bestehen nunmal konzeptionell aus Chunks variabler Länge, von daher liegt der ganzen Idee dieses Dateiformats zugrunde, dass (abgesehen vom 12 Byte langen RIFF-Header selbst) im Grunde nichts an einem festen Offset steht. Klar ist aber auch, dass viele Tools “schlampig programmiert sind” und Spezifikationen (aus Bequemlichkeit oder Unkenntnis) nicht vollständig umsetzen. Cubase scheint hier jedenfalls alles richtig zu machen und den JUNK-Chunk vermutlich zu verwenden, um vorsorglich Platz für die 64-bit Erweiterungen der EBU bzw. ITU zu reservieren.
Beim Rendern könnte man die Größen aller Chunks ja tatsächlich exakt im Voraus berechnen und somit entscheiden, ob ein 32-bit Format ausreicht oder ob ein 64-bit Format erforderlich wird. Bei einer laufenden Aufzeichnung sehe ich eher, weshalb man für Dateien größer als 4 GiB “Vorsorge trifft”, denn da ist nunmal im Voraus nicht bekannt, nach welcher Dauer der Benutzer die Aufnahme beenden wird. Und 4 GiB sind nunmal deutlich schneller erreicht, als manche sich das vorstellen mögen.
- Mono, 96 kHz, 24-bit PCM: 4 h 8 min 33 s
- Mono, 192 kHz, 64-bit IEEE-754: 46 min 36 s
- Mono, 384 kHz, 64-bit IEEE-754: 23 min 18 s
- Stereo, 96 kHz, 24-bit PCM: 2 h 4 min 16 s
- Stereo, 192 kHz, 64-bit IEEE-754: 23 min 18 s
- Stereo, 384 kHz, 64-bit IEEE-754: 11 min 39 s
- 16 ch., 96 kHz, 24-bit PCM: 15 min 32 s
- 16 ch., 192 kHz, 64-bit IEEE-754: 2 min 54 s
- 16 ch., 384 kHz, 64-bit IEEE-754: 1 min 27 s
