Interesting Test Files from the "midicvt" Project
Chris Ahlstrom
2015-11-16 to 2015-11-25

While loading the test MIDI files from our "midicvt" project into Sequencer64,
we found some interesting cases.

   b4uacuse-non-mtrk.midi:
   
      This file has a "MUnk" tag marking the proprietary data track.
      Sequencer64 correctly bypasses this chunk, but perhaps there is a way to
      persist a little more to see if the rest of the chunk is well-formed
      enough to load.

    b4uacuse-GM-alternate-bad.midi:

      This version of our main test MIDI file was written incorrectly by
      an earlier version of Sequencer64, so it is a good test file.
      If Sequencer64 is run from the console, one will see a message
      about this, and a plea to re-save the file.

   choo2xg.mid:

      This file yields "? no support for SYSEX messages, skipping...", and
      loads 31 tracks, 15 of them being empty title tracks.

   CountryStrum.mid:

      This file yields a load error and a warning:

      ? no support for SYSEX messages, skipping...
      unsupported MIDI format detected: 0

      Sequencer64 imports it and splits it, but, interestingly, it starts
      with a sequence number of 8.

   dixie03.mid:

      ? no support for SYSEX messages, skipping...
      unsupported MIDI format detected: 0

      Sequencer64 loads this file; it loads with sequence numbers of
      0 to 2, 8 to 15, and, of course, the original track stored as
      sequence 16.

   Dixie04.mid:

      This file has a PPQN of 960.  Also, it is resistant to the --bus 5
      option!!!!!

      ? no support for SYSEX messages, skipping...
      unsupported MIDI format detected: 0
      unsupported MIDI format detected: 0
      ? no support for SYSEX messages, skipping...
      ? no support for SYSEX messages, skipping...
      ? no support for SYSEX messages, skipping...
         .  .  .
      ? no support for SYSEX messages, skipping...
      unsupported MIDI chunk, skipping: 35000000
      Segmentation fault

      Oh goody, a potential bug to fix!!!!

      Well, first thing, we add better error reporting to the midifile and
      mainwnd modules.  Then we add a test against the MIDI file size so that
      we do not try to get data past that file size.  Once the data counter is
      too big, we disable using it.

      This leads to about 8 of the following message:

      ? Buffer overflow reading MIDI data, further reading disabled

      Followed by "Unsupported MIDI chunk, skipping:        0",
      and four more of the buffer-overflow messages... and then...
      the file is loaded!

      There are a lot of "00 F0 7F" fragments, which looks like some
      incomplete SysEx, probably sent from a crappy synthesizer.  So
      now we check for bytes from 7D to 7F after an F0, and ignore
      that fragment.

      Some of the tracks have really short notes, like 1/64th notes or
      less!  The file ends, according to midicvt, with 11 Sysex messages.
      Yet we get a "no support" message for every byte in every Sysex
      message, it seems.

      This file contains some weird SysEx messages.  We go into detail about
      this file and its weird SysEx in the midicvt project.

     example1.mid:

        An SMF 0 file.  See example1.asc for more detailed discussion of
        this very useful, small, test file.

     mrroboto_with_lyrics.mid:

        An SMF 0 file with lyrics, it is a good test of the track-split
        feature and the handling (skipping) of lyrics tracks.

    wpb_yoshimi-buss-0.midi:

        A file we wrote using Cakewalk for Windows, and imported into
        seq24.  Currently a Yoshimi killer (makes it seqfault on playback
        from Sequencer64).

    Brand3.mid:

        This relatively large MIDI file of the third Brandenberg concerto
        really shows how much faster the std::map code loads over the
        std::list code.  Just an instant for the map, and about 8 seconds
        for the list!

        Currently also a Yoshimi killer.

# vim: sw=4 ts=4 wm=8 et ft=sh
