fbpx


The MIDI Forum

  Saturday, 26 May 2018
  28 Replies
  13.9K Visits
0
Votes
Undo
  Subscribe
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.
3 years ago
·
#1681
0
Votes
Undo
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.
3 years ago
·
#1678
0
Votes
Undo
Thanks for the extra information.

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?

Looking forwards to getting some feedback from OP.

Geoff
3 years ago
·
#1677
0
Votes
Undo
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.
3 years ago
·
#1676
0
Votes
Undo
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.

Download: sekaiju-steps.zip
3 years ago
·
#1674
0
Votes
Undo
Next instalment...

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?

Geoff
3 years ago
·
#1673
0
Votes
Undo
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.

Geoff
3 years ago
·
#1672
0
Votes
Undo
Angus,

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'll play some more.

Geoff
3 years ago
·
#1671
0
Votes
Undo
Hello,

I've downloaded your file.

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?

Geoff
  • Page :
  • 1
  • 2
There are no replies made for this post yet.
Be one of the first to reply to this post!