I don’t think that coding the firmware to be able to convert and store files in a different format is a trivial task, and I’d assume it’s out of the realm of feasibility as far as an unofficial firmware update. I’m not a coder though, and have no idea if the process of conversion on the fly would sound any different than storing pre-converted audio. Yes it does store files as 16 bit and playback at 12. Part of the point of getting a +drive is getting around space limitations, the MD is a drum machine so longer samples were probably never intended. As with any vintage gear, if you’re using it decades down the line you should probably be prepared to deal with certain limitations. As for whether sampled audio is stored in 16 or 12 bit though, I have no clue and would be interested in knowing.
Haha, I was about to do the same test plus with an added 8-bit file analysis, but, please, carry on
Mirroring my reply from the MCL repo here per request:
I’ve experimented with this a bit.
Awave Studio can convert to 12bit SDS, so I used that to convert a 16bit mono 32 kHz WAV file, which was originally 433 kB. After conversion, it came to 459 kB, however to my understanding it’s only bigger because of the SDS header, so I figured if MD discards the header during the transfer it shouldn’t be a problem.
Unfortunately, no matter the bit depth, the file still appeared as 433 kB on the MD itself.
I hope it’s possible to work around this too.
OK, I found a couple of interesting things.
First of all, I sampled a beat I made by connecting the output to input A and I recorded for 1.93 seconds at 44.1kHz and I got 85280 samples. The resulting RAM data shows as 166K. 16bits or 2 Bytes x 85280 samples = 170560 bytes. Considering a KB is 1024byte, 170560byes = 166.5625 KB. Which is same as what it shows in the sample manager.
The interesting part is when I dumped this sample to PC and analyzed it in iZotope RX 11 and Bitter, it shows up as a proper 16 sample:
Which means the notion that MD samples at 12bits seems like not correct.
Now this test only checks the A2D converter and how the data is stored.
It seems like it’s proper 16 bits. So what’s this 12bit the manual is talking about?
Maybe the output D2A is 12bit or sample playback is 12bit somehow?
To check this, I copied the 16bit RAM data to ROM and used a ROM Machine to play the 16bit sampled audio and sampled that again. I made this to check if maybe the the initial beat I made with TRX machine modelling was able to create a 16bit audio and maybe that’s why I got 16bit data?
No, when I recorded the ROM machines supposedly 12bit playback and through the supposedly 12bit D2A output into RAM and transferred that sample to PC and analyzed that, it also created a proper 16 bit audio. Here is how it looks in Bitter:
So this is quite interesting. It looks like everything is 16bits.
Recording, Storing, Playback and Output are all 16bits.
So what is this 12bit playback the Manual is mentioning?
There is also another inconsistency. The manual indicates the following: The S/N ratio for a MKI unit outputs is 91dB
Using the formula SNR (dB)=6.02×bit depth+1.76, we get effective bit depth of the MK1 outputs as roughly 14.8 bits. Which makes sense for a dynamic range of a 16bit D2A interface and not for 12 bits.
I can not find anything 12bit in my mk1 MD.
However, when I created some files with 12bit dithering in izotope rx, i couldnt tell the difference, they sounded great, while Bitter was easily able to show the difference.
Here is how a 16bit file carrying a 12bit dithered audio looks like:
So what is this 12bit playback the Manual is talking about?
Is it about keeping the expectations low?
Now after all this, I still wouldn’t mind a custom firmware feature to make the MD to use 12bit samples, like an old AKAI S900 or an MPC60 for true Lo-Fi goodness and %25 more storage :-).
Hoping to wrap everything up, I made a final test. You see that above Bitter image about this 12 bit sample, I sent it to MD, then played it back as a ROM machine and recorded it to a RAM machine and transferred the sample back to PC, and how do you think the output looks like? It should look like the above 12bit image right? No! it looks exaclty like a proper 16bit audio.
Here is how the 12bit audio looks like after playing and recording the output it back into MD.
It looks like a proper 16 bit audio.
This tells me there is definitely some dithering going on and all my assumptions about everything being 16bit might be wrong afterall. The interesting part is that when I dither a 16bit file to 12bit and back to 16bit, it shows as 12bit in Bitter as expected. I guess a 12bit audio going through D2A and back into A2D makes it look like 16bit with noise shaping and additional dithering.
I might do more tests with RME’s Digicheck and REW tomorrow. However one thing remains true, 12bit drums sound great and I still think it would be a great feature to give %25 more storage, enabling 12bit storage and proper 12bit playback.
Hi em,
I tired this too following your comment with Awave Studio 11.6.
It was nice to use Awave again. I think last I used it was in the 90s with an Akai S3200 
I’m not quite sure if it can convert an 16bit audio to 12bit SDS. I think you’re mentioning the 12bit setting for SDS file export, right?. It looks like it’s only for the header of the SDS file, I’m not sure what’s going on. It can export an 8bit wav though.
I think we either need to convert the audio data in the Awave waveforms area from 16 bit to 12bit somehow, which I couldn’t find an option to do in Awave, or we need to externally dither an audio to 12bits and put it into Awave and export a proper 12bit SDS then. The problem is I can not find any way to save a 12bit audio at all. I can create a 12bit audio in izotope rx but it can not export a 12bit file. Same for Audacity as well.
However here is what I did. I imported my file into Audacity and exported the file as an 8bit unsigned PCM wav file. This truely made a half sized audio compared to the 16bit file since 16bit to 8bit should be half. The 167KB, 16bit wav file became 84KB, 8bit wav. I then imported it into Awave and exported it as an 8bit SDS file but the resulting file became a 177KB SDS file so I ditched that idea. However, I decided to transmit directly from Awave.
I set the SDS transfer settings as 8bit and transferred the 8bit audio from Awave into MD but unfortunately the resulting audio became 166KB again in MD. I also compared sending the following; 8bit 84KB file transferred as 1422 packets in 63 seconds and 16bit 167KB file transferred as 2132 packets in 95 seconds. This tells me I was able to send 8bit audio to MD but it still converts and stores it as 16bit.
As far as I remember from back at the time, the 12bit of the mduw is an emulation: everything is done at 16bit and the 12bit aspect is done in software rather than being a true 12bit conversion.
And with storage Elektron said this:
“12 bit samples loaded into the Machinedrum will take actually take the same amount of storage space as 16 bit samples will. If you want to save space I recommend to convert the samples to 22 kHz.”
Very interesting. But it still makes no sense to me. If you’re reducing to 12bits, no matter how, there still shouldn’t be a need to store in 16bits and lose %25 of storage. I think there has to be a reason.
From your explanation, all I can understand is that it wasn’t a technical limitation but more of a choice, but for what reason? Optimization of something but what? Are you saving precious cpu cycles somehow maybe? I don’t think so. Also which part of the operation is 12bits we’re still not sure.
The problem with reducing the frequency in my opinion is that it has quite a big impact on the audio quality. However, reducing the bitdepth you still get a beautiful sound.
I probably should have used the word emulation rather than done in software - that should make more sense?
yeah, if you think of playback as “emulation” and think that it is trying to emulate 12-bit drum machines, going for lo res æstethics, and as an extension of the E12 machines, then that choice hopefully makes sense.
Yes. That is the point of the engine’s emulation of the SP1200, etc. It is approximating the sound of a 12 bit sampler in playback.
Is that of any actual significance? It was easier for Elektron to manage 16 bit samples through the audio engine and DSP56303AG100 to whatever DAC.
If you have questions about how easy it is to rewrite this engine for additional storage capacity, bring it up with the developers of the alternate firmware, or perhaps ask on the MDX Discord.
You do not understand, that itself is understandable, but you are missing fundamental information about how the MD works at a very low level and the way to get around that is to research over any of this back and forth.
I could guess at aspects like the DSP chips also working at 16 bit, better headroom for the engine, there are many reasons that could validate this design decision versus refusing to accept the design that exists because you would really really like more storage space.
Wanting that is fine but really beyond any point unless it’s to be used as a cudgel to somehow argue that Elektron should rewrite the engine for you, in which case, eh. Why bring that suffering on yourself?
It doesn’t sound fun and it certainly isn’t useful.
Dude, why the condescending tone? Why are you making it personal? Not understanding things and encountering things that don’t make sense have always been important to me—they’ve always shaped how I grow and improve. But you seem to have a problem with that, like you can’t stand the idea that some things don’t immediately make sense. That’s your problem man. Keep it to yourself. This thread is about storing 16bit samples in a 12bit system.
What kind of talk is this? like you have a profound insight? quite pretentious, not necessary and honestly very inappropriate.
I never said I have such questions. I started developing in the 80s and I have developed firmwares for years for microcontrollers and FPGAs. Probably you haven’t read above, I already stated I made a post about this subject at the custom firmware project. I also used a mention to the developer in this thread but you probably missed that part as well.
where you are getting your information? Do you have a source that I don’t already have access to?
So you can guess but I can’t express something not making sense to me?
You should really read the thread more carefully because at no point I expected or requested this. I can’t understand how you came to this conclusion.
I really don’t see the point you’re trying to do here.
The only relevant point you made in your reply is “There should be a reason why they did it that way, just accept it and don’t worry about it”
For people who can not think out-of-the-box like you, I’d like to remind that not thinking this way made it possible for fans to unofficially add compressors to a 20 year old device with better firmware. Companies can only spend a certain amount of time and resources for software development on a specific hardware. This doesn’t mean that the software is perfect. It means it is just enough for a company to sell its product with the advertised/promised features. The more the development, the more expensive the product becomes (or the next product). At that point, the company has to work on other products since the return-on-investment will be better with new products. It is quite normal and technically expected that a firmware of any product is not as good as it can be. This is the nature of the world we’re living in.
Bottom line is, if you still prefer using Elektron’s firmware, even when there is a better fan made firmware, then go on and continue using that. I won’t do that. I like the idea to improve and upgrade classic hardware with newer technology.
I totally agree with this. However, I don’t think the 12bit approach was a preferred choice for going “traditional” but rather a marketing talk in my opinion to find a good wrap-around explanation for the lack of dynamic range and frequency response of the device.
Here I made an analysis of the best frequency response the mk1 MD can make using the A2D.
The red line is Apogee Ensemble’s response and the pink line is MD response using input gate machine for sweep analysis.
I am quite sure this terrible frequency response is due to the A2D and not the D2A of the MD.
Infact I also discovered some unexpected interesting things as well. For best fidelity, routing volume must be at most 33 and input volume must be at most 35. Otherwise both add interesting distortions to the spectrum at different points. Quite fascinating imo!! The track volume has no distortion effect and the master volume has no distorting effect as well. But Accent volume increase also has other distortion as you’ll see below This was a really intereating find.
Anyways, i really don’t think the lack of frequency response is that bad actually. Especially considering this limitation definitely makes you or the MD inherently more creative It just is, becasue the moment you take any audio in, you start messing around with the filter, distortion and the EQs and the sound becomes more interesting. Also, you can see the SNR is quite bad in this analysis. This is probably because this test has both A2D and D2A together.
I was also able to just check the D2A alone but only for SNR.
I used a GND-SN machine to create a SIN wave at 1kHz. Typically that’s how the industry checks the SNR. Measure the noise without signal and compare it with best signal.
This is the noise floor: White is MD noise, pink is my interface response curve.
This is the signal at 1kHz:
And this is the highest possible signal by using Accent. Seems like accent also adds some interesting distortion (The part behind the dialog)
So doing a simple calculation:
Signal Level: -2.12dBFS
Noise Floor: -68.8dBFS
SNR = Signal Level − Noise Floor
SNR = −2.12dBFS −(−68.8dBFS) = 66.68dB
Bit Depth = (SNR+1.76) / 6.02
Bit Depth = (66.68+1.76) / 6.02
Bit Depth = 11.36
So the effective SNR of just the D2A, without the A2D, with signal from internal sound engine seems like is 11.4 bits. This only gives an idea about the bit depth of the usable signal the device can produce not what the device does inside.
However, no matter how the sound is processed internally, the usable signal technically is less than 12 bits meaning storing samples in 12bits should not pose a quality loss, at least for mark1 devices.
I think in terms of marketing, it would have been terrible if they said “for more storage we decided to use 12bit samples” It definitely would have made the Machinedrum look bad. Also, saying it emulates 12bit machines is so clever.
Technically, it makes no difference if the samples were stored in 12bits becuase the device can not reproduce even 12bits of usable signal.
So funny, I’m just realizing this now that back in the day, this is exaclty what the early sampler brands did. Storing samples in 12bits I mean.
- Akai S950: It used the .SND file format, which could store 12-bit samples.
- Ensoniq EPS: It used the .EPS format, which supported 12-bit audio.
- Emu SP-1200: The .SND file format was also used here, with 12-bit resolution.
These formats were specific to the hardware and allowed for the storage of 12-bit audio data.
Ok, here is one more argument.
Technically you can send a sample to your MD, process it there, and receive the sample back. This is a feature of the device. That’s why the device can dump the samples back. It can receive, process and send back 16bit samples.
Would anyone in this day and age use it that way? I don’t think so
What I mean is, the way samples are always used with this machine is, you send your sample to it and never receive it back as in it is quite irrelevant if your 16bit sample becomes 12bits. So this feature, that it can process your 16bit sample and give a 16bit sample back is completely useless.
So my argument really is, if the machine internally converted the received samples to 12bit, it won’t matter to you in any possible way. You will not be wanting to receive your sample back anyways and you will not be able to hear the difference at all anyways (check my above analysis).
I hope this makes sense.
Perhaps the fairly unique sound of the MDs USerWave format is due to the audio starting at 16bit.
Got me wondering if the 12bit playback actually begins at the BRR parameter…!? 0 is 12bit then down from their towards 127.
This would mean any pitch modulation is using full 16bit giving the BRR more information to play with….
Might be totally wrong and it’s 12bit straightaway.
Regardless, LLM copy and paste results are banned around here but I got a pretty decent explanatory response prompting about the machinedrum chipsets 16bit architecture and options to convert storage to 12bit.
If you get a chance it’s worthwhile as it may help you process why the choice was made, and how it’s not a simple/practical/performatively viable little change in the code.
I really don’t think it’s doing much about emulation as we think about emulation today like convolution or anything involving heavy processing. When you’re working with limited bandwidth and dynamic range you have to cleverly let’s say “mold” the sound anyways both in hardware and software. That’s what the older samplers did you know. Like noise shaping and filtering controlling harmonics and distortion as much as you can. There is nothing special about these techniques.
The device I believe is working completely in 16bit; input, synthesis, processing and output. It just don’t have much dynamic range and the resulting usable signal is about 12bits. I believe that’s the whole story.
I really don’t think there was a unique choice other than about making a great sounding device with great features. Technically it has bad dynamic range and bad SNR but that is really irrelevant since it does its job quite good. Also, it has enough fidelity to do its job. They used parts that technically and financially made sense for that time. And they beautifully explained it as nostajic emulation as part of the marketing.
What I’m saying is, especially after all the analysis, that the device is a proper 16bit device and it wouldn’t make a difference if it stored the samples in 12bit, other than the additional storage.
AFAIK the 12-bit playback was a creative choice and use the same (or at least similar? μ-law?) type of PCM algorithm as the SP-1200.
This is of course strictly the sample playback, the rest of the Machinedrum operates at a higher resolution.