I'm trying to parse MIDI files, but my parser can't parse most MIDI files from the internet because its keeps stumbling on command bytes not specified in the SMF specifications. MIDI files exported with FL Studio work fine, but pretty much every other MIDI seems to break.
For example, from this midi file:
00 B0 20 02 | 00 00 00 | 00 C0 00
The first part is easy to parse. It's a Control Change according to MIDI specifications. But the second part makes no sense. After 0 ticks, do what exactly? How many bytes can I expect after that? 0x00 isn't specified as a command in SMF. Nevertheless, the part right after that is recognizable, so you can see the second part has 1 data byte.
However, if I just work around the previous problem, later on it becomes a true mess:
00 C0 00 | 00 B0 07 6E | 00 0A 40 00 5B 46 00 5D 00 00 5E 19 86 70 90 41 6E 00 45 6E 48 45 00 00 41 00 00 43 6E 48 43 00 00 48 6E 60 48 00 00 3C 6E 00 35 6E 30 35 00 [etc]
Okay, so let's see. Patch Change, check. Controller Change, check. 0A? What the hell does 0A do? Trying to recognize any commands after the 0A part doesn't work either, it's all one big mess and I have no idea what belongs to that 0A command or when the next actual SMF command starts. I simply have no idea how to parse the rest of the track after this mess.
Yet, programs like Winamp and FL Studio can open those MIDI files just fine. How do they do it? How do I know when junk data ends and proper commands start?
That's not junk data. That's running status. If, after processing a command, the next byte is less than $80, you assume the same status byte as the previous command. Here's a description of running status.