jacobtylerwalls
commented
3 years ago heya @laurentVeliscek, thanks for the report.
There are MIDI messages in your file I don't understand. The following is from the second track of music:
>>> mf = midi.MidiFile()
>>> mf.open('../Desktop/test.mid')
>>> mf.read()
>>> mf.close()
>>> mf.tracks[2].events[:8]
[<MidiEvent DeltaTime, t=0, track=2, channel=None>, <MidiEvent SEQUENCE_TRACK_NAME, t=0, track=2, channel=None, data=b'goldberg.mid'>,
<MidiEvent DeltaTime, t=20, track=2, channel=None>, <MidiEvent NOTE_ON, t=0, track=2, channel=2, pitch=71, velocity=124>,
<MidiEvent DeltaTime, t=12, track=2, channel=None>, <MidiEvent CONTROLLER_CHANGE, t=0, track=2, channel=2, parameter1=7, parameter2=107>,
<MidiEvent DeltaTime, t=468, track=2, channel=None>, <MidiEvent NOTE_ON, t=0, track=2, channel=2, pitch=71, velocity=0>]The pair of events in the second row looks fishy: I don't think music21 is interpreting that correctly. Here's the binary:
>>> mf.tracks[2].data
b'\x00\xff\x03\x0cgoldberg.mid\x14\x91G|\x0c\xb1\x07k\x83T\x91G\x00\x00L|$Jk\x10L\x00,Le\x0cJ ...The 0x14 after the goldberg.mid I don't understand, and neither does music21 -- music21 gives up and converts 0x14 to an integer to get a value of 20, which becomes your DeltaTime of 20 ticks, which turns out to be a 1/96th rest. Here are your timepoints even after turning quantization off (see the mailing list for some posts on this recently):
>>> s = converter.parse('../Desktop/test.mid', quantizePost=False, forceSource=True)
>>> s.parts[1].makeNotation(inPlace=True)
>>> s.parts[1].measure(1).show('text')
{0.0} <music21.clef.TrebleClef>
{0.0} <music21.meter.TimeSignature 3/4>
{0.0} <music21.stream.Voice 0>
{0.0} <music21.note.Rest rest>
{0.0417} <music21.note.Note B>
{1.1167} <music21.note.Note D>
{2.55} <music21.note.Note D>
{0.0} <music21.stream.Voice 1>
{1.0417} <music21.note.Note E>
{1.2417} <music21.note.Note E>
{2.775} <music21.note.Note C>So the B that should start at 0.0 actually starts at 0.0417. That 20-tick 1/96th rest is what's hosing the rest of your score.
The 0x14 has to be signifying something else, but I have no idea. After some poking around this is my hypothesis: -- 0x14 is used in the WAV file format to declare the MIDI unity note for playback on a MIDI sampler -- 0x14 in MIDI is used to specify cues or loop markers, which music21 doesn't support -- a MIDI writer got confused and wrote the MIDI unity note it parsed from a WAV file into the MIDI output -- music21 got confused on account of its lack of support for cue or loop markers and just converted into the fishy events as above, giving you a 1/96th rest.
Notice \x91G| in \x14\x91G|could be a MIDI unity note, since it's exactly that first B4 in the track (x9: note_on prefix, 1G: pitch value (71), |: velocity value (124):
<MidiEvent DeltaTime, t=20, track=2, channel=None>, <MidiEvent NOTE_ON, t=0, track=2, channel=2, pitch=71, velocity=124>When I load the MIDI into GarageBand, I see ticks very early in the tracks, suggesting markers of some kind, which is bonkers, but at least follows the MIDI spec.
Finally, may I ask -- where did this file come from? If MuseScore is writing it, we can report it to them, and look into a workaround on this end, but if it's less common than that I doubt we can do much. At the very least, you can possibly get rid of these microscopic rests and try building a new stream from everything else. good luck!
laurentVeliscek
music21 version
6.1.0Problem summary
Something seems to be broken when importing multi-part midifiles
When I try to show() the imported score, I always get warnings about meter (?):
Then, I get a MuseScore error message "the xxx.xml file is not a valid MusicXML file". (here, the error message is in french, but that's the idea...)
If I try to open the file in museScore, it crashes, or if I'm lucky, I can display something, but the score seems to be corrupted.
Steps to reproduce
Expected vs. actual behavior
I wish I could import and manipulate the score transparently.
More information
Mac OS Mojave, python 3.7, all modules freshly installed and updated
I tried using many midifiles downloaded from different locations, I tried loading and saving with museScore, but the same results.
In fact, I couldn't find any multi-part midifile that can be imported and showed properly.
To illustrate this, I join 2 screen copies of the file before and after import, using museScore , so you can compare (notes timing are just messed up...)
I attached the test.mid file (zipped).
Did I miss something ?
Thanks !
test.mid.zip