VOGONS


First post, by Spikey

User metadata
Rank Oldbie
Rank
Oldbie

Hey sergm and others,

I would have PM'd you this but you have that feature disabled for some reason.

Basically, I have heard some samples a friend recorded where he tweaked the source code for a project of his and enabled floating point instead of integer, which stopped the MT-32's quantization noise. It was surprisingly improved.

As I record the MT-32's output for my Sierra music website, I would love to have this feature when I use MUNT as a MIDI audio source. Apparently it would not be hard to implement, and I would be very grateful if it could happen.

Regards,
- Spike

Reply 2 of 32, by collector

User metadata
Rank l33t
Rank
l33t

ScummVM's MUNT is pretty much a straight implementation of standalone MUNT and is only as recent as the state of MUNT at the time of the last release.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 3 of 32, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Spikey, this shouldn't be an issue. It's just a matter of setting a compiler define, so I can easily build something if you provide details which tool you'd like to have and for which platform.

But I still think that enabling this option isn't too advantageous. Perhaps, it's rather specific. See, the library not only creates samples in float format, it uses different algorithm in fact. There are lot more sources of noise aside from quantisation to 16-bit samples. That is, this "float" algorithm creates waves more precisely in terms of mathematics but less accurate in terms of emulation. If this isn't a problem, feel free to use it.

Reply 4 of 32, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

I'm happy that MUNT by default tries to be as accurate in its emulation as possible. Emulate the original machine, even its flaws, is the way to go. Nevertheless, listening with headphones exhibits some of the MT-32's flaws, and when given the choice, I prefer the floating-point version for the listening experience.

Listen to the introduction music of Ultima VII Part 2: Serpent Isle, the way it sounds with normal MUNT or a real MT-32/CM module, versus recompiled MUNT with floating point arithmetic. The Synth Brass at the start exhibit the quantization noise very well, which is completely absent in the floating point recording, even as the rest of the track is just as bright.

Having gone through hell getting glib to compile in MingW so I could successfully compile smf2wav with floating point arithmetic (what are you using it for anyway? 😉), I am too burned to install QT to compile the GUI version of MUNT, otherwise I would do it for Spikey.

Reply 6 of 32, by DOSUserDude

User metadata
Rank Newbie
Rank
Newbie
sergm wrote:

This sounds like you guys would be happy if this compiler switch eventually became a runtime option. Damn, my struggle against muffled sound turns out to be for nothing 🤣

I'd take that and a runtime console option as well...

Reply 7 of 32, by Spikey

User metadata
Rank Oldbie
Rank
Oldbie

Spikey, this shouldn't be an issue. It's just a matter of setting a compiler define, so I can easily build something if you provide details which tool you'd like to have and for which platform.

But I still think that enabling this option isn't too advantageous. Perhaps, it's rather specific. See, the library not only creates samples in float format, it uses different algorithm in fact. There are lot more sources of noise aside from quantisation to 16-bit samples. That is, this "float" algorithm creates waves more precisely in terms of mathematics but less accurate in terms of emulation. If this isn't a problem, feel free to use it.

Sergey,

Awesome, thank you. I am running MUNT mt32emu_qt on Win 7 64-bit.

NewRisingSun and I were talking about this. If you listen to the example he provided, you can objectively hear that the 32-bit recording sounds cleaner and 'better' (at least to me), with no downside that I was aware of.

The point for me is less 'accuracy' for more quality (I don't know that accuracy is how I would describe a technological/hardware limitation, but let's go with it for now). If I am making a recording where there are multiple synthesizers, no one will notice a slight difference in MT-32 timbre on a couple patches, but the overall noise floor being lower and the recording being crisper will be noticeable.

At the very least it's not a bad option to have and it gives people such as myself flexibility.

What is your 'struggle against muffled sound'? As NRS said, I am for accuracy, that's what we want for games. But the example he posted sounds more muffled in the 'accurate' version!

Regards, and thanks for all you guys do.
- Spikey

Reply 9 of 32, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

I'm going to play the devil's advocate, as I can objectively say I can't hear a notable difference between the two recordings above.

The synth brass in Ultima 7 's intro might be a wee tad less noisy, but it could also be a placebo -- for sure I'd never have noticed it if NRS hadn't mentioned that specific part. More options are good, but for me the marginal improvement (if any) isn't justified if that compromises accuracy.

Ryzen 2600X 4.2 GHz | Radeon RX 6650 XT 8 GB | DDR4 16 GB | Win10-64 Pro

Reply 10 of 32, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

I believe this stuff is quite subjective and a matter of personal preference. During development, we rather rely on frequency spectrum of output signals than on ear. But anyway, we provide some other runtime options to change emulation, including accuracy, so this one should also be available. The only problem to implement it is usage of different sample types but this can indeed be solved.

Reply 13 of 32, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Something strange happens when using that QT build with the control ROM for the old MT-32 v1.07. Play INIT.SYX and CHAN9.MID; you'll hear a faint but clearly audible kind of "screaming note" in the reverb of the snare drum. This does not occur when using the CM-32L ROM. The screaming note is even louder and grating when I compile myself smf2wav using the 2.0 sources (see attached CHAN9.FLAC) with the floating point option. As the problem is there in sergm's build as well, I don't think it's due to a mistake in my self-compiled build.

Attachments

  • Filename
    CHAN9.zip
    File size
    731.78 KiB
    Downloads
    155 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    strange.zip
    File size
    3.57 KiB
    Downloads
    157 downloads
    File license
    Fair use/fair dealing exception

Reply 15 of 32, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Sorry, haven't find a way to reproduce it yet. Tried directly "mt32emu-qt.exe convert CHAN9.wav INIT.SYX CHAN9.MID" with the build mentioned and hear nothing suspicious. Maybe I'm missing something...

Attachments

  • Filename
    CHAN9_QT.zip
    File size
    1.43 MiB
    Downloads
    143 downloads
    File license
    Fair use/fair dealing exception

Reply 17 of 32, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Why, it's right there in your CHAN9_QT.flac file. It's more faint than in my recording, but definitely there after three seconds. A mid-pitched note with a vibrato at the end. You might have to turn up the volume a bit to hear it.

Reply 18 of 32, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Well, really it is. I had to use "Amplify" tool in Audacity to reveal it. Though, the similar thing is there when converting this MID using the "stock" mt32emu-qt build. Another matter is I can't reproduce it with smf2wav completely, so it's worth more debugging...

Reply 19 of 32, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

This seems to be a kind of use of uninitialised data. It's very well reproduced on Linux when compiling for debug, so I'm on it. It's shown as

MT32: "Rhythm (??????????): Start poly (drum 28, timbre 222): midiKey 52, key 52, velo 100, mod 0, exp 100, bend 0"

It just has nothing to do with MT32EMU_USE_FLOAT_SAMPLES definition 😉