Structure & metadata of midi files

[Malcohol]

Hi there.

I'm working on a project (SeqWires) which, among other things, can load Standard MIDI Files. I was amazed to find that there was no official midi test suite, so your project plugs a really important hole. Right now, I'm planning on using your test suite to test my MIDI handling. Thanks so much for this project!

For my particular use-case, there are feature I'd like to suggest:

1. Put valid and invalid MIDI files in separate folders.
2. Put metadata in a JSON (or whatever) file beside each .mid file, with some high-level information such as track duration, number of events, etc.

These would make it easier for dependent projects to exploit the test data without having hard-coded knowledge of the specific files.

Some other miscellaneous ideas:
3. Write a file with Yamaha XF Chord events

Thanks again,

Malcolm

[jazz-soft]

Hi Malcolm, thank you for sharing!

1. Not sure that is the right thing to do since we have the whole range of "invalidities" from "almost valid" to "completely broken".
2. This sounds like a good idea! Any suggestions on what should be a content of these JSON files?
3. I'm planning to add some karaoke files in different formats in the future. These will include some XF Chords as well.

[Malcohol]

1. Makes sense.

2. With respect to the JSON files, I was thinking of high-level features that might be common to almost every MIDI parser and almost every MIDI files. Here are some sketches (based on a possibly rusty memory of what's in a MIDI file):

{
  "valid": true,
  "format": 0,
  "numEvents": 52,
  "channels": [1, 2, 3, 5],
  "duration": 32
}

{
  "valid": true,
  "format": 1,
  "tracks": [
    {
      "numEvents": 52,
      "channels": [1],
      "duration": 32
    },
    {
      "numEvents": 80,
      "channels": [2],
      "duration": 32
    }
  ]
}

{
  "valid": false
}

The motivation is to allow the full body of test files to be used without writing specific tests for each. MIDI parsing software would expect to load all the files without internal errors, and in all the valid cases, match the given metadata. (By "valid" I mean the events and tracks are sufficiently well-formed to read tracks, events, channels etc. There's probably a better name.)

Such a "high-level" test does not preclude writing individual tests which load specific files and test for specific features. I'm doing some of the latter anyway, so I can make use of the testsuite regardless of whether this proposal (or something like it) gets implemented.

3. That'll be great. Thanks!

Malcolm

[jazz-soft]

2. This looks like the information that can be directly retrieved from the MIDI file with a script as simple as the one parsing JSON.
   I guess I need to think more about it...

[Malcohol]

As I've proceeded to write midi handling tests for my code, I now think #2 is unnecessary.

I have some tests which load specific files and and check for details. In addition, I exploit the breadth of coverage in the test suite with a test which loads every file and checks that my code either loads successfully, or throws a parse exception (so no crashes or unexpected exceptions).

I feel this approach gives sufficient confidence in the midi file handling without the additional metadata.

Thanks for taking the time to consider it though!