VOGONS


Munt Reloaded - Development

Topic actions

Reply 840 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Hi, there

Falcosoft wrote:

The 2 functions give different results regarding volume level. The floating point one results in twice the volume.

Whereas I completely agree with the Facts, I'm not sure if this statement is true. This is so relative. It may look straightforward to deal with the signal volume in the 16-bit integer format but float samples are NOT native for the original hardware units. Even with integer samples there are quite interesting things to consider.

Indeed, we took quite some time to ensure the correct output volume when it comes to integer samples. It closely corresponds to what we get using the digital sampling right at the DAC entrance when the analogue output emulation is turned off. You may consider the volume to be nearly bit-accurate. On the other hand, analogue output emulation does make the output signal volume differ (depending on the frequency), so even with integer samples there is not much to compare with. And I even don't mention that virtually every analogue capture taken from a real device may have arbitrary volume 😀

OK, speaking of this particular question, it depends on how you measure the volume of float samples. The mt32emu routine that does the sample format conversion actually divides an integer sample by 16384 to produce a float one, and correspondingly a float sample is multiplied by 16384 to return an integer sample. This is mainly intended to adapt to the common rule of having float samples normalised. So, if you say you get the output volume doubled, then it seems your audio processing path expects a different multiplier, i.e. 32768.

However, all is not that simple. Real units are famous of suffering from digital overflows. When we started the float rendering engine, the main goal was to get rid of that sort of things completely. So, the output signal you get with float samples is not actually normalised. It may exceed unity in absolute value, so you have a possibility to normalise the whole recording further.

Another thing to consider is the output from mt32emu is usually too low compared with SFX in most games. So, making it reliably never-ever overdriven is not an option as it'll be difficult to mix nicely. That is why we don't map float 1.0 to integer 32768. Actually, the float renderer internally maps unity to 8192 in the integer renderer. This is the natural full volume of a single playing partial in the engine. It leaves some room for mixing more partials though, but as I said, it's easy to overdrive. The multiplier 16384 used in the sample format converter just takes into account the DAC bit shift that real units feature.

In the conclusion, I'd want to note that it's quite easy to change the output volume with almost no effect on the emulation. Use functions mt32emu_set_output_gain and mt32emu_set_reverb_output_gain for this. By default, the gain is set to 1.0, so supplying a value of 0.5 makes the output twice lower.

PS: Though, I also agree that now, when mt32emu has two rendering engines side-by-side and provides sample format conversion in-flight, this stuff is rather confusing. I'll consider making the volume of float renderer such as to have smoother float <-> integer conversion.

Reply 841 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Hi Serg,
Thank you very much for your answer!

Use functions mt32emu_set_output_gain and mt32emu_set_reverb_output_gain for this. By default, the gain is set to 1.0, so supplying a value of 0.5 makes the output twice lower.

The plugin has the corresponding controls (gain/reverb gain) and the user can set them freely.

muntvsti1.jpg
Filename
muntvsti1.jpg
File size
126.83 KiB
Views
1192 views
File license
Fair use/fair dealing exception

The problem is the users compared the default output (samples get with mt32emu_render_float
+ 1.0 gain + default DAC input mode 'Nice') to the Windows driver that produces half the volume level with the default setup. Actually I do not have any problem with the current implementation, and I recommended the users to change the DAC input mode to 'Pure' if the higher deafult volume is problematic for them. Why 'Pure' mode is not selectable in the Qt client anyway?
Thanks again for your help.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 842 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Falcosoft wrote:

The plugin has the corresponding controls (gain/reverb gain) and the user can set them freely.

OK, that's nice.

Falcosoft wrote:

Actually I do not have any problem with the current implementation

Hmm, but it feels like I now have one 😀 After more thinking about it I became to a conclusion that the current behaviour is actually a mess. Regardless of whether the output float signal may overshoot, it must be (almost) normalised, so your users have a rationale.

Falcosoft wrote:

Why 'Pure' mode is not selectable in the Qt client anyway?

That's another interesting question. KingGuppy wrote the following about the PURE mode:

	/**
* Produces samples that exactly match the bits output from the emulated LA32.
* Nicer overdrive characteristics than the DAC hacks (it simply clips samples within range)
* Much less likely to overdrive than any other mode.
* Half the volume of any of the other modes.
* Output gain is ignored for both LA32 and reverb output.
* Perfect for developers while debugging :)
*/

That means it is not meant for day-to-day use but for easier analysing those digital DAC captures. Not sure whether that word about Output gain is currently true (looks like I added a new bug) but the rest is. Also, in mt32emu_smf2wav PURE mode has more special usage when it produces multi-channel output.

Reply 843 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Hi

Not sure whether that word about Output gain is currently true (looks like I added a new bug) but the rest is.

.

I have not considered this a bug (quite the contrary), but indeed currently Gain/Reverb Gain is applied even in 'Pure' DAC mode.

Edit:
James-F int the FSMP topic has noticed another problematic behavior:

Testing the "32bit internal rendering" produces even Less emulated DAC digital distortion with HQ and 'Pure'. But there is somet […]
Show full quote

Testing the "32bit internal rendering" produces even Less emulated DAC digital distortion with HQ and 'Pure'.
But there is something terribly wrong with Gen1/2 DACs in 32bit , they are extremely distorted even more than in 16bit.
You can test this with my headroom.mid and "Output Gain" at 20.

Falco, I think this is relevant information to the MT-32 Dev thread but I don't want to duply-post on various boards.

Thanks in advance, Serg!

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 844 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Hi Serg,
It would be advantageous if you could add something like this to the C API:

mt32emu_bit32u mt32emu_get_rendered_sample_count(mt32emu_context context) {
return context->synth->renderedSampleCount;
}

The reasons are here:
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

To sum it up In the VSTi plugin sample rate can change at runtime and Munt's timestamp is important because of VST event blocks that can contain offsets.
So I always try to figure out what the actual inner timestamp of Munt can be by calculations that can produce rounding errors (especially at sample rates like 44100) to use the ***_at functions.
I do not care my sample rate dependent timestamp only Munt's is important. But currently it's a black box. All the error prone calculations could be avoided if the C/C++ interface would make this value public.
Also in the documentation maybe the 'synth' should be changed to 'context' since first I thought that an mt32emu_close_synth() and mt32emu_open_synth() sequence resets the timestamp, but actually only new contexts reset it.

timestamp is measured as the global rendered sample count since the synth was created (at the native sample rate 32000 Hz).

Thanks in advance.

Ps: I know about the conversion functions mt32emu_convert_synth_to_output_timestamp() and mt32emu_convert_output_to_synth_timestamp() but they do not help without knowing what the synth's internal timestamp exactly is. (I could do the calculations exactly like these functions do in my code) .

Last edited by Falcosoft on 2017-05-29, 07:03. Edited 1 time in total.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 847 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Thanks Serg, it's exactly what I wanted 😀

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 848 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Hi,
I have seen you have also made modifications to cure the mt32emu_render_float() related volume/normalization problem.
I compiled the new version and the default is now perfect .Mt32emu_render_float() volume level is now the same as mt32emu_render_bit16s() and so the Windows driver. Now at 100% gain, the level is half of the previous version. So in order to get the same volume level you have to duplicate the gain now.
But the problem is that when the internal floating point rendering is NOT enabled the new version is much more distorted at higher gains than the previous one.
I have made a video about the issue. To make things more clear I have given the new library the version number 2.1.1 (vs. the old 2.1.0)
The video:
https://youtu.be/hZ1FBoXNovY

Ps:
in the new version of the plugin the Gain slider range is 0 - 400% (0 - 4.0f). In the old version the Gain slider range was 0 - 200% (0 - 2.0f).
I forgot to mention but mt32emu_get_internal_rendered_sample_count() works perfectly 😀

Thanks for your efforts.

Edit: Forget it, I have just checked and the old version of the library produces the same level of distortion if you use 4.0f Gain and multiply the sample results given back by mt32emu_render_float() with 0.5f (to get the same volume level as the new version). So it could only be a drawback for users who actually liked the higher volume level and they cannot compensate the current lower level with doubled Output Gain of Munt. But they can use a regular Gain VST effect plugin if they want pure doubled volume.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 849 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Oh, just wanted to point out that one should actually expect distortions when setting the gain above 1.0 (at least with integers). This facility only exists because of some games programming the master volume too low, so you can easily regain the balance this way.

Another matter is with floats since we don't clip samples all the way, and they can be carefully normalised further. In realtime, I think there is also a possibility to automatically normalise the signal on the fly (most likely via a VST plugin).

Reply 850 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

NewRisingSun

I feel like all the quirks of MT-32 GEN0 that you've pointed out are now emulated. The only thing I completely fail to sort out is "SpaceAlvin hardly audible in Space Quest 1". I cannot find any differences regarding that patch, and it seems quite simple, btw. May it be that another intrument sounds too loud?

Also, I plan to push a snapshot build to SF.net soon, so could you please do a little testing?

Reply 851 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Of course. Results as follows, using mt32emu-qt.exe dated 2017-06-04:

Issues solved (hence no recording necessary):

  • Dune II's DUNE20.XMI sequence 3: Guitar decayed too quickly
  • The Adventures of Willy Beamish's BULLY.SND: Guitar decayed too quickly
  • Police Quest II's 40.SND: Kick drum played at wrong pitch
  • Strike Commander's COMBAT.XMI music 4: "Taiko Cym" cut off

Issue almost solved (recording from a real 1.07 MT-32 linked):

  • The Colonel's Bequest's 10.SND: Swamp sound effect sounds almost right, but the mid-frequency rumble-like noise is still too loud (sorry, cannot find a better way to describe it). MT-32 recording

Issues that persist (recordings from a real 1.07 MT-32 linked):

  • King's Quest V's 24.SND: Whiporill plays at wrong pitch. This is the only one that has gotten worse --- Now it sounds like the CM-32L even with the MT-32 1.07 ROM. MT-32 recording
  • Space Quest I's 608.SND: SpaceAlvin hardly audible. MT-32 recording

If you listen to my recording, you will hear that SpaceAlvin itself is indeed the culprit. I'll later post a recording of a chromatic scale of SpaceAlvin at several velocities later to prove my point further.

But still, great update, and thank-you for your continued work.

Last edited by NewRisingSun on 2017-06-04, 20:40. Edited 1 time in total.

Reply 852 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Attached file "SPCALVIN.ZIP" demonstrates the SpaceAlvin problem better. SPCALVIN.MID plays a chromatic scale of notes, all at velocity 70. On the CM-32L, and in the MUNT snapshot with MT-32 v1.07 ROMs, the effective volume is gradually lowered as the pitch increases. On the real MT-32 v1.07 (recording linked), starting at note 92, the instrument suddenly starts screaming and distorting heavily. Space Quest I relies on this.

Attachments

  • Filename
    SPCALVIN.ZIP
    File size
    4.45 KiB
    Downloads
    61 downloads
    File license
    Fair use/fair dealing exception

Reply 853 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Thank you again, NewRisingSun! With these recordings I'm surely able to go on digging.

Well, I still doubt I can do something to improve SwmpBackgr. The range within which the pitch varies is now correct but the algorithm we use to emulate LFO is a crap. While our LFO is perfect, it is far from that on a real unit as you know 🙁 I thought even of randomization the pitch changes but still that would be far from being correct behaviour. With nearly fair emulation of MCU, SwmpBackgr does sound very close but that also takes ~25% of my CPU...

As for Whiporill, I can see that it relies on undefined behaviour rather. The code lacks the range-check of velosens value, so it passes out of range to the calculation. And according to 8098 spec, a register shift with counter above 15 turns to an indirect shift, [nonsense]i.e. it takes the shift counter from another register (which in turn varies with velosens). Though, in the MCU emulation that register was 0,[/nonsense] so Whiporill sounded identically to CM-32L what I implemented. It seems to be a nasty hack needed to make it sound right...

And of course, that sweep you provide for SpaceAlvin will surely help to find the quirk I despaired to discover!

P.S. Whiporill did sound identically to CM-32L but only because of a thinko implemented in the MCU emulator. 😉

Reply 855 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

SpaceAlvin and Whiporill now sound correct as well. Thank-you very much. 😀

For more extensive testing, an updated version of smf2wav is needed as well. I can then convert all game soundtracks I have, copy the flac files to my cellphone and listen to them throughout the day. That will allow me to spot any remaining imperfections (as if!) 😉

Reply 856 of 965, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

That’s quite some dedication you two! Thank you!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 857 of 965, by Spikey

User metadata
Rank Oldbie
Rank
Oldbie

Great work. I was talking to Rob Atesalp not too long ago, who composed sound effects for quite a few Sierra MT-32 games, and he was talking about how he made a lot of them, basically changing pitch bend and note range until it sounded crazy.

Reply 858 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

For more extensive testing, an updated version of smf2wav is needed as well. I can then convert all game soundtracks I have, copy the flac files to my cellphone and listen to them throughout the day. That will allow me to spot any remaining imperfections (as if!) 😉

smf2wav build is available. Beware of the weird ROM loading priority: CM32L_CONTROL.ROM / CM32L_PCM.ROM take precedence over MT32_CONTROL.ROM / MT32_PCM.ROM if both sets are present in one directory. I think we need another command line switch to make it less messy...