VOGONS


First post, by lukeman3000

User metadata
Rank Member
Rank
Member

I have been using the DOSBox with MUNT that collector includes with his installers over on the Sierra Help pages.

I tried out the most recent ECE build (r4006 ECE) with interesting results. The music sounds a little more distorted and "crackly" as compared to the DOSBox build included with the Sierra Help installers. I've included a video for comparison:

https://youtu.be/CdOrXYE_d5g

As the description says, the first version heard is the most recent ECE build whereas the second is the one included with the SHP installers. If you alternate between pressing 2 and 8 it will skip the video between the two versions for better comparison.

Any idea why I'm getting this distortion with the ECE build? Additionally, the ECE build sounds like it's equalized a bit differently, like with more of a reverse bell curve (low mids, high highs) whereas the SHP build sounds a bit more flat in comparison.

Here is a another comparison between King's Quest IV:

https://www.youtube.com/watch?v=u5yobdHILvo&feature=youtu.be

(This time, the older MUNT build is at the first of the video and the newer, ECE build is at the end)

The newer MUNT sounds a little less muddy to me, but if you'll notice on some of the higher notes (as in at 0:56), it sounds like there's some kind of buzzing or distortion or something going on.

Maybe that's how it's supposed to sound and this newer version of MUNT is a more true MT-32 emulation? I don't know. But to me it sounds a little messed up, not knowing what a real MT-32 sounds like in this scenario.

Here's (apparently) the KQ4 soundtrack which was recorded with an MT-32 and it does not seem to have that distortion that I'm hearing in the ECE build.

Reply 1 of 54, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I just had a look at the SHP Installer and it seems that with that one, it isn't DOSBox that does the M32 emulation, but an external driver called MTBLAST.drv that's used for playback. Since this driver is from 2010 there might of course be differences in the sound it produces.

You can change some parameters for MT emulation in the .conf file for your game as well, have you tried playing around with those?

#           mt32.romdir: Name of the directory where MT-32 Control and PCM ROM files can be found. Emulation requires these files to work.
# Accepted file names are as follows:
# MT32_CONTROL.ROM or CM32L_CONTROL.ROM - control ROM file.
# MT32_PCM.ROM or CM32L_PCM.ROM - PCM ROM file.
# mt32.reverse.stereo: Reverse stereo channels for MT-32 output
# mt32.verbose: MT-32 debug logging
# mt32.thread: MT-32 rendering in separate thread
# mt32.chunk: Minimum milliseconds of data to render at once.
# Increasing this value reduces rendering overhead which may improve performance but also increases audio lag.
# Valid for rendering in separate thread only.
# Possible values: 2, 3, 16, 99, 100.
# mt32.prebuffer: How many milliseconds of data to render ahead.
# Increasing this value may help to avoid underruns but also increases audio lag.
# Cannot be set less than or equal to mt32.chunk value.
# Valid for rendering in separate thread only.
# Possible values: 3, 4, 32, 199, 200.
# mt32.partials: The maximum number of partials playing simultaneously.
# Possible values: 8, 9, 32, 255, 256.
# mt32.dac: MT-32 DAC input emulation mode
# Nice = 0 - default
# Produces samples at double the volume, without tricks.
# Higher quality than the real devices
#
# Pure = 1
# 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.
# Perfect for developers while debugging :)
#
# GENERATION1 = 2
# Re-orders the LA32 output bits as in early generation MT-32s (according to Wikipedia).
# Bit order at DAC (where each number represents the original LA32 output bit number, and XX means the bit is always low):
# 15 13 12 11 10 09 08 07 06 05 04 03 02 01 00 XX
#
# GENERATION2 = 3
# Re-orders the LA32 output bits as in later generations (personally confirmed on my CM-32L - KG).
# Bit order at DAC (where each number represents the original LA32 output bit number):
# 15 13 12 11 10 09 08 07 06 05 04 03 02 01 00 14
# Possible values: 0, 1, 2, 3.
# mt32.analog: MT-32 analogue output emulation mode
# Digital = 0
# Only digital path is emulated. The output samples correspond to the digital output signal appeared at the DAC entrance.
# Fastest mode.
#
# Coarse = 1
# Coarse emulation of LPF circuit. High frequencies are boosted, sample rate remains unchanged.
# A bit better sounding but also a bit slower.
#
# Accurate = 2 - default
# Finer emulation of LPF circuit. Output signal is upsampled to 48 kHz to allow emulation of audible mirror spectra above 16 kHz,
# which is passed through the LPF circuit without significant attenuation.
# Sounding is closer to the analog output from real hardware but also slower than the modes 0 and 1.
#
# Oversampled = 3
# Same as the default mode 2 but the output signal is 2x oversampled, i.e. the output sample rate is 96 kHz.
# Even slower than all the other modes but better retains highest frequencies while further resampled in DOSBox mixer.
# Possible values: 0, 1, 2, 3.
# mt32.reverb.mode: MT-32 reverb mode
# Possible values: 0, 1, 2, 3, auto.
Show last 4 lines
#      mt32.reverb.time: MT-32 reverb decaying time
# Possible values: 0, 1, 2, 3, 4, 5, 6, 7.
# mt32.reverb.level: MT-32 reverb level
# Possible values: 0, 1, 2, 3, 4, 5, 6, 7.

Here's some info on drivers used in the SHP installers: http://sci.sierrahelp.com/Tools/SCISoundTools.html
And here's a thread in these forums where some of those drivers were created / hacked: Sierra/Dynamix sound driver hacking
Maybe there's some useful info in one of these sites there as well.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 2 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member

I just tested again using a vanilla DOSBox installation with MUNT installed separately, and it sounded great. Compared to this, the ECE MT-32 emulation sounds like it has some kind of distortion going on...

I haven't played around with the MT parameters in the config file, I've left them at default. Though, I did play around in MUNT with the different parameters and I could not reproduce the distortion that I'm hearing.

Here's a video I made. The first time I am using vanilla DOSBox and MUNT separately. The second time (when I hear distortion), I'm using the r4006 ECE build. This video does capture the distortion, or at least what I think to be such.

https://www.youtube.com/watch?v=S1axP590uT4&feature=youtu.be

Reply 3 of 54, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

If playing around with the settings doesn't help it might help to open a ticket on MUNTs SF page, maybe the author can tweak something in his DOSBox patch. Since the source code for the external and the integrated emu are the same, the changes made by the diff for DOSBox are the only difference between them.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 4 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:

If playing around with the settings doesn't help it might help to open a ticket on MUNTs SF page, maybe the author can tweak something in his DOSBox patch. Since the source code for the external and the integrated emu are the same, the changes made by the diff for DOSBox are the only difference between them.

Ok, I will submit a ticket. Have you been able to reproduce this issue, or can you verify that you hear a difference between the two examples in my video?

Reply 5 of 54, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:
Yesterplay80 wrote:

If playing around with the settings doesn't help it might help to open a ticket on MUNTs SF page, maybe the author can tweak something in his DOSBox patch. Since the source code for the external and the integrated emu are the same, the changes made by the diff for DOSBox are the only difference between them.

Ok, I will submit a ticket. Have you been able to reproduce this issue, or can you verify that you hear a difference between the two examples in my video?

Not really, but I'll check again when I am back home, my headphones I have here with me aren't exactly the best. I'll let you know.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 6 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote:
lukeman3000 wrote:
Yesterplay80 wrote:

If playing around with the settings doesn't help it might help to open a ticket on MUNTs SF page, maybe the author can tweak something in his DOSBox patch. Since the source code for the external and the integrated emu are the same, the changes made by the diff for DOSBox are the only difference between them.

Ok, I will submit a ticket. Have you been able to reproduce this issue, or can you verify that you hear a difference between the two examples in my video?

Not really, but I'll check again when I am back home, my headphones I have here with me aren't exactly the best. I'll let you know.

Thanks. I just went through and tried out many different combinations of settings, but they made no noticeable improvement on the distortion that I'm hearing.

Reply 7 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

If I get things right, what you hear can well be the most classic type of distortion: aliasing. It often becomes audible due to adding unwanted mirror spectra to the original audio signal in the process of sample rate conversion. I suspect DOSBox's mixer sample rate differs significantly from that of the mt32emu engine in this case. I hope you can get rid of it by syncing the output sample rate of mt32emu engine with the DOSBox's mixer sample rate.

FYI: mt32emu works internally at fixed sample rate of 32000 Hz which is the sample rate of the famous hardware. The sample rate of mt32emu output signal however can vary in accordance with the mode of the recently introduced emulation of the analogue end found in the hardware. You can set the mode with help of mt32.analog property. In modes 0 and 1 the sample rate doesn't change, while in modes 2 and 3 it gets higher (in the process, some degree of aliasing is even added but intentionally).

Reply 9 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member
sergm wrote:

Evidently, aliasing is well audible when whistles are playing. If I set rate=48000 in the mixer section, they are gone.

Thank you! This seems to work.

This may be a bit off-topic, but, would I be served from setting the mixer rate to 49716 in any given game? Do I get better sound quality (aside from the aliasing that occurs) with the higher setting?

Reply 10 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Yes, you need the rate 49716 Hz in order to achieve most accurate OPL emulation. If a game plays adlib/sb music only (or if it sounds just better to your taste), you should set both the mixer rate and oplrate to this value. Unfortunately, with this setting you'll also get aliasing when playing sounds at any other rate (which is not a multiple of 49716 Hz). DOSBox's mixer is fast and.... that's all its positive points. On the other hand, it's hard to find an audio system unable to provide a quality sample rate conversion these days, so using yet another SDL audio channel (running at native sample rate of e.g. mt32emu or adlib) may appear a way to go rather than mixing all the audio channels within DOSBox. Most probably, I'll add this to the patch and fall-back to DOSBox's mixer in case it fails.

As for the sound quality, you generally gain nothing from boosting sample rate above the minimum required (i.e. the one necessary to hold all the audible spectra without loss). But using higher sample rate may still become in handy during digital sound processing, so it is not uncommon to see e.g. 96 kHz or 192 kHz (or even higher) sample rates.

Reply 11 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member
sergm wrote:

Yes, you need the rate 49716 Hz in order to achieve most accurate OPL emulation. If a game plays adlib/sb music only (or if it sounds just better to your taste), you should set both the mixer rate and oplrate to this value. Unfortunately, with this setting you'll also get aliasing when playing sounds at any other rate (which is not a multiple of 49716 Hz).

I'm sure this is my ignorance speaking, but I'll ask anyways.

If I'm understanding you correctly, I should set the mixer and oplrate to 49716 when using adlib or soundblaster in a game. If I'm using MT-32 or CM-32L the mixer rate should be set to 48000 (I'm assuming that oplrate doesn't matter in this case). What about in the case of general midi?

Anyways, you say that I'll get aliasing when playing sounds at any other rate which is not a multiple of 49716. But, isn't the only reason I'd set the mixer to 49716 because of the fact that I'm using adlib/sb? So how then could this be an issue? If I'm not emulating MT-32 with MUNT (at 48000 Hz) because I'm using adlib/sb, how could sounds play at any other rate than 49716 Hz which is what the DOSBox mixer would be set to in this case?

Reply 12 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

The problem is not with munt at all. If you use an mt32emu engine (either in the Qt app or the MIDI driver), it sends output to the system sample rate converter.

When it comes to DOSBox internal sound sources, all pass audio output to the mixer. The last time I looked at it, a sort of linear interpolator was used to convert sample rates, and this is not the best option.

Concluding the above (and having DOSBox's mixer as it is):
- if FX quality matters, you should set rate to 44100 (as supported by SB) or 22050 (if the game uses this rate);
- if you want to hear OPL sound at its best, you set the rate to 49716 Hz;
- if you want to get non-distorted MT-32 sound, you sync the mixer rate with the mt32emu output rate.

Ideally, you should have mixer tuned to the SB (or maybe GUS), and have MT-32 and OPL music output sent to the system sample rate converter. While it's easy with munt, a patch is required to do so for OPL.

As for the General MIDI, we need to clarify if DOSBox does the synthesis (e.g. Ykhwong DaumCafe does). If an external synth is used (like bassmidi or vsc), it doesn't matter how you tune the DOSBox mixer 😀

Reply 13 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member

What matters to me is highest sound quality with respect to non-distorted MT-32 sound. Since I'll be using the ECE build, does that mean I should be setting both mixer and oplrate to 48000, or should I set mixer to 48000 and leave oplrate at 41000?

Reply 14 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

What matters to me is highest sound quality with respect to non-distorted MT-32 sound.

If so, I'd just use an external mt32emu engine for awhile.

should I set mixer to 48000 and leave oplrate at 41000

And again, oplrate only affects the output of the OPL synth. If you're going to achieve the highest audio quality, just keep in mind that almost any sample rate conversion using linear interpolation immediately distorts the signal, and sometimes quite obviously (like in the case you've pointed out).

Reply 15 of 54, by KainXVIII

User metadata
Rank Member
Rank
Member
sergm wrote:
Concluding the above (and having DOSBox's mixer as it is): - if FX quality matters, you should set rate to 44100 (as supported b […]
Show full quote

Concluding the above (and having DOSBox's mixer as it is):
- if FX quality matters, you should set rate to 44100 (as supported by SB) or 22050 (if the game uses this rate);
- if you want to hear OPL sound at its best, you set the rate to 49716 Hz;
- if you want to get non-distorted MT-32 sound, you sync the mixer rate with the mt32emu output rate.

Thanks, i'll keep it in mind (but what a hassle 😵 )

Reply 16 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member
sergm wrote:
If so, I'd just use an external mt32emu engine for awhile. […]
Show full quote

What matters to me is highest sound quality with respect to non-distorted MT-32 sound.

If so, I'd just use an external mt32emu engine for awhile.

should I set mixer to 48000 and leave oplrate at 41000

And again, oplrate only affects the output of the OPL synth. If you're going to achieve the highest audio quality, just keep in mind that almost any sample rate conversion using linear interpolation immediately distorts the signal, and sometimes quite obviously (like in the case you've pointed out).

Sergm - Forgive me for being so dense. A lot of this is new to me and I'm trying to make sense of it. I've tried finding other sources that discuss mixer rate and oplrate in dosbox and how they are (or aren't) related, but I haven't had much luck. It seems like a lot of this assumes some amount of prerequisite knowledge which I don't have.

That said, for certain reasons I will be using the ECE build with integrated MUNT, so in this case, I know that mixer rate MUST be set at 48000 to avoid distortion of the MT-32. So, and once again please forgive me if this has already been answered, in this scenario, what should oplrate be set to?

I know that, ideally, I would use external MUNT and then set both mixer rate and oplrate to 49716. But if I'm using ECE, mixer rate must be 48000 - I'm just not sure what I should be setting oplrate to in this scenario.

Reply 17 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

If you set the mixer rate to 48000Hz, then OPL should also produce output at this rate to avoid rate conversion. But just note, any FX that play at other rates will be converted. If the mixer rate was 44100Hz (as per default), and a game outputs sound stream at this rate, the conversion would be avoided completely. But if you set 48000Hz, your FX will pass through the sample rate conversion (since SB did not support this rate). That is why I don't recommend to use such configuration if you really want the highest audio quality. Either you set mixer rate to 44100, 48000, 49716 or 32000Hz, there will be something you'll loose. The total cure would be to incorporate a sample rate conversion library right to DOSBox, so audio may always play at the highest quality. But this is obviously out of munt's scope.

Reply 18 of 54, by lukeman3000

User metadata
Rank Member
Rank
Member
sergm wrote:

If you set the mixer rate to 48000Hz, then OPL should also produce output at this rate to avoid rate conversion. But just note, any FX that play at other rates will be converted

Are you referring to FX that play from the soundblaster? In other words, if an FX was originally recorded at 41000 Hz then it will be converted to 48000 Hz since that's what I have oplrate set to, and I might possibly get some distortion from this? But still it is desirable to have oplrate match mixer rate?

To summarize:

If using r4006 ECE build with integrated MUNT:
mixer rate: 48000
oplrate: 48000
*For non-distorted MT-32. However, FX originally recorded at other rates will be converted

If using external MUNT:
mixer rate: 49716
oplrate: 49716
*For non-distorted MT-32 and non-converted FX

Do I have this right?

Reply 19 of 54, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

The first part is inarguable. The second part will ensure the best available quality for MT-32 and OPL sound, but I think all the FX will degrade (just because 49716 Hz is a very uncommon sample rate).