Muffled percussion instruments in DOSBox

[marooned_on_mars]

I've previously stated that I can hear muffled instruments (esp. percussion) here, but this time I tried it outside of DOSBox and found out it doesn't sound exactly the same:

DOSBox SVN r3871 + munt GIT 16-11-2014 (48000Hz) - Linux (CrunchBang 11 + Unstable Debian repos)
munt Qt GIT 16-11-2014 (library and GUI from the same version - 48000Hz) - Linux (CrunchBang 11 + Unstable Debian repos)
HooT + munt GIT 09-11-2014 - stand-alone library available here (48000Hz) - Windows
HooT + munt GIT 09-11-2014 (32000Hz) - Windows

The crispest sound I get out of HooT (but unfortunately it causes cutoffs/overdrive in some games, not in the recordings above though), the munt GUI sounds close to that, and the DOSBox version sounds the worst, even though it uses the same sampling rate as the GUI/HooT. I've also recorded the same piece on HooT on 32000Hz, and it sounds very similar to how DOSBox sounds at 48000Hz. So my question is, is this some issue with how DOSBox handles audio or is it some other issue?

Also please note, DOSBox + munt ≠ DOSBox + munt Qt GUI

[truth_deleted]

On typical Windows, I believe dosbox+mt32emu routes through directsound, whereas the other method may rely on waveout. However, I don't see any description above on which OS is even used, or whether these tests were done on different operating systems. It's difficult to replicate an audio issue if the test conditions are missing.

I don't know why there is no recording from real hardware above. Other users cannot replicate which sounds "worst" without hearing the expected sound, and even better if more than one recording is included (from different versions of the MT32 device).

[marooned_on_mars]

On typical Windows, I believe dosbox+mt32emu routes through directsound, whereas the other method may rely on waveout. However, I don't see any description above on which OS is even used, or whether these tests were done on different operating systems. It's difficult to replicate an audio issue if the test conditions are missing.

Fixed that, basically DOSBox + munt GUI recordings were done on Linux, with HooT was done on Windows. (don't think there would be much of a difference if I were to record under wine)

I cannot test DOSBox + munt on Windows since ATM I don't have any environment for compiling set up, but I will work on it if it helps.

Also attached the DOSBox config file and hoot.ini, in case anyone wants to test out with the same settings I used. On munt GUI, I used the default settings with the CM-32L ROM, v1.02.

Sorry for leaving out details

I don't know why there is no recording from real hardware above. Other users cannot replicate which sounds "worst" without hearing the expected sound, and even better if more than one recording is included (from different versions of the MT32 device).

Because I don't have the real hardware? Unfortunately I don't have any real MT-32/CM-32L devices to test against, but I've heard quite a few recordings of real MT-32s and the percussion shouldn't sound like that. If anyone has any device free for testing I can give the midi file, otherwise I can't help with that.
Basically I'm here to ask about the DOSBox part of munt or the patches, not exactly about the accuracy compared to the real hardware (as I stated above, I cannot prove this or that sounds inaccurate since I don't have the real hardware)

[truth_deleted]

If you are to answer your original question, it is ideal to have a test against real hardware. That way it can be determined which sounds "worst". It would allow others to hear the result, too.

The munt author also previously explained the likely cause of "muffled percussion" in the thread you referenced. Perhaps you missed his post in that thread, but that is an obvious starting place to test the issue, especially since he has written a significant portion of the emulator.

[marooned_on_mars]

If you are to answer your original question, it is ideal to have a test against real hardware. That way it can be determined which sounds "worst". It would allow others to hear the result, too.

Sure it is, but again, it's not strictly about accuracy in this case. As I said I suspect it might be with the way DOSBox resamples/handles audio (if it is about resampling) or something about the DOSBox mt32emu patch.

The munt author also previously explained the likely cause of "muffled percussion" in the thread you referenced. Perhaps you missed his post in that thread, but that is an obvious starting place to test the issue, especially since he has written a significant portion of the emulator.

I did see sergm's replies in that thread, and I replied to what he said as well. It still doesn't explain why things sound differently between applications when using the same sampling rate. And why DOSBox @ 48000Hz sounds (almost) the same as HooT @ 32000Hz

[truth_deleted]

Those recordings were all done on developmental versions of the MT32 emulation? It may be worthwhile to test with the official version 1.40, instead of code which has been undergoing modification daily.

[sergm]

Good catch, marooned_on_mars!

As I mentioned in http://www.vogons.org/viewtopic.php?p=387863#p387863, DOSBox patch cannot use 'accurate' emulation of analogue LPF, so it always runs the emulation @ 32kHz. Even if you set DOSBox mixer to 48kHz output rate. DOSBox mixer simply does resampling (well, linear interpolation is a way of resampling too, heh). So, the high frequency spectra boosted in the default 'coarse' mode is further attenuated by the linear interpolator of DOSBox. I assume, you are probably aware of why people bother with filters, sincs and so forth instead... This is basically the main reason I always suggest to avoid resampling if it is possible.

In contrast, mt32emu-qt thing has fully incorporated analogue emulation stuff, so you can play with the analog mode switch and hear the difference. You can even play with quality settings of the resampler you use (it's hard-coded to the fastest sinc-based interpolation by now, though). The Windows driver has been also updated but it sucks to have no UI.

I don't forget about the DOSBox patch, and I plan to update it soon. Moreover, I also plan to add an optimised sinc-based resampler that is to be bit-accurate yet not to eat memory like libsamplerate nor to waste time with FFT (there is really really no need for it in munt case) like libsoxr. Especially, no reason to rush so you're able to do proper comparisons.

However, it seems munt suffers a lot more of lack of proper MIDI parser. So, I put this issue to a higher priority. At the end, sending multiple/fragmented sysexes should no longer be a problem on Windows (and perhaps with OSS raw MIDI ports).

[marooned_on_mars]

As I mentioned in http://www.vogons.org/viewtopic.php?p=387863#p387863, DOSBox patch cannot use 'accurate' emulation of analogue LPF, so it always runs the emulation @ 32kHz. Even if you set DOSBox mixer to 48kHz output rate.

That explains it.
LPF = Low Pass Filter?
Also I'm curios now in which way HooT uses the munt library, as it sounds very crisp, and doesn't have the problems DOSBox has. I'll ask on the HooT thread above

DOSBox mixer simply does resampling (well, linear interpolation is a way of resampling too, heh).

A little bit off-topic but do you know if this happens with the other sound modules provided by DOSBox? (OPL*, internal MIDI like Gravis, Tandy, etc.)
In that case it would make very little sense in changing the sampling rate to 49716Hz when using OPL.

In contrast, mt32emu-qt thing has fully incorporated analogue emulation stuff, so you can play with the analog mode switch and hear the difference. You can even play with quality settings of the resampler you use (it's hard-coded to the fastest sinc-based interpolation by now, though). The Windows driver has been also updated but it sucks to have no UI.

Alright, I'll make sure to use the GUI emulator for the time being

I don't forget about the DOSBox patch, and I plan to update it soon. Moreover, I also plan to add an optimised sinc-based resampler that is to be bit-accurate yet not to eat memory like libsamplerate nor to waste time with FFT (there is really really no need for it in munt case) like libsoxr.

Sounds good

Especially, no reason to rush so you're able to do proper comparisons.

?

However, it seems munt suffers a lot more of lack of proper MIDI parser. So, I put this issue to a higher priority. At the end, sending multiple/fragmented sysexes should no longer be a problem on Windows (and perhaps with OSS raw MIDI ports).

Awesome, looking forward for it
Thanks for your contributions to the project sergm

[sergm]

LPF = Low Pass Filter?

True.

Also I'm curios now in which way HooT uses the munt library, as it sounds very crisp, and doesn't have the problems DOSBox has. I'll ask on the HooT thread above

Also, the most correct way to get it clear. Unfortunately, I barely find time for munt itself

A little bit off-topic but do you know if this happens with the other sound modules provided by DOSBox? (OPL*, internal MIDI like Gravis, Tandy, etc.)
In that case it would make very little sense in changing the sampling rate to 49716Hz when using OPL.

The correct way is to ask somewhere in DOSBox threads. AFAIK, the mixer is an optimised fixed-point-math linear interpolator. Perhaps, it was improved recently, didn't look. But the true is, this kind of resampling affects the signal in an _audible_ way.

Alright, I'll make sure to use the GUI emulator for the time being

No need, in fact. Use the tooling most suited your needs. As I noted before, the output you get can be post-processed. This includes high-quality resampling, applying the LPF emulation, equalising, etc. The analogue emulation implemented is nothing more then applying the theoretical response of analogue LPF used in real modules. But it is necessary to note, analogue circuits rarely perform in a perfect way. Besides, the properties of electronic parts degrade with time... KingGuppy proposed me once to add emulation of the time effects

Awesome, looking forward for it
Thanks for your contributions to the project sergm

I hope it'll help at least one guy

[Mok]

Also I'm curios now in which way HooT uses the munt library, as it sounds very crisp, and doesn't have the problems DOSBox has. I'll ask on the HooT thread above

Hoot uses munt directly without any changes, there's a simple resampling bridge (the source code is included with hoot, as they cannot include dll binary, it's a closed source project). The reason for the overdrive is their internal volume settings for mt32 emulator dating from very old versions of munt, ie. they amplify the output from munt which causes distortion. A simple workaround is to modify munt library to decrease the output by 40-60% and the distortions will most likely disappear.

The difference is sound is harder to explain, it might be simply because dosbox emulates the whole game while hoot only emulates the sound code alone. There might be a bug in the game or in the hoot driver (many hoot bridges/drivers do not use code taken directly from the emulated game but a generic one from the soundsystem used by the game) etc. So you really should be comparing against a real synth.

[sergm]

@Mok
Thanks for the clarification. I believe 'a simple resampling bridge' may appear a source of enough change in the frequency spectra. And the overdrive distortions as well. But the real issue with the 'muffled' sounding which MoM doesn't really want to hear is exactly the imperfection of the implementation in the real hardware analogue path. So, the worse it sounds, the better for MoM.

[marooned_on_mars]

So, the worse it sounds, the better for MoM.

That really depends on (perhaps) subjective preferences. I for one don't want my recordings to sound like they were downsampled or the MT-32 "orchestra" put towels and clothes over their rhythm sections. I won't pretend to know much about how any of the LA synths work (that's why you're contributing to this project and not me) but I did hear a lot of recordings from real hardware (mainly on YouTube and CVGM but also from QuestStudios) and I can tell that the "muffled sound" problem is not present.

[Mok]

@Mok
Thanks for the clarification. I believe 'a simple resampling bridge' may appear a source of enough change in the frequency spectra. And the overdrive distortions as well. But the real issue with the 'muffled' sounding which MoM doesn't really want to hear is exactly the imperfection of the implementation in the real hardware analogue path. So, the worse it sounds, the better for MoM.

The resampler in hoot was added only recently (relatively speaking, a few months after you forced the output to be always at 32k), and the overdrives were present waaay before that (it's been years since I started lowering munt output volume when compiling the bridge). It's just hoot is closed source so it's not possible to disable it's internal amplifying, and the devs are japanese which makes "contributing" hard (I tried once, years ago, won't try again). Anyway it's a hoot problem and not a munt one, so no need to discuss here

[truth_deleted]

So, the worse it sounds, the better for MoM.

That really depends on (perhaps) subjective preferences.

It's not subjective, it's based on comparing real hardware to emulation. This comparison may even be done with equipment to measure the sound properties, although even a verified recording is insightful. However, it is better than we make conclusions based on recordings we have done rather than referencing youtube samples from unknown sources and unknown test conditions.

[sergm]

@marooned_on_mars
Well, ignoring Hoot existence, what do you feel comparing the output of mt32emu_qt when you change "Analog emulation mode" setting (note: it requires saving the synth profile and restarting the synth to take effect)?

[sergm]

You're right, truth5678. This should be done properly this way. Unfortunately, DSP doesn't operate with such categories like "muffled" and "crisp". Only with impulse / frequency responses.
On the other hand, even real hardware units do sound differently due to burned resistors, leaking capacitors, dust, etc. My own RA-50 even doesn't sound at all

[marooned_on_mars]

It's not subjective, it's based on comparing real hardware to emulation.

I think you might have misunderstood what I said, I wasn't calling sergm's "opinion" as subjective (as I said, sergm clearly has a better idea of how the MT-32 & co. function/process signals than me), but I was calling out that just because I prefer munt to sound a certain way does not mean I prefer things to sound "worse".

This comparison may even be done with equipment to measure the sound properties, although even a verified recording is insightful. However, it is better than we make conclusions based on recordings we have done rather than referencing youtube samples from unknown sources and unknown test conditions.

I won't argue with you on this one, I'd be happy to provide recordings from real hardware together with the test conditions, or anything else that is required (IIRC sergm required FFT scans as well some time ago) to test but as I stated earlier I cannot provide those. It wasn't just YouTube I was "referencing" earlier, there's also RMLA that states on which exact model they recorded their stuff, but even that's not enough to be able to test accurately.

@marooned_on_mars
Well, ignoring Hoot existence, what do you feel comparing the output of mt32emu_qt when you change "Analog emulation mode" setting (note: it requires saving the synth profile and restarting the synth to take effect)?

Will test that out in the following days.

[marooned_on_mars]

Okay, so I've tried all three modes, coarse analogue path emulation is inbetween digital and accurate sound-wise. Also apparently it still plays/exports @ 32000Hz, and I assume that's expected. Coarse sounds a tad bit better than what I've got out of DOSBox, so I assume this is what you wanted to hear?

[sergm]

Basically. Thanks, glad to hear your opinion.

[NewRisingSun]

I love the analogue sound emulation, and want to encourage you to keep updating smf2wav and release one with that feature as well for people like me who hate GUIs.

Normally, I would compile it myself, but it uses glib, which seems to be a real pain to compile under MingW.