Topic: XMPlay MIDI plugin

[quanta]

When trying to play an empty XMI MIDI file (see EMPTY.XMI from attachment EMPTY.ZIP) using XMPlay MIDI plugin, XMPlay automatically strikes out the file with a single line (ie: marked unplayable). However, when trying to play the struck out file again, eventually the following dialogue box appears:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01b95580.
Registers:
EAX=05acd500 CS=018f EIP=01b95580 EFLGS=00210212
EBX=00000003 SS=0197 ESP=0077cb40 EBP=0077cb6c
ECX=0625e6bc DS=0197 ESI=0000000c FS=6d2f
EDX=008dab5c ES=0197 EDI=007911c4 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 ba 01 59 c3 53
Stack dump:
01ba1565 007911c4 007911c8 00000003 00000000 00000388 0077c970 0077cba4 01ba19d0 01ba3060 00000000 0077cbb0 01b953fe 0625e6bc 0000000c 007911bf

After the dialogue box is closed, another one appears:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01b95580.
Registers:
EAX=0077c724 CS=018f EIP=01b95580 EFLGS=00210202
EBX=01ba3060 SS=0197 ESP=0077c6e0 EBP=0077c708
ECX=0625e6b0 DS=0197 ESI=00000000 FS=6d2f
EDX=bff768fa ES=0197 EDI=8191c710 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 ba 01 59 c3 53
Stack dump:
01ba15da 8191c710 00000000 01ba3060 0077c6e4 0077c510 0077c724 01ba19d0 01ba3070 00000000 0077cb6c 01ba159f 0625e6b0 0000000c 007911be 01b95580

After closing error dialogue box again, the third error dialogue box appears after XMPlay windows are closed:

XMPLAY caused an invalid page fault in
module IN_TXT.DLL at 018f:01bd23ee.
Registers:
EAX=02240690 CS=018f EIP=01bd23ee EFLGS=00010206
EBX=00000001 SS=0197 ESP=0367fc30 EBP=0367fc70
ECX=7ffce00c DS=0197 ESI=01d00ef4 FS=942f
EDX=c00309fc ES=0197 EDI=00000001 GS=0000
Bytes at CS:EIP:
8b 08 50 ff 51 08 c3 e8 05 00 00 00 e9 0a 00 00
Stack dump:
01bd70e1 00000000 01bd0000 00000001 01bd7084 00000000 00000000 00000001 01bd43e4 01bd447c 01bd0000 00000000 00000001 00000000 01bd0000 819253dc

The number of times needed to trigger the error varies between XMPlay sessions without specific pattern, but XMPlay is more likely to crash if the playlist only has dead file(s). After comparing with XMI MIDI files from Buck Rogers Matrix Cubed[1], it seems the empty XMI MIDI file has 16 bytes at the beginning of the actual file header. After removing the extra contents from the beginning of the, XMPlay properly recognizes and plays the MIDI file without crashing. Even so, XMPlay should never have crashed when trying to play unplayable files.

[1] http://www.old-games.com/download/3900/buck-rogers-matrix-cubed

[quanta]

When playing a MIDI file using XMPlay MIDI plugin, choosing 'Piugin file info' context menu item causes XMPlay to crash with following errors:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01765580.
Registers:
EAX=1df06f70 CS=018f EIP=01765580 EFLGS=00210202
EBX=00773403 SS=0197 ESP=00772f70 EBP=00772f9c
ECX=1e7b8de0 DS=0197 ESI=0000000c FS=0ecf
EDX=008b000c ES=0197 EDI=008b1e78 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 77 01 59 c3 53
Stack dump:
01771565 008b1e78 008b1e7c 00773403 00000000 00008e15 00772da0 00772fd4 017719d0 01773060 00000000 00772fe0 017653fe 1e7b8de0 0000000c 027eb3f3

After closing the dialogue box, sometimes another dialogue box with following message appears:

XMPLAY caused an invalid page fault in
module IN_MIDI.DLL at 018f:01765580.
Registers:
EAX=00772b54 CS=018f EIP=01765580 EFLGS=00210216
EBX=01773060 SS=0197 ESP=00772b10 EBP=00772b38
ECX=1e7b8dd4 DS=0197 ESI=00000000 FS=0ecf
EDX=bff768fa ES=0197 EDI=818f3878 GS=0000
Bytes at CS:EIP:
8b 01 85 c0 74 08 50 ff 15 d8 20 77 01 59 c3 53
Stack dump:
017715da 818f3878 00000000 01773060 00772b14 00772940 00772b54 017719d0 01773070 00000000 00772f9c 0177159f 1e7b8dd4 0000000c 027eb3f2 01765580

However, if the Stu003 Text-Speech plugin v1.01 was loaded, this second dialouge box with following message appears:

XMPLAY caused an invalid page fault in
module IN_TXT.DLL at 018f:017a23ee.
Registers:
EAX=020506e0 CS=018f EIP=017a23ee EFLGS=00210202
EBX=00000001 SS=0197 ESP=0357fc30 EBP=0357fc70
ECX=7ffce00c DS=0197 ESI=01b10ef4 FS=50df
EDX=c00309fc ES=0197 EDI=00000001 GS=0000
Bytes at CS:EIP:
8b 08 50 ff 51 08 c3 e8 05 00 00 00 e9 0a 00 00
Stack dump:
017a70e1 00000000 017a0000 00000001 017a7084 00000000 00000000 00000001 017a43e4 017a447c 017a0000 00000000 00000001 00000000 017a0000 8196f804

The bug does not occur if 'Plugin file info' command is chosen when playing a file that is not in archive. In any case, XMPlay should never crash, and it should allow users to use 'Plugin file info' command when playing a file that is inside an archive.

[Ian @ un4seen]

Tested system
=============
OS: Windows 98SE
Memory: 384MB
CPU: Intel Pentium II 400
Sound: ESS Solo-1
Video: Neomagic MagicMedia 256AV
XMPlay version: 3.8.0.16

When changing XMPlay MIDI plugin's performance decreases when updating from rev.12a to rev.14. Specifically, the amount of active voices in MIDI mixer can reach 107 without going red in rev.12a plugin, but the active voices value reaches red in rev.14 plugin with as little as 90 voices.

Using the NULL output plugin to compare how long it takes the 2 versions to process a MIDI file, rev.14 is actually a bit faster than rev.12 for me. If you would like to try that, you can get the NULL output plugin here:

   www.un4seen.com/stuff/xmp-null.dll

Go to the "NULL" page in the "Options and stuff" window to see how long it took to process each file.

Regarding why you're seeing voices killed earlier with rev.14, perhaps it is limiting the CPU usage earlier/lower (I don't recall if it does). Does Task Manager show rev.14 using more CPU than rev.12 when playing the same part of the same MIDI file with the same settings?

When trying to play an empty XMI MIDI file (see EMPTY.XMI from attachment EMPTY.ZIP) using XMPlay MIDI plugin, XMPlay automatically strikes out the file with a single line (ie: marked unplayable). However, when trying to play the struck out file again, eventually the following dialogue box appears:
...

That and the other crashes are all in Winamp plugins (IN_MIDI.DLL and IN_TXT.DLL), so I'm not sure there's much that can be done about that. If you remove those 2 plugins, do you still get crashing in the same scenarios?

[Krstfr]

The file in the zip crashes the midi plugin upon scanning.

[winner]

The file in the zip crashes the midi plugin upon scanning.

The .mid file is only 14 bytes in length. It is incomplete and corrupt.

[Krstfr]

The .mid file is only 14 bytes in length. It is incomplete and corrupt.

Isn't it still kind of bad that it crashes XMPlay though?

[saga]

Exactly. No matter how broken, it simply shouldn't crash.

[Ian @ un4seen]

Here's an update to fix that problem (by rejecting MIDI files with 0 tracks):

   www.un4seen.com/stuff/xmp-midi.dll

This update also introduces improved sinc interpolation (using 16 points instead of 8) with CPUs that support SSE2 (8 points will still be used with older CPUs).

[dsp2003]

Hey, Ian. Thank you for working on the MIDI plugin so far. With the last update, I've finally got proper reproduction of my Japanese SoundCanvas MIDI cover collection. :3

Any plans on implementing more XG variation filters?

[GM88]

Something seems wrong with the vibrato algorithm like it's applying too much of it.  Dozens of songs I've tried has this problem. The vibrato sounds twice as strong as it should be.

[Ian @ un4seen]

Any plans on implementing more XG variation filters?

There aren't any immediate plans for that, but it is something that I would like to see supported eventually.

Something seems wrong with the vibrato algorithm like it's applying too much of it.  Dozens of songs I've tried has this problem. The vibrato sounds twice as strong as it should be.

Is that happening when using a particular soundfont or is it happening with all soundfonts? Also, is it a particular preset in a particular soundfont that's affected? If so, please state which. If you have a MIDI file that clearly demonstrates the problem, please also upload that to try here:

   ftp.un4seen.com/incoming/

[GM88]

I don't know how to upload to ftp, but you can find one midi demonstrating the problem in this archive file.

http://psrtutorial.com/songs/Yamaha/XGByComposer.zip
The file is "Cool by Dave Kelly.mid" in the Dave Kelly folder.

I tried several different soundfonts. Same problem.

[Ian @ un4seen]

Your example MIDI file seems to sound OK with the ChoriumRevA and WeedsGM3 soundfonts that are available from the XMPlay webpage? If those 2 are fine for you too, please state the soundfont(s) that you have found to be affected.

[piovrauz]

I think I spotted a small bug: I got this archive:

http://leejacksonaudio.lbjackson.com/GrabbagOriginalVersionMIDI.zip

if I try to drag and drop on XMPlay, XMPlay crashes;  the rar contains 2 midi files, one text file and a file without estension.
If I remove the file without estension, I can drag and drop succesfully, so it appears that files withouth extension can crash XMPlay.
I think this should not happen. Is there any way to fix this? Thanks.

[Dotpitch]

if I try to drag and drop on XMPlay, XMPlay crashes;  the rar contains 2 midi files, one text file and a file without estension. If I remove the file without estension, I can drag and drop succesfully, so it appears that files withouth extension can crash XMPlay. I think this should not happen. Is there any way to fix this? Thanks.

It doesn't crash here. I think it's an input plugin crashing on that file, usually xmp-ffmpeg or xmp-dshow. Could you try with just XMPlay, xmp-zip and xmp-midi?

[piovrauz]

I will try with vanilla XMPlay and report the result; I don't have xmp-ffmpeg nor xmp-dshow, I know they're trouble and axed them.
Btw, I set .mid as priority filetype for the midi plugin in case it matters.

EDIT: I could investigate faster than I tought; it seems it was caused by libg719_decode.dll and libg7221_decode.dll being present at the same time...
Removing the older one fixes the crash. I still don't get why it crashed nor why there were 2 different dlls but I guess it slipped when manual updating.

[kode54]

libg719_decode.dll and libg7221_decode.dll being present at the same time

Those are two different codecs, and whatever imports them probably needs both, or will fail to load.

[Dotpitch]

Those are two different codecs, and whatever imports them probably needs both, or will fail to load.

Don't they both belong to in_vgm?

[piovrauz]

All of them are from "xmp-vgmstream", that I used sometime ago.
btw, I removed all files related to xmp-vgmstream for now.

[sevendy]

None of the version 14's properly load multiple bank soundfonts. For instance, in version 13 and prior, I have a two-bank file "added" at bank 042, with two banks displayed in the config window at 042 and 043. In version 14, bank 043 does not appear in the config, nor does it sound correctly. Reverting to version 13, and bank 043 magically reappears.

[winner]

None of the version 14's properly load multiple bank soundfonts. For instance, in version 13 and prior, I have a two-bank file "added" at bank 042, with two banks displayed in the config window at 042 and 043. In version 14, bank 043 does not appear in the config, nor does it sound correctly. Reverting to version 13, and bank 043 magically reappears.

Would the soundfont be jeux14.sf2? This is a two-bank file and I can confirm that in Midi plugin 14f it does not load in banks 042 and 043 as I know it did in previous Midi plugin versions. Maybe all of the 14 versions (a, b, c, etc.) show this behavior for this soundfont, but I can't say that I've seen this with any other multiple bank soundfonts.

[sevendy]

Exactly: Jeux14; but also another organ Soundfont, "Stefans" in 80-85. You're right though--I hadn't noticed this, but another multiple bank soundfont does seem to load correctly: the old Sound Blaster "4GMGSMT". I used Rundt's "Viena" to create a two-bank soundfont, and it behaved like Jeux14--the second bank doesn't show up in version 14.

[Ian @ un4seen]

None of the version 14's properly load multiple bank soundfonts. For instance, in version 13 and prior, I have a two-bank file "added" at bank 042, with two banks displayed in the config window at 042 and 043. In version 14, bank 043 does not appear in the config, nor does it sound correctly. Reverting to version 13, and bank 043 magically reappears.

Rev.14 did indeed change how multi-bank soundfonts are used when assigned to a non-0 bank. Previously, the assigned bank would become a base number that's added to all of the soundfont's banks, but that didn't seem particularly useful/desirable, so now only the assigned bank from the soundfont is used in the assigned bank; if the soundfont doesn't contain that bank, then its bank 0 (or 128 for drums) is used.

Do you actually need the soundfont's bank 1 to be used in bank 43 in your case, or are you just reporting the change that you've observed?

[sevendy]

Rev.14 did indeed change how multi-bank soundfonts are used when assigned to a non-0 bank. Previously, the assigned bank would become a base number that's added to all of the soundfont's banks, but that didn't seem particularly useful/desirable, so now only the assigned bank from the soundfont is used in the assigned bank; if the soundfont doesn't contain that bank, then its bank 0 (or 128 for drums) is used.

Do you actually need the soundfont's bank 1 to be used in bank 43 in your case, or are you just reporting the change that you've observed?

Yes, I certainly do need the old behavior to play existing MIDI files which assume banks 42 and 43 (Jeux14) or 80-85 (Stefans). Is there some way to manually load the secondary banks from soundfont files into arbitrary locations? On the other hand, I am content to stay with version 13, which is entirely adequate for my needs.

I brought this to your attention because I didn't understand that the old behaviour was considered a bug. If I recall correctly, the old behavior is consistent with how the old SBLive worked "in hardware".

[saga]

I am content to stay with version 13, which is entirely adequate for my needs.

You could simply render the few MIDI files that need this old behaviour to FLAC and then go on with the times.