Trying to determine what is causing a specific MIDI file to misbehave in my program (type 0).
I ran it through test-midi-files before and after I modified it.
The before file has a ton of errors as such:
After modifying, it also now has some of these:
So, just curious, are all midi CC values restricted to 0-127 unless it has a CC MSB and LSB?
I'm having a hard time tracking down exactly where these errors are in an event viewer. Sekaiju does not list any tick or byte offsets.
I have another program simply called MIDIEE (MIDI Event Editor) which will not open the file and gives the error
"Event with a parameter >= 128"
I can go to the locations in a hex editor, and see, for example, the first one is "00 80 FF 14" which is a note off on a non-existent instrument.
[UPDATE BEFORE I EVEN FINISHED POSTING]
Well, update, I'll post this anyway for the CC value question, but the problem is the program that generated this MIDI file has some flaws, and every one of those bad MIDI values is the same "80 FF 14" in tons of spots throughout the file. Because it is a note off event, my program never touches it unless it is on a percussion channel. Therefore, I will continue to test out other files, and chalk these issues up to a bad test file. If I run this file through Anvil Studio's "repair" option, it converts it to a type 1 file and fixes it, and there are no errors afterwards.
I ran it through test-midi-files before and after I modified it.
The before file has a ton of errors as such:
WARNING: offset 88 track 1 tick 0 -- Bad MIDI value (255)
WARNING: offset 4049 track 1 tick 1915 -- Bad MIDI value (255)
WARNING: offset 4185 track 1 tick 1935 -- Bad MIDI value (255)
...
After modifying, it also now has some of these:
WARNING: offset 71602 track 1 tick 3753082 -- Long VLQ value (128/255/20)
WARNING: offset 71607 track 1 tick 3753082 -- Bad MIDI value (129)
WARNING: offset 72126 track 1 tick 4577392 -- Long VLQ value (128/255/20)
WARNING: offset 72131 track 1 tick 4577392 -- Bad MIDI value (153)
...
WARNING: offset 249287 track 1 tick 295710527 -- Incomplete track data (1)
So, just curious, are all midi CC values restricted to 0-127 unless it has a CC MSB and LSB?
I'm having a hard time tracking down exactly where these errors are in an event viewer. Sekaiju does not list any tick or byte offsets.
I have another program simply called MIDIEE (MIDI Event Editor) which will not open the file and gives the error
"Event with a parameter >= 128"
I can go to the locations in a hex editor, and see, for example, the first one is "00 80 FF 14" which is a note off on a non-existent instrument.
[UPDATE BEFORE I EVEN FINISHED POSTING]
Well, update, I'll post this anyway for the CC value question, but the problem is the program that generated this MIDI file has some flaws, and every one of those bad MIDI values is the same "80 FF 14" in tons of spots throughout the file. Because it is a note off event, my program never touches it unless it is on a percussion channel. Therefore, I will continue to test out other files, and chalk these issues up to a bad test file. If I run this file through Anvil Studio's "repair" option, it converts it to a type 1 file and fixes it, and there are no errors afterwards.
For MIDI events (events that get sent out as MIDI messages on a MIDI port), the status byte must be decimal 128 to 255, and the data bytes must be decimal 0 to 127.
It is possible for meta events to have data bytes of any value (decimal 0 to 255).
If the MIDI file is missing a byte somewhere (or has an extra byte somewhere), then the test program could be interpreting things as data bytes that were originally supposed to be something else, and interpreting things as variable-length quantities (i.e. delta times, sysex length values, or meta event length values) that were originally supposed to be something else.
Try focusing on the first error message. If you find a problem there that you can fix, that might cause all the other errors after it to clear up too.
It is possible for meta events to have data bytes of any value (decimal 0 to 255).
If the MIDI file is missing a byte somewhere (or has an extra byte somewhere), then the test program could be interpreting things as data bytes that were originally supposed to be something else, and interpreting things as variable-length quantities (i.e. delta times, sysex length values, or meta event length values) that were originally supposed to be something else.
Try focusing on the first error message. If you find a problem there that you can fix, that might cause all the other errors after it to clear up too.
For MIDI events (events that get sent out as MIDI messages on a MIDI port), the status byte must be decimal 128 to 255, and the data bytes must be decimal 0 to 127.
It is possible for meta events to have data bytes of any value (decimal 0 to 255).
If the MIDI file is missing a byte somewhere (or has an extra byte somewhere), then the test program could be interpreting things as data bytes that were originally supposed to be something else, and interpreting things as variable-length quantities (i.e. delta times, sysex length values, or meta event length values) that were originally supposed to be something else.
Try focusing on the first error message. If you find a problem there that you can fix, that might cause all the other errors after it to clear up too.
It is possible for meta events to have data bytes of any value (decimal 0 to 255).
If the MIDI file is missing a byte somewhere (or has an extra byte somewhere), then the test program could be interpreting things as data bytes that were originally supposed to be something else, and interpreting things as variable-length quantities (i.e. delta times, sysex length values, or meta event length values) that were originally supposed to be something else.
Try focusing on the first error message. If you find a problem there that you can fix, that might cause all the other errors after it to clear up too.
If the MIDI file is missing a byte somewhere (or has an extra byte somewhere), then the test program could be interpreting things as data bytes that were originally supposed to be something else, and interpreting things as variable-length quantities (i.e. delta times, sysex length values, or meta event length values) that were originally supposed to be something else.
This is basically the problem. I've narrowed it down to happening when I insert a new Bank Select MSB and/or LSB. I have them both in one function, and my pointers are getting misaligned somehow, so every once in a while, the bytes are being written shifted either back or forward from where they are supposed to be, which messes things up until the end of the track. It only happens with certain files, including this one (and actually so far, only this one, but I've only tested a small amount since my latest code changes).
I am pondering adding in a "valid range" check to compensate for invalid values when I scan in a file.
Well, seems I may have found the actual (first) issue in the file, but still can't easily figure out why it happened. The Bank Select appears to be 12 bytes too early from where it should be. Too many "B0"s!
The offending section:
00 B0 07 50
00 B0 B0 00 00 00 27 27 00 BO 0A 40 86 40 C0 2F 00
Before the edit, it was
00 B0 07 50
00 B0 27 27 00 BO 0A 40 86 40 C0 2F 00
The bytes added when I insert the bank select should presumably be
B0 00 00 00
as I keep the delta time prior to the new bank select, and add the new delta time after it. It should be just before the program change, and for some reason it is off by 12 bytes (or 8 prior to the insertion).
The offending section:
00 B0 07 50
00 B0 B0 00 00 00 27 27 00 BO 0A 40 86 40 C0 2F 00
Before the edit, it was
00 B0 07 50
00 B0 27 27 00 BO 0A 40 86 40 C0 2F 00
The bytes added when I insert the bank select should presumably be
B0 00 00 00
as I keep the delta time prior to the new bank select, and add the new delta time after it. It should be just before the program change, and for some reason it is off by 12 bytes (or 8 prior to the insertion).
Huzzah! I noticed a pattern. It was happening anywhere there was a track that contained multiple instruments that were intermixed. Single instrument tracks were not a problem.
I originally inserted the bank selects per instrument, and did the position updating after looping through all the instruments. This was sometimes checking the insert position against an incorrect value.
I changed it to do the insert and update both at the same time with each instrument loop. In this particular case (this stubborn test file :P ) it is all now working exactly as I intended.
I originally inserted the bank selects per instrument, and did the position updating after looping through all the instruments. This was sometimes checking the insert position against an incorrect value.
I changed it to do the insert and update both at the same time with each instrument loop. In this particular case (this stubborn test file :P ) it is all now working exactly as I intended.
- Page :
- 1
There are no replies made for this post yet.
