Can anyone help with this? I have been trying to export/mixdown to a wav to use on my Korg Dss-1 Hardware sampler, but when I try to read it on the Dss-1, I get a BAD HEADER error. When I looked at the wave file with a text editor it is adding this at the top of the file:
Thanks for trying that…I,m not sure if that header is normal or not, but I also created a wav file in Wavelab and had the same results…can you do me a favor when you get a chance, can you check one of your existing wav files to see if it has a simiiar header.
It looks like Steinberg adopted this optional format for CD-ROMs which includes this JUNK chunk in the header . I checked some of my older wave files from Cubase 4 and it did not have it.
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.
Hmm…I thought I tried every combination , assuming you are talking about the export audio mixdown pane…I still cannot remove it…What settings did you use?
I had the same issue and posted this in the german forum - ended up with the same request: please create an option to turn off JUNK Chunks in WAV Export.
Meanwhile my workaround is to open up the WAV file in a Waveeditor and save it (overwrite). My WAV editor removes the JUNK Chunk. I’m using free Free Nero WaveEditor ( http://nero.com → Downloads ) because it loads/closes really quick and does the job.
And so here again: It has nothing to do with sector alignment for CDs.
The JUNK chunk is there to reserve additional space after the 32-bit RIFF header, so that the 32-bit RIFF header can be overwritten with a header of a 64-bit file format, like RF64 (RIFF, 64-bit - as specified in “EBU-Tech 3006-2007”) or BW64 (Broadcasting WAVE, 64-bit - as specified in “ITU-R Recommendation BS.2088-1”), in case the file gets larger than ~4 GiB during recording.
Obviously, the 64-bit file formats have larger headers, because they have to accomodate for larger length fields. Therefore, when starting out with a 32-bit RIFF WAVE file, it is often wise to reserve some additional space in case you need to grow the headers afterwards, when the file gets larger. The JUNK chunk marks that space as reserved (and to be skipped by utilities reading the file) until it’s needed.
The specifications above explicitely mention reserving space after the 32-bit RIFF header for the 64-bit extensions using a JUNK chunk and, as the file gets larger than ~4 GiB, overwriting both the 32-bit RIFF header and the following JUNK chunk with the header of a 64-bit RIFF extension.
I agree with you that it should be possible to turn this off though, since, as you mentioned, especially hardware units often won’t implement the full RIFF specification, but instead expect some sort of minimal or “canonical” format where certain information is stored at some very specific offsets - even though the “full” RIFF format itself is actually very flexible and “dynamic”, and allows almost everything to be “relocated” inside the file.