I have this broken MIDI which sounds broken a different way on every platform I try it and w/every soundfont. Most of it sounds fine, until about 3:55. At that point is sometimes sounds scratchy then dies, or becomes cacophonous, one guy actually reported it sounds fine until the end when it gets quiet. I tried using software called Rosegarden in Ubuntu to analyze it, but it doesn't seem to have any kind of repair feature and I couldn't even get the sound to work anyway. What's the proper way of going about this?
Of course, if you just want to give a man a fish, that's fine too. Here it is.

I've just run it through DECODE, which turns it into a text file so it can be easily inspected. You said the file was damaged, so I was expecting this conversion to give a problem, however, the process completed fine, and I have a complete .TXT version of your .MID file. So I'd suggest that the file is NOT damaged or broken, and the integrity of the midi data is OK.

I'll need to try playing it, various ways, and see what it sounds like, but I suspect that the problem is musical rather than with the structure of the data, hence I'd guess that any program 'fix' process will NOT find anything to 'fix'!

Maybe something it happening regarding instruments selected (Program Changes) or one or more controllers are changing the sound into something that isn't nice to listen to. Or maybe there's data there that just does NOT work with the specific devices/processes you're using to create the sounds (virtual instruments of hardware?) I'll try both?

There are no text items in the file to help, so if I see PC items I do NOT know what instrument they are supposed to be. I'll assume GM?

I've just played your file back using SYNTHFONT with the Timbres of heaven SF2 file.

Sounds perfectly fine to me.

However, once I remove the earplugs...

Well, i recognise a couple of bits, one sounds a bit like Gershwin, and another suggests a hint of Borodin's Polovtsian Dances, and maybe there are suggestions of other things in there too that I've just not sussed yet, but MOST of the file plays and sounds OK. There are two places where the sound breaks up, about bar 51.2 and 112.0, and at these points I note that far too many notes are playing and the CPU load goes to 100% which is NOT a good thing. That's probably the problem, too many Note ON and/or missing Note OFF.

I'll try to work out just where in the file - I need to note the timings and not the bar.

I see you use 16 tracks, why not use more? You can use 16 midi channels, but you use 2 to 9 only. Almost all (except Tr 7) include program changes, so you're making things difficult to keep tracks of things, which may have given rise to the problems?

The GM soundset seems to be OK - there were a couple of places where I wondered if the instrument was not correct for the music, but this was a tiny part of the overall piece and it's prob just my taste!

Note that SYNTHFONT recovered from the overloads quite OK. Other systems might NOT. This might explain why someone said it all went wrong about 3:55 but another said it was OK until near the end.

However, I'd repeat. The data structure of the file seems OK. The file is not damaged/broken. The problem IS with the musical data within the file, which will require HUMAN attention.

I've still not spotted the 'smoking gun' regarding the problem with this file, but I have noted some distinct oddities.

The switching between instruments (via PC - Program Change instructions) seems rather odd, especially when you have two tracks which APPEAR to be using the same Channel (but actually may not be - see below) are seeming to start with the same patch/instrument (fair enough) but then change separately to different instruments later.

Various of the tracks (most ?) seem to contain PC instructions assigned for a specific Channel, followed by note data for a different channel, and no note data for the channel to which the PC was set.

Things like this are not necessarily WRONG, but they will make the midi data far more difficult to keep track of. Making more consistent use of the available tracks (maybe many, depending on your software) and the midi Channels (limited to 16, usually) usually make it much easier to keep track of which notes are playing which instrument.

Going now to my old midi machine. The antique. Although, I've got much more antique machines here.

This is a Pentium 75 running MSDOS 5.0. Got a Roland LAPC-I sound card installed, although in this case I've got the internal sounds muted, and am using midi thru-put to a Yamaha MU90r tone module.

Using an old DOS program called 'Play' (part of Midi Tools package from kevin Weiner).

Your midi file loads fine, shows total time of 5:26. The Channel/Tracks listing looks somewhat unusual, as two channels are using two tracks each, 3 channels are using 5 tracks each, and 4 channels are using 4 tracks each, and most tracks are using 2 channels and some are even using 3. Way, way too much overlapping there.

Pressed play.

But HEY, this sounds MUCH MUCH better than the sound produced by SYNTHFONT (virtual synth etc) on the Windoze machine. Massively clearer/crisper sound, better drums (need to work out why drums seemed NOT or barely to be there on the virtual synth). No hint of any break-up of the sound (then the computer is merely sending midi data out the data port and the Yamaha is doing all the sound creating work). However, near the end, at about 4:20 of the 5:26 total, certain notes start up and just drone on and on. Quite clear and normal sounding, just no OFF! The notes keep on playing even after the 5:26 has come. The display on the Yamaha shows notes playing on Ch 2 and 3. The software suggests that nothing is playing.

But the overall sound is SO MUCH MORE preferable. The piece is so much more musical. Maybe too much fading up/down, with uneven levels. But VERY NICE overall.

You never said, what setup did you create the piece for? How does it play on that? What set-up's were causing problems?

One problem I can see: The channel 3 sustain pedal is left on at measure 82, and the channel 2 sustain pedal is left on at measure 103.

Note: I suspect this MIDI file was made by copying snippets from several MIDI files into one composition. This could be the reason each channel appears over various tracks. It will be easier to work with the file by first moving each channel into its own track.

I like to use Sekaiju, a free MIDI sequencer for Windows: http://openmidiproject.osdn.jp/Sekaiju_en.html . The attached text file shows how you can use Sekaiju to move each channel to its own track, then find and remove the events that leave the sustain pedal on.

My previous post explained how to fix the issue, but didn't really explain how to investigate these kinds of problems.

When you have a MIDI file that seems to be misbehaving, it's helpful to look at the problem area in the event list of a MIDI sequencer.

In this case, when I played the MIDI file, I did indeed encounter cacophony starting around 3:55 as Angus reported. So I started looking at the event list around that time.

In Sekaiju's event list, I unchecked Note On and Note Off to focus on other kinds of events, and right away noticed a sustain pedal event (Control Change 64) that was leaving the sustain pedal on. I deleted it, but when I repositioned to a little before 3:55 and clicked play, I still heard notes getting stuck on. (In fact the problem sounded worse, but I now suspect that was because the distribution of channels over various tracks in this file was making it difficult for Sekaiju to keep track of the current status of controller values.)

I re-started from the original file, set up the event list to show just the Control Change events, then exported the list to a CSV file. I opened the CSV file in a spreadsheet application, then played with the data to just keep Control Change 64 events and remove other Control numbers, sort the data by channel and time, then looked at the last Control Change 64 event for each channel. This helped me find both the channel 3 and channel 2 sustain pedal events that were leaving the sustain pedal on.

When I went back to the Sekaiju event list to delete the problem sustain pedal events, I was getting confused by the tracks having various channels on them, so I used the trick of converting to Format 0 then converting back to Format 1 to move the channels to individual tracks. This helped me be more confident I was locating and deleting the correct sustain pedal events that were causing the issues.

I'd not seen the problem with the sustain pedal being left on, although I was having a quick look for something like that. The way that data is spread about regarding Tracks and Channels does not help anyone, of course.

Various of the utilities I have allow midi files to be re-arranged regarding tracks/channels, as you suggest. Not gone that far yet.

Interesting that my 'antique' setup seems not to be troubled at all by the sustain being left on. Dependant I guess on how the playing software handles that, I assume the command is sent, then forgotten about, while the tone module receives the setting and then does it's own thing with it and must turn it off on its own regardless. The 'virtual' setup, however, must be doing something like noting the sustain is on and repeatedly re-forming the sound to generate the sustain artificially. Maybe it does eventually 'time out' but not until the CPU is overloaded?

Oh, I think I can spot a couple of notes being left ON at the end of the piece. On Ch 2 and 3. Again, a difference in how this is handled.? The 'virtual' setup seemed not to be bothered, I'd guess the 'End of Track' maybe forced an OFF. Meanwhile the 'antique' setup, having sent the ON to the tone module, did nothing and left the TM happily playing the note for ever?

Well, thank you for the enthusiastic responses!
Thing is, I didn't make this MIDI. It was rendered probably before I even knew was MIDI was and based on a Dos game. If you look to the bottom of this list, you can find a zip of 50 other MIDIs to give you an idea of what they are like.
WC2-48.MID is a medley, played at the end of the game, so the hypothesis that it is a concatenation of other MIDIs might be right. However, I find myself wondering if they extracted the MIDI data from the program code or just rerendered the music themselves to create these MIDI files. If the former, why did this one give them trouble? If the latter why did this one give them trouble?
So I followed the instructions on how to remove those pesky sustains, and it sounds better, but it still doesn't sound right and still gets quiet early. I take it that the extra music is simply not in WC2-48.MID. It definitely should have been, because if you listen to WC2-45.MID, you'll see that it opens differently and goes on for much more than the 15 seconds or so in WC2-48.MID. Perhaps it falls to me to apply it.

Yes, I sort of wondered if it was from a game, it had the feel of that.

I'm not sure how old Wing Commander is, but the file may have been constructed to work with specific hardware. I'd guess it's been 'converted' to be GM.

Really, it played back fine on my 'antique' setup as described above. This may be more in keeping with the setup it was created on/for.

You have NOT described what setup you're trying to play it back on, which is not helpful.

The data I was looking at shows a LOT of realtime messing with volume settings, fading sections out, fading new sections in. These work fine on my setup. Clearly they do not on (some ?) of your's You need to look at that. I think these are 'master' levels, i.e. not specific to any Channel. But the setting of these will inter-relate with the channel settings as well, and it could be a problem depending on how your setup handles that relationship between the master volume setting, and the indiv 'velocity' (i.e. volume) settings for the channels.

An interesting problem which I've just started to take a look at.
The first thing was to load it into a program other than Sekaiju, which is a great program, but it doesn't show exactly what's going on.

My preference is an ancient sequencer by Yamaha called XGworks (a sequencing program from the nineties).
This shows the uploaded file to consist of many track (or should that be channel) fragments in what can only be described as a seemingly random order.
See the image WC2-48-01.

If you observe the left of the image you will see that the channel assignment is in no order whatsoever (that I can discover).
(I can't get Sekaiju to do this. Can you?)
The first thing I observed was that there's no observable channel 1 usage in XGworks but there is in Sekaiju.
What I read into that is that all the meta events have been inserted into channel one instead of into the header track.
(XGworks has automatically reassigned all these and thus emptied channel one of data.)
These appear as shown in WC2-48-03.

Taking this and aligning all the channels together in the correct order has produced the image in WC2-48-02.
(You'll probably notice that XGworks has done some "tidying" of the lengths of some tracks where there are no MIDI events.)
This allows (me at least) to have a clearer overview of what's going on, and then to be able to look at a channel's worth of events more easily.

Wing Commander II is circa 1990, and it worked on a SoundBlaster 16. I always assumed that meant it had a GM track, as well as several others (I can confirm it also had an AdLib).

I've got several setups, which is how I know it sounds different (but never correct) on every one of them, but I suppose my first choice for testing is Audacious in Ubuntu 16.04 using the OPL soundfont I pulled off of https://musical-artifacts.com/artifacts/15.

I find it strange that the MIDI sounds "fine" in some setups. Is GM so badly standardized that what might be proper for some setups is not for others?

The SB16 is described as being GM compliant, so the sounds (instruments) should be OK, although the GM soundset can cover a wide range of differences depending on the exact implementation, i.e. some piano sounds are better than others, some string sounds are better, etc. I don't think that ANY two devices will sound exactly the same, even from the same manufacturer?

This is NOT any fault of the manufacturers.

On top of that, you have the way that the various aspects of the midi standards, for things like controllers, velocity, etc, are implemented. Yes, there IS a stamdard. The standard is fairly detailed, but it leave quite a lot of room for differences in implementation. So, increasing the volume by 10 on one setup may NOT be exactly the same change on another setup (if you had the equipment to measure this scientifically ).

And on top of this, when us humans get to play/create/manipulate the midi data, we usually find ways to take liberties with the midi spec. Prob call it 'being creative'. But the liberties you take on one setup should replicate on another VERY similar setup, but they should not be expected to replicate exactly on another setup, even though BOTH systems ARE compliant with the Midi Spec.

Then, add another level on top, when we get into the virtual systems, where in effect the computer is emulating the midi, but also emulating the hardware (in effect) and that emulation is not really part of the midi spec at all. Were virtual synths even possible when the midi spec was finalised?

The playback on my system sounds pretty good, I think, but I totally doubt it's EXACTLY like the original SB16 version

Looking at the history of WC2, specifically regarding the music, it seems that the original music MIGHT have been midi, but there also seem to have been mp3 variants (on the CD versions of the game ?). There is also reference to the music being 're-mastered'? At least once??

Is it possible that at some time a mp3 version has been converted back into midi? This is technically possible, but it IS somewhat problematic. If such a thing WAS done, then this could well explain some of the problems with the midi file you have. It might also explain your 'complaint' that the midi file is NOT sounding like it should (are you comparing the sound with the original game?).

The file came from the zip at the bottom of that list I posted ("51 MIDIs" ). In it you'll find WC2-45.MID, which approximates what the end of WC2-48.MID is supposed to sound like. As you can see, it goes on for well over a minute, which would fit neatly into the quiet part of WC2-48.MID at the end.

I don't know exactly where those mp3s came from, but they are either fan creations or something that the game company released separately from the game. I can promise you that the game did not ship w/mp3s (remember, it was around 1990. Floppy disks. Sometimes 5.25" ).

Can you do me the favour of uploading an mp3 of the rendering that you said sounds right? I'm curious to hear what it sounds like when it's good.

Did I say it sounded 'right'? That was stupid of me. I very much doubt even my best version sounded 'right' (I assume - in comparison to the original game).

You also say that none of the versions You've been able to play sound 'right' either. But you don't say what was wrong with them, maybe a lot of little things which might be expected that you're NOT using an original SB16 card.

I've done some further research and it would appear that Wing Commander was written to take advantage of the "older" version of the MT32.
This also explains why the MIDI file sounds odd played on a GM module/VST.
I found a list of the voices the MT32 supported and which MIDI program number they were invoked by.
The original document can be found by following the links on the MT32 page in Wikipedia.
The details can be found at the URL below.

Maybe you didn't use the word "right", but from the way you were talking, it sounded like you weren't hearing any of the problems I was. Anyone who heard what I've heard would know something was wrong, even if unfamiliar w/the original score.

I've listed a few ways in which I've experienced or heard of the failure on the various platforms, but the most up-to-date list is, at 3:55 to the end:

Cacophony, like multiple renderings of the same piece or left and right out of sync. (Improved w/the removal of the sustains, but not eliminated)

Scratchiness, like a fading AM radio station

Silence

A minute and a half of droning (eliminated by the removal of the sustains).

Sekaiju's playback was also unique, in that there was utter silence after 3:55, with the brief exception of these drums, which I'd never heard on other platforms.

I've still got my Roland LAPC-I card active on my old system. That is in effect a MT32. I'd not tried playing through that, as I'd interpreted early comments to relate the SB16 card to GM, and the GM playback seemed OK.

I'll get to try the playback of the original file via the Yamaha MU90r, and via the Roland card (as per MT32) and record both, and post the result.

I've just played the file both ways, using the LAPC-I card (MT-32 sound set) and to the Yamaha (GM).

Not really THAT much difference, but there ARE certainly differences.

I certainly could NOT say that one is clearly 'right' and one is clearly 'wrong', but then I've not heard the original version. As in, played from the actual game. I don't know that the version in the .MP3 is 'right' - is it?

I'll get the two versions saved as .MP3. Not done yet.

The sound quality (generally) from the Yamaha is clearly better, but then it ought to be, it's later technology. Some of the instruments are clearly the same, i.e. piano, but various other instruments are similar patch ## in both sound sets. Both versions hit a problem about 4:25 - the Roland card just goes to nothing, the Yamaha goes to a drone on Ch 2 & 3 until the end (5:26).

Hmm - for what it's worth, the Yamaha MU90r supports a C/M sound set, which is basically MT32. Never tried this. I suppose it'll be MT32 with the later level of sound quality. It's somewhat 'enhanced' over the normal MT32, as there's the standard MT soundset for Ch 1-9, and various extra sounds for Ch 11 to 16. I suppose there was never much point in my trying this as I have the 'Real Thing' readily to hand!!

Just tried the C/M version. It works. Not really sure how it compares to the other two versions. When I do the MP3s, I'll do all three versions?