Munt Reloaded - Development

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

Re: Munt Reloaded - Development

Postby AbbyGelber » 2016-10-18 @ 15:03

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,
AbbyGelber
Newbie
 
Posts: 1
Joined: 2016-10-17 @ 16:18

Re: Munt Reloaded - Development

Postby Dominus » 2016-10-18 @ 15:16

Make sure you enable both sound effects and music and the mt32 in the U7 setup. And latest munt.
User avatar
Dominus
DOSBox Moderator
 
Posts: 7230
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby gdjacobs » 2016-10-18 @ 22:02

Also, you may be interested in trying the GM patches for Ultima 7 for comparison.
User avatar
gdjacobs
l33t
 
Posts: 3593
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby HunterZ » 2016-10-22 @ 16:27

I just got a notice from sourceforge that a Munt 2.0 release is available. What's new?
User avatar
HunterZ
l33t++
 
Posts: 6043
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby collector » 2016-10-22 @ 16:44

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

viewtopic.php?f=40&t=50520
User avatar
collector
l33t
 
Posts: 3919
Joined: 2003-1-15 @ 10:39

Re: Munt Reloaded - Development

Postby gdjacobs » 2017-3-20 @ 17:52

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.
You do not have the required permissions to view the files attached to this post.
User avatar
gdjacobs
l33t
 
Posts: 3593
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby sergm » 2017-3-23 @ 05:53

Great, I'll have a look. Thank you!
sergm
Oldbie
 
Posts: 675
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby HunterZ » 2017-4-09 @ 15:17

Got a notice from Sourceforge that Munt 2.1.0 has been released: https://sourceforge.net/projects/munt/files/munt/2.1.0/
User avatar
HunterZ
l33t++
 
Posts: 6043
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-10 @ 15:57

Yay. I'm reconverting all of my MT-32 game soundtracks right now. :)
NewRisingSun
Oldbie
 
Posts: 750
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby KainXVIII » 2017-4-10 @ 16:46

NewRisingSun wrote:Yay. I'm reconverting all of my MT-32 game soundtracks right now. :)

2.1 version improve quality so much? 8-O
User avatar
KainXVIII
Member
 
Posts: 186
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-10 @ 16:49

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.
NewRisingSun
Oldbie
 
Posts: 750
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-10 @ 20:10

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.
You do not have the required permissions to view the files attached to this post.
NewRisingSun
Oldbie
 
Posts: 750
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby gdjacobs » 2017-4-10 @ 23:32

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.
User avatar
gdjacobs
l33t
 
Posts: 3593
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby NewRisingSun » 2017-4-11 @ 20:04

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.
NewRisingSun
Oldbie
 
Posts: 750
Joined: 2005-9-02 @ 02:26

Re: Munt Reloaded - Development

Postby Spikey » 2017-4-12 @ 02:46

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?
User avatar
Spikey
Member
 
Posts: 185
Joined: 2003-2-04 @ 10:36
Location: South Australia

Re: Munt Reloaded - Development

Postby gdjacobs » 2017-4-12 @ 06:18

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.
User avatar
gdjacobs
l33t
 
Posts: 3593
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby sergm » 2017-4-12 @ 06:54

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.
sergm
Oldbie
 
Posts: 675
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Yesterplay80 » 2017-4-12 @ 08:15

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

Code: Select all
[ 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 (without debugger) for Windows and Linux: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 209
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: Munt Reloaded - Development

Postby sergm » 2017-4-12 @ 08:49

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.
sergm
Oldbie
 
Posts: 675
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Yesterplay80 » 2017-4-13 @ 08:21

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:

Code: Select all
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 (without debugger) for Windows and Linux: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 209
Joined: 2016-2-23 @ 11:02
Location: Germany

PreviousNext

Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 2 guests