Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIDI File parse bug. #177

Open
2 tasks done
SinanKarasu opened this issue Mar 15, 2023 · 4 comments
Open
2 tasks done

MIDI File parse bug. #177

SinanKarasu opened this issue Mar 15, 2023 · 4 comments
Assignees
Labels
🎩 refinement An enhancement to an existing feature 🎹 smf MIDIKit SMF (Standard MIDI File)

Comments

@SinanKarasu
Copy link
Sponsor

Please Confirm

  • I have reviewed the MIDIKit Documentation which contains descriptive guides and extensive API reference
  • I have searched Issues and Discussions to see if the same question has already been asked

macOS Version(s) Used to Build

macOS 13 Ventura

Xcode Version(s)

Xcode 14

Description

The following file does not parse. The same file parses in two other MIDI Parsers, Logic Pro, and plays in AVAudioSequencer.
Anonim - Uzun Ince Bir Yoldayim.mid.zip

Crash Logs, Screenshots or Other Attachments (if applicable)

No response

@orchetect
Copy link
Owner

orchetect commented Mar 15, 2023

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.

@orchetect orchetect added the 🎩 refinement An enhancement to an existing feature label Mar 15, 2023
@orchetect orchetect self-assigned this Mar 15, 2023
@SinanKarasu
Copy link
Sponsor Author

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?

@SinanKarasu
Copy link
Sponsor Author

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

@orchetect
Copy link
Owner

orchetect commented Mar 15, 2023

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.

@orchetect orchetect pinned this issue Mar 16, 2023
@orchetect orchetect added the 🎹 smf MIDIKit SMF (Standard MIDI File) label May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🎩 refinement An enhancement to an existing feature 🎹 smf MIDIKit SMF (Standard MIDI File)
Projects
None yet
Development

No branches or pull requests

2 participants