I noticed that on line 18, the "32767.0f" part is actually "32787.0f" in MUNT. Try to change it and see if it gets bit accurate now? Though tbh, that kinda looks like a typo in the MUNT code.
EDIT: Most likely not a typo! I see the same value in the integer LA32 code too.

Also how do you know if it's bit-exact or not? What kind of reference do you have?

Could you please elaborate to what extent do you observe differences from the reference samples?

P.S. If you care about portability, rows #4 and #5 could be slightly improved.

8bitbubsy wrote on 2020-10-13, 19:34:

I noticed that on line 18, the "32767.0f" part is actually "32787.0f" in MUNT. Try to change it and see if it gets bit accurate now? Though tbh, that kinda looks like a typo in the MUNT code.
EDIT: Most likely not a typo! I see the same value in the integer LA32 code too.

Also how do you know if it's bit-exact or not? What kind of reference do you have?

I have the PCM ROM(s) from a D-50 synth. 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). Decoding the D-50 ROM with the code I posted above creates good results. 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. I have to zoom right up vertically to see it in Sound Forge. 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). So 32767 wins in this case.

sergm wrote on 2020-10-13, 19:40:

Could you please elaborate to what extent do you observe differences from the reference samples?

P.S. If you care about portability, rows #4 and #5 could be slightly improved.

Thank's for the portability tip. It's really just a personal project but I may as well improve it where possible.
Hopefully the reply to 8bitbubsy answers the observe differences but if not, let me know and I'll post screenshot or audio of the difference or something.

I see.

One problem here is that you can't know for sure if the decoded D-50 PCM ROM in the VST is bit-accurate to how D-50 is decoding its encoded ROM in realtime. It's possible that the original D-50 is using tricks to save chip manufacturing costs or to make the decoding faster, while Roland decoded the ROM in a different way for the VST. Just a guess, anything is possible here when you don't have it confirmed...

Is the D-50 even operating in 16-bit PCM?

The difference between the decoded data from Roland and the self-decoded ROMs is so tiny that it makes me think it's just the decoding code that's not quite there. Maybe it's a rounding difference or something.

clearcase wrote on 2020-10-13, 20:36:

The difference between the decoded data from Roland and the self-decoded ROMs is so tiny that it makes me think it's just the decoding code that's not quite there. Maybe it's a rounding difference or something.

Yeah, that's what I mean. Try to figure statistical data from the differences, like mean and std deviation. Excel-like spreadsheet should help 😀

If the differences are rather substantial, I'd not think about rounding errors but about Roland using a different technique when producing the VST data.

Thanks for all the help, I reckon the results are close enough and it's not known how the decoded data from the VST was derived anyway a you say. I had originally assumed they'd have access to the original data before encoding for the ROM rather than having to decode their own ROMs but you never know. It may have been lost after 30 years.

However, just in case it help you chaps, I tested again using the code from LA32FloatWaveGenerator::getPCMSample.

1float sampleValue = EXP2F(((pcmSample & 32767) -32787.0f) / 2048.0f);

and also modified to

1float sampleValue = EXP2F(((pcmSample & 32767) - 32767.0f) / 2048.0f);

When inverted and overlayed with the VST data, 32767 gave much better results .

I'm not so sure about rounding errors now, if you normalise the data you can see and hear it is the original data (albeit very noisy of course). Almost like there was a slight volume difference between the two but I don't really know.
However, I just post that in case it's useful.
Thanks for all the help again.

I have the PCM ROM(s) from a D-50 synth. 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). Decoding the D-50 ROM with the code I posted above creates good results. 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. I have to zoom right up vertically to see it in Sound Forge. 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). So 32767 wins in this case.

I think any wise coder should at least have commented the indicted line with an explanation, in case he had any good reasons to write 32787 vs. the more expectable 32767, to avoid people suspecting of a typo. He didn't instead, too bad. I simply chimed in cos I also noticed the same and was wondering indeed !

...later addition, sorry. I simply had a suspect and I could prove it.
I decoded the pcm rom to two 32 bits float wav files, one using 32767 and one using 32787, and I inspected them with Audacity. I chose a sample which decays slowly, having some good amount of very low level (almost silence) at the end before the next sample. I amplified these almost-silence decaying portions. As I expected, the version made using 32787 showed a considerable DC, while the one made using 32767 was still perfectly centered even after amplification !
So I *have* to conclude that 32787 *is* a typo.