Exporting MixDown to create a sample for Korg DSS-1

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:

RIFFHî WAVEJUNK fmt €» w data î


Anyone know what this is and how I can remove it?

Thanks,
Nick

Don’t know what it is, but I deleted it here in Wordpad. But after doing so, it won’t play in WMP.

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.

Thanks
Nick

NWP, Just realized (duh)that what you did was using a WAV from Cubase to test. Disregard my previous message.
Thanks,
Nick

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.

http://www.sonicspot.com/guide/wavefiles.html

http://www.daubnet.com/en/file-format-riff

Does anyone know if there is a setting where I can turn this off?

Like I said, it can be edited in Wordpad. Did you try deleting it there?

Yes, but then the sample becomes unusable even in Cubase. I just deleted the actual characters JUNK but not the spaces after it.

I got a file without the JUNK header :imp: so it is possible, but I don’t know if it would work for what you want. Answer’s in the Export dialog. :wink:

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?

Wave64

Was a little miffed at having wasted Sat AM guitar time on this. :laughing:

Ahh…ok…no that won’t work for me, it has to be in wav format. Sorry about the lost guitar time…maybe play some speed metal to catch up. :slight_smile:

Wave64 is wave format. The file sizes are exactly the same. Did you try it?

Yes…same results, bad header on the DSS-1.

I submitted a request with Steinberg Support…hopefully there is an option somewhere…if I even ever hear back from them.

Just tried in C4, it doesn’t export with the JUNK header.

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.

Regs
Marcus

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.