I uploaded a 16-bit sample to my Machinedrum. According to the manual, the sample only plays at 12-bit resolution.
This implies that either C6 or the MD itself converts/dithers the sample to 12-bit during transfer. That makes sense since the MD likely stores samples in 12-bit depth to optimize its limited RAM, right?
However, what confuses me is that when I transfer the sample back to my PC, it’s still 16-bit. And I don’t mean a 12-bit file padded to 16-bit—I’m getting back the exact same file I originally sent.
Using Stillwell Audio’s Bitter plugin to analyze it, I can see that the received file isn’t 12-bit dithered and back. It still contains a full 16 bits of audio data.
To double-check my measurements, I dithered a 16-bit file down to 12 bits, then re-dithered it back to 16 bits. When I analyzed it with the Bitter plugin, I could clearly see the loss of bits during the process.
This tells me either MD only dithers a 16bit sample to 12bits realtime during playback, or it’s actually playing back a 16bit sample internally but they used a cheap D2A that can play 16bits but only has a resolution of 12bits?
Any thoughts on what’s happening here? It seems like the MD is storing the samples as 16bits. Either case this makes no sense to me.
Don’t get me wrong, 12bit drums still sound great but I would have preferred to be able to actually store 12bit samples and save some space at least.
The manual says: “All bit depths are accepted but will be played back at 12 bit.” (See SAMPLE MANAGER (UW MODELS ONLY) on page 71).
When you sample on the MD, it samples at 12-bit. But you can transfer 16-bit samples to it, and they’re stored as 16-bit, and can be transferred back out as 16-bit.
I think whatever you transfer is stored unchanged, so if you want to save space on the + drive you’ll need to convert them to 12-bit before transferring them.
You might want to pose this question to those guys who wrote the unofficial firmware, I’d think that if anyone would know, it’s probably them. I think if anyone is actually left at Elektron who would still know the specifics of this, they’d probably be pretty tight lipped (given the way they handle inquiries about their proprietary technology).
Not saying that members won’t have good input or feedback, but I suspect that it’s all going to be guessing. I think those guys who worked on the unofficial firmware got a pretty in depth look at things and might be able to give a more direct answer.
Hi @PofM, that’s exactly how I understand it as well, but it makes no sense to me. Why store it as 16-bit and waste a quarter of the minimal storage if only 12 bits are ever used? This is a design question I should have asked Elektron 20 years ago, but it still puzzles me.
Yea, unfortunately it doesn’t work that way. The problem with 12bit pcm/wav files is that there isn’t a file standard where you can store a 12bit audio as a 12bits file. You can at best store it (with dithering or with padding) in a 16bit file but then it becomes a 16bit file carrying 12bit audio information and the file size is still 16bits.
I think that could be the case too, but it would also be poor and rather irresponsible coding since a simple software improvement could boost storage efficiency by 25% without any loss in audio fidelity.
I think you’re taking this rather emotionally. I don’t think you can know it if was purely a limitation of technology. Look, I think they managed to came up with a great composition of components and parts that we clearly know which actually worked and lasted very well. However, I’m also sure you know the saying “if it’s not broken, don’t fix it” They obviously had their reasons. There is no dissappointment, but we clearly know now that compressor(s) would have been possible with resources spent on software development which they never chose to do.
However, I’m not overlooking the fact that they continued supporting their discontinued gear even after releasing newer replacement versions, something they certainly didn’t have to do. While I’m not sure about the new management, in my opinion, they historically did an excellent job.
The interesting point is that it seems like they were able to get away with this storing 16bit but only utilizing 12bit situation since I think this point has never came up before.
@JustinValer
I left a comment about this on the custom firmware development project. If this is something left out by the engineers for whatever reason, just like the compressors and could be implemented with firmware, then it is great. But if there is a real technical reason why it won’t be possbile to store samples as 12bits and gain %25 more storage space, too bad, you know?..
Nevertheless, we are talking about the devs/managers who did not include compressor on a drum machine when they actually could so I wouldn’t be surprised if they left this out as well and I really don’t think it has anything to do with how much love and thought went into designing the MD.
Yea I know but that thread is about how to get best use out of the limited storege.
No one is even talking about the fact that samples are needlessly being stored as 16bit when they actually should be stored as 12bits.
people are talking about it and have given you the answer, add efficiency to this too. “needlessly” and “simple software improvement” mean linking : "It should be simple to code"
Yes, exactly my argument. Thus I am wondering, instead of simple coding, with better coding maybe %25 more storage might be possible. You’re concentrating on protecting what Electron did for whatever reason. I am concentrating on the inefficiency and figuring out the possiblity to get %25 more storage.
The truth is, about this 12bit data taking 16bit space, I thought maybe transferring a 12bit SDS file might be possible, if MD can actually store 12bit data somehow with its current firmware.
To test this, I will now sample something in MD, transfer to non-volatile memory (sorry I can’t get myself to call it ROM as Elektron calls it) then transfer it to PC and analyze the audio data in the wav file. also will try to dump the ram data to PC and test that too. which I think will take out the importing-16bit-samples out of the equation and might shine some light on what’s exactly happening internally as in if the device is even currently able to store its 12bit sampled data as 12bits or 16bits.
