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,
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.
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.
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.
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.
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.
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.
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.
I tried to compile a static library of the new mt32emu but run into this error no matter what I do:
1[ 14%] Building CXX object CMakeFiles/mt32emu.dir/src/FileStream.cpp.obj 2In file included from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\bits\locale_facets.h:39:0, 3 from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\bits\basic_ios.h:37, 4 from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\ios:44, 5 from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\istream:38, 6 from c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\fstream:38, 7 from C:\DOSBox\msys\1.0\home\<MYUSERNAME>\munt-2.1.0\mt32emu\src\FileStream.h:21, 8 from C:\DOSBox\msys\1.0\home\<MYUSERNAME>\munt-2.1.0\mt32emu\src\FileStream.cpp:20: 9c:\dosbox\lib\gcc\mingw32\5.3.0\include\c++\cwctype:89:11: error: '::iswblank' has not been declared 10 using ::iswblank; 11 ^ 12CMakeFiles\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.
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.
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:
1In file included from midi.cpp:77:0: 2midi_mt32.h:27:11: error: 'Service' in namespace 'MT32Emu' does not name a type 3 MT32Emu::Service *service; 4 ^ 5midi_mt32.h:42:9: error: 'mt32emu_report_handler_i' does not name a type 6 static mt32emu_report_handler_i getReportHandlerInterface(); 7 ^ 8midi_mt32.h: In member function 'Bit32u MidiHandler_mt32::getMidiEventTimestamp( 9)': 10midi_mt32.h:48:10: error: 'service' was not declared in this scope 11 return service->convertOutputToSynthTimestamp(Bit32u(playedBuffers * framesPe 12rAudioBuffer + (playPos >> 1))); 13 ^ 14make: *** [midi.o] Error 1
Do you have any ideas what could cause this and how I could resolve it?