VOGONS


Munt Reloaded - Development

Topic actions

Reply 780 of 964, by AbbyGelber

User metadata
Rank Newbie
Rank
Newbie

Hi..i am a new user here. In my case the intro of Ultima 7 - The Black Gate. It is a real MT32 recording of the intro. It's three parts, the middle part is ok with munt. The problem is especially with the first part, the birds chirping. With munt you only hear some kind of effect when you turn the volume very high and even then it is not the correct one. The third part might be almost correct now,

turnkey pcb

Reply 781 of 964, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Make sure you enable both sound effects and music and the mt32 in the U7 setup. And latest munt.

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 782 of 964, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Also, you may be interested in trying the GM patches for Ultima 7 for comparison.

All hail the Great Capacitor Brand Finder

Reply 784 of 964, by collector

User metadata
Rank l33t
Rank
l33t
HunterZ wrote:

I just got a notice from sourceforge that a Munt 2.0 release is available. What's new?

Munt 2.0.0 released

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

Reply 785 of 964, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

I've created a patch for mt32d and xmt32 to allow selection of either the MT32 or CM32L ROMs via command line switch. Hopefully it will be useful for others as well. Please let me know if it looks reasonable or if you'd like changes made. I'm hoping for convenience that this kind of functionality can be mainlined.

Edit: The patch had an inconsistent setting between the mode default (int mode=2) and the usage notes (CM32L is the default mode). Either mode should be initialized to 1 or MT32 should be the default. This version is corrected for the error.

Attachments

  • Filename
    romset.patch
    File size
    4.65 KiB
    Downloads
    20 downloads
    File license
    Fair use/fair dealing exception

All hail the Great Capacitor Brand Finder

Reply 790 of 964, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

32 bits float, baby.

Which brings up the question: is there such a thing as clipping with float samples? This post would suggest there is not, but maybe MUNT clips internally even in float rendering mode.

Edit: Hah, it never clips. I can convert King's Quest IV's logo music with the extremely loud horns at 100% main volume. The resulting .wav file does heavily clip when played in Audacity without modification, but when I normalize it, it actually reduces the amplitude by 12 db and produces a beautiful non-clipped waveform.

The only disadvantage is that FLAC does not handle 32 bit float --- I first have to find out the peak value to scale the entire set of .wav files of a game's soundtrack to avoid clipping, then convert to 24 bit integer, then FLAC everything.

Reply 791 of 964, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Let me be the first to congratulate sergm on another fine release. Let me also be the first to immediately nitpick. 😀

I think there might be some residual uninitialized data left in the reverb code. When I use smf2wav (64 bit) with the float renderer, MT-32 ROMs, a .SYX file that changes reverb and a .MID file that has a second of silence at the beginning (attached), the resulting wave file has non-zero floating point samples at the beginning. It's so quiet that these samples do become zeros when converting to 24 bit integer, but when normalizing the original float samples in Audacity, it sounds like a typical "reverb change boom". I only noticed it because it messes up my silence detection code in my processing chain.

Attachments

  • Filename
    reverbBoom.zip
    File size
    733 Bytes
    Downloads
    17 downloads
    File license
    Fair use/fair dealing exception

Reply 792 of 964, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

32 bit floats have their purpose. It's probably what I'd use if I wanted to create an MT-32 sample based remix track. However, I'm not too excited about it from a listening point of view.

32 bit float is useful from an audio engineering standpoint as it effectively lifts the limit on dynamic range for all intermediate stages of the pipeline, but I question the utility for the end user. I would expect 24 bit integer samples with proper gain settings to be more than sufficient for listening purposes as it's already superior to 24 bit DACs on the best output hardware (which are already far superior in precision to our ears). If your audio isn't mixed with DAC headroom in mind, you'll have to do some range compression so as not to lose soft segments of the audio when it's renormalized to prevent clipping.

All hail the Great Capacitor Brand Finder

Reply 793 of 964, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Here is more evidence of remaining problems with the v1.07 MT-32 ROM using smf2wav x64 from MUNT v2.1.0. The archive contains an initialization sysex and a MIDI file from "The Colonel's Bequest".

Here is how it sounds with CM-32L ROMs (correct). And here is how it sounds with MT-32 v1.07 ROMs. Note the strange low-frequency drone which is not supposed to be there. I don't know whether it's a reverb problem or something pecular to that swamp sound effect timbre.

Reply 794 of 964, by Spikey

User metadata
Rank Member
Rank
Member

gdjacobs:

32 bit floats have their purpose. It's probably what I'd use if I wanted to create an MT-32 sample based remix track. However, I'm not too excited about it from a listening point of view.

Just curious about this statement. What would be undesirable about a higher quality render from a listening point of view? Potential inaccuracy?

Reply 795 of 964, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Considering the MT-32 was designed to operate electrically in far less dynamic range than presented by a 32 bit internal representation, I'm skeptical that there will be great benefit to using floating point in the engine for straight listening (unless amplitude is set into clipping, as above). Furthermore, even if floating point is used in the Munt engine, there will be no further listening benefit to outputting float samples as the PCM data will have to be normalized (possibly with compression), converted to integer, and decimated for playback anyway.

The advantage is being able to have vast dynamic range preserving both soft and extraordinarily loud sections which might all become important further along in an audio processing pipeline where the limit of playback hardware not to mention human hearing isn't such a factor.

All hail the Great Capacitor Brand Finder

Reply 796 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

I can add one more point. Even if the float wave generator can produce more precise output for the synth partials, the PCM partials are still 16-bit and only linearly interpolated, so the effect of the float engine is very limited in this case.

Reply 797 of 964, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I tried to compile a static library of the new mt32emu but run into this error no matter what I do:

[ 14%] Building CXX object CMakeFiles/mt32emu.dir/src/FileStream.cpp.obj
In file included from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\bits\locale_facets.h:39:0,
from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\bits\basic_ios.h:37,
from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\ios:44,
from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\istream:38,
from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\fstream:38,
from C:\DOSBox\msys\1.0\home\<MYUSERNAME>\munt-2.1.0\mt32emu\src\FileStream.h:21,
from C:\DOSBox\msys\1.0\home\<MYUSERNAME>\munt-2.1.0\mt32emu\src\FileStream.cpp:20:
c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\cwctype:89:11: error: '::iswblank' has not been declared
using ::iswblank;
^
CMakeFiles\mt32emu.dir\build.make:137: recipe for target 'CMakeFiles/mt32emu.dir/src/FileStream.cpp.obj' failed

I already made sure MinGW is up to date. Any idea what I might do wrong?

UPDATE: I tried to compile the older 2.0.0 release, but ran into the same error.

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

Reply 798 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:

I already made sure MinGW is up to date. Any idea what I might do wrong?

Obviously, this is exactly what you did wrong. It compiled fine even early in March before they updated the C++ runtime. I'd recommend to forget about MinGW due to its quite poor support atm. Better switch to MinGW-W64 or MSYS2, as many do now.

Reply 799 of 964, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

OK, I managed to build a static library using MSYS2/MINGW64-i686. Bun now I run into errors when I compile DOSBox using MT32EMU and the patch provided:

If I disable libmt32emu_SHARED and libmt32emu_C_INTERFACE in CMake, compilation of DOSBox fails with "Incompatible setting MT32EMU_API_TYPE=3". Alright, according to config.h, this means that I should have left libmt32emu_C_INTERFACE enabled, because TYPE=3 includes all features from all interfaces. I was able to compile DOSBox with a new build of MT32EMU with both interfaces, C++ anc C, enabled. But it crashes whenever I try to use MT32 as MIDI device.

I then changed +#define MT32EMU_API_TYPE 3 in the patch file to +#define MT32EMU_API_TYPE 0, because I hoped that using only the c++ interface would work, as it did with version 2.0.0. But now I get the following error when I try to compile DOSBox:

In file included from midi.cpp:77:0:
midi_mt32.h:27:11: error: 'Service' in namespace 'MT32Emu' does not name a type
MT32Emu::Service *service;
^
midi_mt32.h:42:9: error: 'mt32emu_report_handler_i' does not name a type
static mt32emu_report_handler_i getReportHandlerInterface();
^
midi_mt32.h: In member function 'Bit32u MidiHandler_mt32::getMidiEventTimestamp(
)':
midi_mt32.h:48:10: error: 'service' was not declared in this scope
return service->convertOutputToSynthTimestamp(Bit32u(playedBuffers * framesPe
rAudioBuffer + (playPos >> 1)));
^
make[3]: *** [midi.o] Error 1

Do you have any ideas what could cause this and how I could resolve it?

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