WAV Container mit JUNK Chunk?!?!

Hallo zusammen,

ich habe erstmalig mit meinem niegelnagelneuen Cubase 7 einen Audio-Mixdown exportiert und … war enttäuscht! Meine Versuche die resultierende WAV-Datei zu Brennen wurden von der Brennsoftware mit “ungültiges WAV Format” kommentiert. Ich habe alle Einstellungen richtig vorgenommen (44,1KHz / 16 Bit / alles andere auf “Aus”) - kein Erfolg.

Also nahm ich mir mal einen HEX-Editor zur Hand, um zu checken, was man denn da wohl falsch machen könnte. Es stellte sich heraus, dass Cubase 7 nach dem “RIFF[LÄNGE-DER-DATEI-ALS-32UINT]WAVE” als nächstes einen “JUNK” Chunk schreibt, bevor der "fmt " Chunk kommt. Ich konnte keine Spezifikation finden, die dies erlaubt. Zwar sind einige Programme offenbar fehlertolerant, aber leider nicht alle.

Mein Workflow ist nun als wie folgt: mit Cubase 7 Audio-Mixdown erstellen. In Nero WaveEditor öffnen, sofort wieder speichern. Nun kann ich die Datei brennen.

Könnte man da nicht irgendwie eine Art Kompatibilitätsmodus integrieren, der den JUNK Chunk weglässt, so dass viel mehr Programme mit dem resultierenden WAV Container zurechtkommen?

Wenn ich beiden Dateie dann vergleiche hat Nero WaveEditor tatsächlich auch nur den JUNK Chunk entfernt - sonst ist Datei völlig gleich. Erst habe ich einen Text-Comparer genommen und weil ich das Ergbebnis nicht glauben konnte, habe ich noch einmal mit einem HEX Editor einen Vergleich gemacht. Ergebnis: es ist tatsächlich nur dieser JUNK Chunk zuviel.

Und weil “Junk” u.a. auch Plunder, Schrott, Ramsch u. Ausschuss heißt - können wir das nicht weglassen zukünftig oder wenn es für Cubase 7 selbst erforderlich sein sollte: per Option ausschließen können? Oder vielleicht machen wie die anderen: extra Chunks NACH dem Format und Data Chunk - damit kommt nahezu jedes Programm klar und man kann immer noch Cubase 7 spezifische Daten ablegen, falls dies benötigt würde.

Viele Grüße
Marcus

Marcus, ich muss dazu sagen, ich brenne viel mit Nero, und hatte in all den Jahren jedenfalls niemals ein Problem mit gerenderten Wavs´s, welche aus Cubase/Nuendo (und Wavelab) stammen…
Auch mit anderen Brennprogrammen oder Betriebssystemen, immer alles ok. Auch habe ich hier im Forum und im Musikerkumpelkreis nie davon gehört, dass es da Sorgen gab… Daher bin ich etwas verwundert über dein Posting.
Vielleicht vorab etwas in technischer Hinsicht, welche Nero Version verwendest du genau?
Und hast du es parallelerweise schon mit dem onboard Win7 Brenntool (ich gehen davon aus, dass du Win7 nutzt) probiert?
Wie rendern denn andere DAWs? vielleicht kannst du das auch mal per Hex-Editor ganz genau gegenchecken…

Hallo Centralmusic,

ich brenne mit NTI MediaMaker 8. Das war Anno 2010 bei meinem Laptop (Acer 8942g / 16GB / 1TB SSD / 2 TB HDD / WIN8.1 / Cubase 7.0.5) dabei und hat bisher jedes WAV gebrannt, was ich ihm untergeschoben habe.

Ich hatte vorher keine DAW. Meine DAW war bisher Sequel (v1). Ich habe erst vor einigen Wochen Cubase 7 gekauft und musste dann erstmal über einige Woche so einige Stunden Youtube-Tutorials ansehen, bevor ich jetzt wieder zur Musik komme.

Also das Problem ist, in der Spezifikation von WAV steht, dass an zweiter Stelle ein Block kommen sollte, der mit “fmt” anfängt und in dem das Format spezifiziert ist. Bei dem gerenderten WAV kommt dieser Block erst an dritter Stelle. Die Beschreibungen, die ich gelesen habe, besagen auch, dass man sich darauf nicht verlassen sollte, wenn man Software schreibt, aber wie oben erwähnt ist diese WAV die allererste, die mir unterkommt, wo ich wirklich mal nachsehen musste, was da passiert und warum das nicht geht. Ich weiß auch nicht, warum dieser zusätzliche Block eingefügt wurde. Es stehen keine Nutzdaten drinne - er ist leer.

Ich habe ein Screenshot der beiden Dateien angefügt. Beide Dateien fangen an mit “RIFF” gefolgt von der Länge der Datei als uint32 (4 Zeichen) gefolgt von WAVE. Dann kommt der erste Chunk und der sollte laut Spezifikation “fmt” sein, gefolgt von einem “data” Chunk. Ich habe im Bild beide “fmt” Chunks markiert. Man sieht deutlich, wie bei der gerenderten Datei noch “JUNK” Chunk zwischen WAVE und “fmt” liegt - ohne Inhalt. Die Frage ist, wozu soll das gut sein, wenn er a) leer ist und b) gegen die Spezifikation verstößt?

Ich habe ja ein Workaround und alles ist gut. Der Sinn erschließt sich mir dennoch nicht. Mit Sequel konnte ich einfach exportieren und mit jedem Program auf CD Brennen. Alle mit Sequel gerenderten WAV sind ordnungsgemäß nach Spezifikation und halten sich an die Reihenfolge der notwendigen Chunks (“RIFF”/"fmt "/“data”).
wav-hex.png

Gefunden auf: http://www.daubnet.com/en/file-format-riff
To align RIFF chunks to certain boundaries (i.e. 2048bytes for CD-ROMs) the RIFF specification includes a JUNK chunk. Its contents are to be skipped when reading. When writing RIFFs, JUNK chunks should not have odd number as Size.

lol … ich hab doch auch danach gegoogelt - warum zum Geier habe ich das nicht gefunden!!! Wobei sich mir dennoch nicht erschließt, warum Cubase beim Export meine WAVs an Grenzen ausrichten will, wo das eigentlich die Brennersoftware machen sollte, die natürlich auch mit den JUNK Chunks umgehen können sollte.

Gut, Thema erledigt und es bleibt eine Wahnung für die Leute, die das Forum durchsuchen:

Achtung beim Brennen mit NTI MediaMaker 8 - es mag Probleme geben mit dem JUNK Chunk :wink:

Danke.

@doggy. Forum durchsuchen ist eine gute Idee. Ich habe es gerade mal gemacht. Junk Chunk eingegeben und was glaubst du was ich gefunden habe ?. Reflexartig bemühe ich immer Google und an die Suchfunktion im Forum denke ich selten. :unamused:

http://www.steinberg.net/forums/viewtopic.php?f=19&t=49622&p=302683&hilit=Junk+Chunk&sid=94c72790a7bcf6f534f95ba3c9bd645e&sid=94c72790a7bcf6f534f95ba3c9bd645e#p302683

Das es da auch ein Problem gibt ist abschaltbar machen vielleicht doch eine gute Idee.

Ja, ich wollte hier suchen, konnte jedoch nicht, weil ich da noch nicht registriert war. Also hab ich mich durch die Registrierung gequält - war verwundert, dass der Account des Forums nicht mit mysteinberg gekoppelt ist - und danach hab ich die Suche im Forum hier tatsächlich vergessen.

My fault, sry! :unamused:

Hier zu suchen ist mir auch erst eingefallen als du davon geschrieben hast. Wie gesagt, google per default. Fest verdrahtet im Hirn. Ist wie atmen. :slight_smile:

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. :wink:

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”. :wink: )

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
1 Like