The ddrum4 multisample format

[Deleted]

Hi all,

I was thinking this thread would serve for sharing what is known about these .mid files the ddrum4 uses for multisamples.

When opening the file in a audio editor (as 8-bit), there is a "header" at the beginning with a length of 1212 bytes, then at every 589'th byte there's a sample at level 247 (F7h), which may tell the module to adjust the level according to the info in the first 1212 bytes.
If opened as samplerate of 44,1kHz, the duration of the file is shorter than when playing it using the ddrum4tool (even though the samplerate set in the ddrum4tool's audio setup is 44,1kHz) which indicates a compression using pitchbending. The attack of a percussive instrument requires full bandwith, but the decay does often not, so a fixed pitchbend could make a sample occupy less bytes (I have tried this with my ddrum3). The actual audio portion of the .mid files seem to be truncated to 8-bit, which indicates some form of swapping around of sample levels, maybe also referring to the data in the beginning.
It's a well known fact that digital audio gets more distorted at lower levels, and dynamic compression could lower this distortion, and even produce smaller files due to reduced bit depth, and that could be what they've done, like normalizing every x milliseconds, and then putting the amount of change of the level in the header. They only had 16bit back then, so they probably wanted to squeeze out every bit of resolution they could.

If there's anyone here on the forum that knows programming and stuff, maybe we could figure it out!

[After comparing what I've found with the findings of Bill Piland, I edited this post to be more correct]

[lite]

Hi krillo,

interesting thread. The Developer of the 2box software has posted a DOS tool which converts ddrum4 sounds into wave files:

www.2box.se/Downloads/ddrum4wav.zip

During conversion it shows some parameters which could be related to the things you've stated (see attachment).

There is definitely an audio compression. As the ddrum4 was released 1996 it can't be a highly sophisticated compression algorithm. The Developer in the 2box forum has written the compression was done with a very old Mac and that the codec was “nasty” (2box thread: www.2box-forum.com/index.php/topic,466.msg5726.html#msg5726). I've asked him to provide the old Mac tool but he has never replied. I think he was just interested to provide 2box owners a tool to continue using ddrum4 sounds on the 2box (people have asked for it). But maybe he is not interested to gain the ddrum4 capabilities as they want to sell their 2box stuff.

There is a guy who has started to alter values in the ddrum4 sound files and he evoked some effects on the sounds already. However he was not able to put in own samples:
www.2box-forum.com/index.php/topic,466.msg5766.html#msg5766

Clavia stock sounds are compressed by a factor in the ballpark from 4 to 6. If you load own (single-shot) samples into the ddrum4 it's less (only around 2 if I recall correctly). If you send your own samples into the ddrum4 you do it as standard MIDI sample dump. This means the ddrum4 compresses them on its own. If you send Clavia stock sounds they are already compressed before in the proprietary ddrum4 files on the computer.

As said, reverse engineering Clavia's proprietary ddrum4 multisample sound format would make the ddrum a true killer beast :-)

Please, someone? :-)

[lite]

.

Attachments:

[lite]

the tool states "type CDD4". I didn't find any compression codec across the web called this way :-(

[Deleted]

The developer is Rik van der Brugghen and he's working with 2box now, that's probably the guy at the 2box forum. I found his e-mail and even his cell phone number ;D maybe I should write him a line

[Deleted]

Dec 31, 2010 7:13:22 GMT -5 lite said:

the tool states "type CDD4". I didn't find any compression codec across the web called this way :-(

I'm wondering if the 4 in CDD4 refers to there being 4 sounds in the file?

Here's what I've found of old file compression for the mac:
en.wikipedia.org/wiki/List_of_old_Macintosh_software
en.wikipedia.org/wiki/StuffIt
* Compact Pro
* PackIt
* DiskDoubler
* StuffIt
Wouldn't think they work with audio. I have no Mac so can't test it

[lite]

You should definetly get in touch and make some swedish connection :-)

Stuffit is like ZIP. They all sound like non audio compression codecs.

The ddrum4 uses up to 8 samples for a sound. The Simon Philips Sounds for example are all 7 samples. I've imported them into the ddrum3.

Get that old Mac tool. I'll get the Mac for it :-)

[Deleted]

Dec 31, 2010 8:30:06 GMT -5 lite said:

You should definetly get in touch and make some swedish connection :-)

Stuffit is like ZIP. They all sound like non audio compression codecs.

The ddrum4 uses up to 8 samples for a sound. The Simon Philips Sounds for example are all 7 samples. I've imported them into the ddrum3.

Get that old Mac tool. I'll get the Mac for it :-)

I e-mailed Rik (aka Deve Loper) and he wrote basically what he already posted on the 2box forum, and he doesn't have the code What is the file extension for 86k mac files?

[lite]

you mean executables on old Mac?

[Deleted]

Dec 31, 2010 11:46:58 GMT -5 lite said:

you mean executables on old Mac?

yeah, I think it's .bin

[lite]

I dunno. I remember old Mac OS basically don't identify file types via three letter extension like DOS. Sometimes this is nasty when transferring sounds from a PC.

So we won't get/find the original Mac 68k tool?

If you have an interest of ddrum4 hi-hat detailed MIDI data for running hi-hat multisamples on the ddrum3 just let me know.

[Deleted]

I e-mailed Armadillo to see if they have that tool...
Here's a thought for those of you who have both the ddrum3 and 4: Is it possible to transfer multisamples from the 3 to the 4 without having to split them up?

[lite]

No, it's not possible. ddrum3 and ddrum4 sound formats are different.

Other we would have got a nice walkaround transfering own multisamples into the ddrum4 :-)

[Bill]

I have figure out some of the ddrum4 sound file format and parameters by trial and error – modify a parameter value, load the modified file, and test the changes. The files listed below provide details of what I have discovered. As far as I know, the ddrum4 proprietary compression algorithm has never been released to the public domain. I have no clue what compression algorithm was used.

I used one of my favorite snares (SNRE 222) as an example. This sound has five variations. Variation one is programmed for positional sensing with three samples. Variation two is programmed for velocity sensing with three samples. The other variations are programmed for velocity sensing with one sample.

You can download the following files from home.comcast.net/~bill.piland/site/. Click "DD4 Sound File Format" on the top menu bar.

ddrum4 Sound File Description.pdf - An overview of the sound file structure.

ddrum4 Sound File Format Example.pdf - This file demonstrates how to convert the binary data into a readable format.

DD4 Sound File Format_Packet 0.pdf - Packet 0 (the playback instructions) of SNRE 222 converted into a readable format with descriptions of the parameters that I have decoded.

DD4 Sound File Packet 0 Data_Table Format.pdf - SNRE 222 data formatted as a table (easier to read).

Please post any further decoding here. I hope that someone with programming skills can use this information to create an editing tool for the ddrum4.

Cheers,
Bill

[lite]

Hi Bill,

welcome! That's awesome. Thank You very much. Interesting to see that there're a lot of parameters stored with the samples I've never heard of. For example the sequence playback of certain multisamples. Unfortunately I am no software engineer. Would love to reverse engineer the audio compression.

It's quite interesting that the module itself is capable of compressing standard MIDI dump sounds into its own proprietary format but with less compression (ratio ~ 2) compared to the factory sounds (ratio 3 to 6). A ratio of 2 could indicate a simple data reduction like zip or rar. But I am sure the factory sounds have a true audio specific compression.