Munt Reloaded - Development

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

Re: Munt Reloaded - Development

Postby sergm » 2017-5-25 @ 13:51

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.
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-5-25 @ 20:29

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

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.
You do not have the required permissions to view the files attached to this post.
User avatar
Falcosoft
Member
 
Posts: 381
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby sergm » 2017-5-26 @ 06:37

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:
Code: Select all
   /**
    * 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.
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-5-26 @ 08:51

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 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!
User avatar
Falcosoft
Member
 
Posts: 381
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-5-28 @ 10:17

Hi Serg,
It would be advantageous if you could add something like this to the C API:
Code: Select all
mt32emu_bit32u mt32emu_get_rendered_sample_count(mt32emu_context context) {
   return context->synth->renderedSampleCount;
}


The reasons are here:
http://www.vogons.org/viewtopic.php?f=24&t=48207&start=440#p587426

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-5-29 @ 07:03, edited 1 time in total.
User avatar
Falcosoft
Member
 
Posts: 381
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby sergm » 2017-5-28 @ 12:03

No problem, I'll try to make this thing available today.
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-5-28 @ 12:52

Falcosoft

See if this commit helps.
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-5-28 @ 16:30

Thanks Serg, it's exactly what I wanted :)
User avatar
Falcosoft
Member
 
Posts: 381
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-5-28 @ 19:50

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.
User avatar
Falcosoft
Member
 
Posts: 381
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby sergm » 2017-5-29 @ 18:44

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).
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-6-04 @ 09:51

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?
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-6-04 @ 20:22

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-6-04 @ 20:40, edited 1 time in total.
NewRisingSun
Oldbie
 
Posts: 774
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-6-04 @ 20:38

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.
You do not have the required permissions to view the files attached to this post.
NewRisingSun
Oldbie
 
Posts: 774
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby sergm » 2017-6-05 @ 08:11

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. ;)
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-6-06 @ 19:05

sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-6-06 @ 19:38

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!) ;)
NewRisingSun
Oldbie
 
Posts: 774
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby Dominus » 2017-6-06 @ 20:14

That’s quite some dedication you two! Thank you!
User avatar
Dominus
DOSBox Moderator
 
Posts: 7283
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby Spikey » 2017-6-07 @ 03:39

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.
User avatar
Spikey
Member
 
Posts: 188
Joined: 2003-2-04 @ 10:36
Location: South Australia

Re: Munt Reloaded - Development

Postby sergm » 2017-6-07 @ 06:26

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...
sergm
Oldbie
 
Posts: 732
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-6-07 @ 16:25

Thank-you. Is it within the realm of possibility that panning is different between MT-32 and CM-32L, or am I imagining things?
NewRisingSun
Oldbie
 
Posts: 774
Joined: 2005-9-02 @ 02:26

PreviousNext

Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest