Create your own E-mu Drumulator sounds with these decoder / encoder tools…
E-mu Drumulator Sound ROM Creation Tools v0.60
Included kits (so far):
– Emu Drumulator Factory Sounds
– Digidrums – African Percussion
– Digidrums – Alternate Set 1
– Digidrums – Electronic Drums 1
– Digidrums – Electronic Drums 2
– Digidrums – Latin Percussion
– Digidrums – Rock Drums 1
– Akai XR10
– LinnDrum
– Yamaha RY30
Please do share any created kits here so that others may enjoy them!
Note: The tools are fairly automated and fool resistant, but the old adage holds true — garbage in, garbage out.
Technical Details
This is mostly information for developers, and will likely be of minimal interest to general users.
E-mu Drumulator Metadata Guide
The E-mu Drumulator instrument sound metadata is located within the program (Operating System) ROM. Specifically, the metadata is held in a 60 byte block found at the address range of $1EBC~$1EF7.
The metadata defines the properties of all twelve instrument pads. While the actual sounds can be replaced and are more-or-less arbitrary (tamborine for a rimshot?), the instrument pads generally correspond to the sounds below, and are referenced in this specific order throughout the metadata.
INSTRUMENT PADS
00 – Clave
01 – Cowbell
02 – Claps
03 – Open Hi Hat
04 – Closed Hi Hat
05 – Ride Cymbal
06 – Bass Drum (Kick)
07 – Snare Drum
08 – Rimshot
09 – Hi Tom
0A – Mid Tom
0B – Low Tom
OUTPUT CHANNEL ASSIGNMENT
The first 12 byte section ($1EBC~$1EC7) of the metadata block holds the assigned output channel for each of the twelve instrument pads. Each byte corresponds to one instrument pad and the order of the bytes follows the same sequence as the instrument pads section above.
There are eight possible values:
$00 = Lo Tom
$02 = Hi/Mid Toms
$04 = Clave/Cowbell
$06 = Claps
$08 = Ride/Cymbal
$0A = Hats
$0C = Snare/Rim
$0E = Bass (Kick)
While the instrument pads generally corresponds to their channel counterparts, it is possible to reassign any instrument pad to any output channel.
SAMPLE START POSITION AND SAMPLE LENGTH
The remaining 48 byte section ($1EC8~$1EF7) of metadata holds sample start position pointers for the sound data, as well as length values for each of the samples. The sample start position pointers and the length values for each instrument are always located at the same position within the program ROM and the metadata for the instruments are stored in the same sequence as the instrument pads section above.
In other words, each instrument is assigned a 4 byte region within this section and each region has an absolute address. “Clave” occupies the first four bytes, “Cowbell” the four bytes after that, “Claps” the next four bytes, and so on.
The first two bytes of each instrument’s region holds the sample start position. It should be noted that the values are in a “reversed” little-endian format, meaning that the two byte sequence should be read from right-to-left rather than left-to-right. It also seems to be be offset by -1, so the sound actually starts at the address one higher than the stored value indicates.
In other words, a value of $0C $00 within the ROM should be interpreted as $000C, and then $000D when adjusted for the offset, denoting the 14th byte within the sound ROM address space.
The last two bytes of each instrument’s region holds the sample length. As with sample start position, the values are in little-endian format, so the byte-order generally needs to be swapped. Equally important, the length is “complemented” (ones complement), so the value needs to be inverted (XOR’d by $FFFF) which can also be expressed as $FFFF – length in hex.
In other words, a sample length value of $FF9B would invert to $0064, denoting a sample length of 100 samples.
ADDITIONAL INFO
The stock sound ROM sounds happen to be arranged in the following order, but there is little-to-no specific reason for this layout as although the sound ROM data is split over four physical ROMs, the sound ROMs are addressed as one contiguous block, so it is possible for sound from one instrument to be span across more than one ROM. The metadata in the sound ROM area uses relative addressing, not absolute, so the start addresses are simply offsets within the sound ROM area, and consequently have a range of $0000~$FFFF (equal to 64K worth of total data). Also, each byte/address corresponds to one sample since Drumulator samples are stored as 8-bit values.
ROM A (1E, 16K) = RIDE/CYMBAL
ROM B (3E, 16K) = MID TOM, LOW TOM
ROM C (4E, 16K) = OPEN HAT, CLOSED HAT, SNARE, CLAVE
ROM D (5E, 16K) = HI TOM, KICK, RIMSHOT, CLAPS, COWBELL
While the metadata is stored in a specific order, there is little rhyme-or-reason to the order in which the actual sound data is stored. Other than the requirement for each individual sound to be stored in linear fashion (not broken into chunks or scattered), the order which the sounds are stored within the ROMs is arbitrary because the metadata can point anywhere within the ROM. For example, the snare sound might be the first sound within ROM, the last, or somewhere in the middle.
In fact, there isn’t even a requirement that 12 unique sounds are present, as the same sound data and/or metadata can be shared among multiple instrument pads, so it is technically possible to reuse/recycle sound data between the pads. As an example, a full drum loop could be stored into sound ROM and triggered in its full length by one instrument pad, and then chopped into smaller pieces by other instrument pads.
A more common use of this would be to have the same sound shared between a couple instruments which allows one or more other instrument sounds to be longer by “stealing” space which would otherwise be occupied by that instrument.
For example: Rimshot can use the same start pointer and length value as Snare which then allows Bass Drum to be longer by the amount of samples that Rimshot would have used. In this case, the Rimshot and Snare pads will play the exact same sound.
Many more ideas and configurations are possible, and the DIGIDRUM kits actually incorporate a few of them.
NON-SOUND DATA
While the metadata is stored in program ROM, the sound ROMs also contain extra data which is not strictly sound data. Each of the stock Drumulator sound ROMs contains non-sound data in their first 12 bytes. This is of little consequence as the instrument sounds can begin anywhere within ROM and be of any length.
Similarly, most or all DIGIDRUM sets have copyright data embedded at start of sound ROM A. In some kits, the last few bytes of ROM seem to be unused/unreferenced/non-sound data of unknown purpose or utility.
METADATA VALUES FOR STOCK/FACTORY OS V3.0
| INSTRUMENT PAD | ACTUAL SOUND | OUTPUT CHANNEL | CHANNEL CODE |
|---|---|---|---|
| Clave | Clave | Clave/Cowbell | $04 |
| Cowbell | Cowbell | Clave/Cowbell | $04 |
| Claps | Claps | Claps | $06 |
| Open Hat | Open Hat | Hats | $0A |
| Closed Hat | Closed Hat | Hats | $0A |
| Ride/Cymbal | Ride/Cymbal | Ride/Cymbal | $08 |
| Kick | Kick | Kick | $0E |
| Snare | Snare | Snare/Rim | $0C |
| Rim | Rim | Snare/Rim | $0C |
| Hi Tom | Hi Tom | Hi/Mid Toms | $02 |
| Mid Tom | Mid Tom | Hi/Mid Toms | $02 |
| Low Tom | Low Tom | Lo Tom | $00 |
Clave:
Start ($1EC8/$1EC9): $B84E (+1 with offset) = 47,183 bytes in
Length ($1ECA/$1ECB): $F850 ($FFFF – $F850 = $07AF) [1967 samples]
Cowbell:
Start ($1ECC/$1ECD): $F548 (+1 with offset) = 62,793 bytes in
Length ($1ECE/$1ECF): $F54B ($FFFF – $F54B = $0AB4) [2740 samples]
Claps:
Start ($1ED0/$1ED1): $E6B4 (+1 with offset) = 59,061 bytes in
Length ($1ED2/$1ED3): $F16B ($FFFF – $F16B = $0E94) [3732 samples]
Open Hi Hat:
Start ($1ED4/$1ED5): $800B (+1 with offset) = 32,780 bytes in
Length ($1ED6/$1ED7): $DE1F ($FFFF – $DE1F = $21E0) [8672 samples]
Closed Hi Hat:
Start ($1ED8/$1ED9): $A1EB (+1 with offset) = 41,452 bytes in
Length ($1EDA/$1EDB): $F62F ($FFFF – $F62F = $09D0) [2512 samples]
Ride/Cymbal:
Start ($1EDC/$1EDD): $000B (+1 with offset) = 12 bytes in
Length ($1EDE/$1EDF): $C00C ($FFFF – $C00C = $3FF3) [16,371 samples]
Kick:
Start ($1EE0/$1EE1): $D78D (+1 with offset) = 55,182 bytes in
Length ($1EE2/$1EE3): $F9F8 ($FFFF – $F9F8 = $0607) [1543 samples]
Snare:
Start ($1EE4/$1EE5): $ABBB (+1 with offset) = 43,964 bytes in
Length ($1EE6/$1EE7): $F36C ($FFFF – $F36C = $0C93) [3219 samples]
Rimshot:
Start ($1EE8/$1EE9): $DD94 (+1 with offset) = 56,725 bytes in
Length ($1EEA/$1EEB): $F6DF ($FFFF – $F6DF = $0920) [2336 samples]
Hi Tom:
Start ($1EEC/$1EED): $C00B (+1 with offset) = 49,164 bytes in
Length ($1EEE/$1EEF): $E87D ($FFFF – $E87D = $1782) [6018 samples]
Mid Tom:
Start ($1EF0/$1EF1): $400B (+1 with offset) = 16,396 bytes in
Length ($1EF2/$1EF3): $E3EA ($FFFF – $E3EA = $1C15) [7189 samples]
Low Tom:
Start ($1EF4/$1EF5): $5C20 (+1 with offset) = 23,585 bytes in
Length ($1EF6/$1EF7): $DC44 ($FFFF – $DC44 = $23BB) [9147 samples]
