I wonder if this is a bug in mt32emu-smf2wav or perhaps in my settings: I am using munt 2.3.0 based Windows executables to convert MIDI files (in this case, Tom Lewandowski's recording of the complete King's Quest 5 soundtrack, page, archive, but it seems to apply to other files too) to WAV. With mt32emu_qt_1_7_1, the playing time of the output WAV is 1:34:35 and as far as I can tell, the sound is correct. With mt32emu_smf2wav_1_5_0, the playing time of the WAV is only 1:18:49 and the tempo is noticeably faster. The music seems to be all there, only much faster than expected. How is that possible? It was my assumption that both renderers use the same emulator code.

The reason I would prefer to use mt32emu-smf2wav over mt32emu-qt is that it supports much better control over the rendering process, e.g. it would let me specify a higher sampling frequency or a more detailed calculation:

pepak wrote:How is that possible? It was my assumption that both renderers use the same emulator code.

Not quite. While the emulation core is shared, the code that processes MIDI files is not. mt32emu-smf2wav uses libsmf to parse standard MIDI files (and perhaps an ancient version of that), while mt32emu-qt contains a minimalistic implementation dedicated to the usage. It could be that the version of libsmf included in mt32emu-smf2wav simply can't handle files which are that large. I'll check if it's worth to update the library or maybe it's easy enough to replace it with the MIDI file parser of mt32emu-qt.

sergm wrote:Well, don't you get some error messages when trying to convert this file using mt32emu-smf2wav?

Apparently I do. I didn't notice them before. And, to be honest, I wouldn't know what to do about them anyway - the content doesn't seem truncated, only playing at a much higher tempo.

Not quite. While the emulation core is shared, the code that processes MIDI files is not. mt32emu-smf2wav uses libsmf to parse standard MIDI files (and perhaps an ancient version of that), while mt32emu-qt contains a minimalistic implementation dedicated to the usage. It could be that the version of libsmf included in mt32emu-smf2wav simply can't handle files which are that large. I'll check if it's worth to update the library or maybe it's easy enough to replace it with the MIDI file parser of mt32emu-qt.

Thanks for the explanation. I would appreciate a fix either way - either by updating the -smf2wav engine, or by providing rendering options to -qt.

It appears, mt32emu-smf2wav truncates something that doesn't affect sounding much, probably some unsupported meta data. On the other hand, we seemingly have here a genuine tempo issue. That file has BPM set to 100, and mt32emu-qt recognises this properly. For instance, if you try to play this file using the "Play MIDI file..." menu option, you'll see the actual tempo in the bottom right of the MIDI player window. But mt32emu-smf2wav seems to default to 120 BPM, and does not recognise the Tempo meta event (or exactly that event was truncated? Need to check...).

Anyway, both mt32emu-smf2wav and mt32emu-qt do not provide you with an option to override the tempo, and this doesn't seem right. I'll try to deal with it next week, so it'll be an easy way to force the right tempo regardless of what can be read from the MIDI file. Apparently, there are files that really contain invalid Tempo values. It's easy to achieve e.g. with Cakewalk by opening a MIDI file written with 120 BPM in mind but which does not contain the Tempo meta event, and then saving it. Cakewalk uses 100 BPM as the default, and does write it in the MIDI file. After that, the MIDI file gets broken

UPD: libsmf evidently supports Tempo changes. So, I only suspect that the Tempo track was truncated...

Ugh, the version of libsmf we use really has a bug in parsing meta events with sizes > 130 bytes, so everything later the address 0x4986 in track 1 of that file isn't processed (including the Tempo change event).

Yikes. I suppose libsmf is dead by now... The mainstream version at SF still contains this bug, and it claims that the development has been moved to github, but the link is 404. I can find a fork at github but it sill contains that bug...

Perhaps it wouldn't be too difficult to add sample rate and bit depth support to mt32emu-qt? Then mt32emu-smf2wav could get removed, or at least the bug should be documented so that other people don't make the same mistake I did?

As for the future of mt32emu-smf2wav, I'd consider it deprecated. However, many guys find it more useful being a small console tool.Indeed, I wish to improve mt32emu-qt, and likely refactor it, so it may be more useful in the console mode too.

Myself, I would prefer a command line utility every day, but not if it depends on a library which seems to have serious bugs and is not maintained anymore. In that case, a maintained GUI app is the preferred choice.