Skip to content

Decoding Yamaha EMT-10 samples & voices information

Technical discussion which is not directly related to VGM files. Talk about Hardware and Software.

Moderator: Staff

Decoding Yamaha EMT-10 samples & voices information

Post by RomplerDumper »

With a lot of interest I've read the thread about decoding the Yamaha TG-100 GM rompler here so I thought I might be able to grab the attention of some guys to help decoding another Yamaha rompler? :D

The EMT-10 is a rather cheap device, but I need these exact sounds for personal reasons. Instead of sampling, I wanted to grab the samples from the chips to have the best possible quality without noise etc.

The device is a PCM rompler with "AWM" technology, only has 12 patches in three variants (default, bright, mellow), is supposed to have 12 bit samples (which is not 100% correct, see below) so I thought it might be similar to the TG-100. But apparently it is not.

The unit has three chips with 8x512k of wave rom data and another 8x128k chip with presets configuration (and probably the firmware code for the CPU is in there, too).

I successfully desoldered and dumped all four chips and I have been able to extract the samples already. The encoding for the samples is 8 bit DPCM which results in about 11-12 bits of sample data. Due to the encoding, some samples have a non-constant DC offset (they drift away) but a simple high pass filter fixes this.

The first wave rom starts with a LUT that specifies the offsets for the samples in 16 byte blocks. Sample length, and loop information (start & length) are part of the wave rom data too and are in front of each sample. There is more information in there but I have failed so far to decode these, I am not sure if I need that data.
Sample headers (part of the Wave ROMs, in front of each sample)
Sample headers (part of the Wave ROMs, in front of each sample)
Now for the part that I am stuck with: Forming voices from the individual samples. The total data size for the preset definition is about 88k, this surprises me as it is plenty of data for just 12 (36) patches and at that time (1988/1989) memory was still costly I guess. Maybe the unit is just very stupid and that definition defines the used samples for each note.

The firmware/preset rom starts with an address table (uint16s) with 36 entries, which makes sense as the unit has 12 patches with three variants each. But them I'm stuck. There is a table of length 128 for each of these entries, followed by multiple entries (20-30) with two data blocks: One is always 32 uint16s in size, and then another one between 52-68 uint16s. Some of these values seem to be addresses in the ROM, it can clearly be observed when this firmware is loaded as 16 bit in a wave editor. This seem to be addresses of sample start positions, I checked some of them and they seem to match if multiplied by 256.
firmware_waveeditor.png
As I am guessing that I am not allowed to upload the binaries here the question is how you can help if you wanted to? Maybe this data format sounds familiar to anyone?

Post by RomplerDumper »

Some additional information about the firmware: All 16 bit integers are stored as little endian = intel byte order

The dark blue part is the address table, it needs to be multiplied by 0x10 to get the offsets in bytes, 36 entries (highly possible one entry per patch)

The yellow part exists once per patch, has a length of 512 bytes (or 256 16 bit ints) an may be another LUT into the sections following afterwards.

For each of the following entries (29 for the first patch), there is one table with 32 entries (light blue, 64 bytes) and then a list between 52 and 68 entries (green part) with contains sample addresses but also other data.

What I want to decode: Note => Sample relation to be able to create a multisample SFZ per patch. What I also know is: The device can blend two samples based on velocity, so it is likely that there is more than one entry per note
Attachments
firmware_hxd.png
Post Reply