If I recompile the code using 32787 and do the same, the remaining signal is higher (about -43dB as opposed to about -70dB with 32767). I have to zoom right up vertically to see it in Sound Forge. However, if I open both in Sound Forge (audio editor) and invert the phase of one and merge it with the other (aligned to the exact sample) there is still a signal - albeit very, very low. Decoding the D-50 ROM with the code I posted above creates good results. Roland also make a VST of this instrument and in the resources section of the dll is the original ROMs already decoded (or can get with a memory dump). Try to change it and see if it gets bit accurate now? Though tbh, that kinda looks like a typo in the MUNT code.ĮDIT: Most likely not a typo! I see the same value in the integer LA32 code too.Īlso how do you know if it's bit-exact or not? What kind of reference do you have? I noticed that on line 18, the '32767.0f' part is actually '32787.0f' in MUNT. Sergm said in another thread that I'd need to loose the float calculations and use a LUT and pointed me to the Tables.cpp file in mt32emu. This code produces almost perfect results but not bit accurate. Id love to see it as Sonar beat Logic in some respects. Copy code to clipboard 1 for (int i = 0 i > 1 & 0x3F80 ġ5 ordered_sample |= raw_sample << 1 & 0x007E ġ8 double float_sample = pow(2.0f, (((ordered_sample & 0x7FFF) - 32767.0f) / 2048.0f)) ġ9 sample_data = (int16_t)(float_sample * 32768.0f * ((ordered_sample & 0x8000) ? -1.0f : 1.0f)) A few years ago, Cakewalk tried to create a Sonar version for Mac OS, but it was ultimately.

Roland d 50 emulator mac