MIDI File parse bug. about midikit HOT 4 OPEN

Thanks for the bug report. I've looked into this and the file is being successfully parsed, but there are two trailing bytes at the end of the file: 0x0D 0x0A. Because these bytes are unexpected, the file is technically considered malformed, even though these bytes are of no apparent consequence.

Thus far I cannot find any reason for them being there. There is nothing in the SMF spec that mentions what they would be for. It's possible to ignore them but I'd rather get to the bottom of why they might be there in the first place if possible before resorting to that.

from midikit.

Appears they are the \r\n characters. Maybe someone edited the file with a hex editor on windows, and when saved it added carriage return line feed?

from midikit.

I have developed parsers using Antlr, and this was always a problem between Windows and Unix. Here is one from IBM.
https://www.ibm.com/support/pages/additional-carriage-return-and-line-feed-added-during-sterling-connectdirect-file-transfer

from midikit.

Yeah it's a Windows CRLF byte pair. Really odd. But if someone attempted editing the file in a text editor then maybe that explains it. Some of the MIDI files out in the wild have survived decades and who knows what happened along the way.

On a related note: I sourced a zip file of about 30,000 crowd-sourced MIDI files from the web and ran all of them through a test harness that had MIDIFile parse them to catch any misfits. It returned a number of results so I'm going to go through those soon and see if the parser can be made more resilient to malformed or unexpected files.

from midikit.