Hello all. I'm currently writing software to read midi files and I've having troubles. For starters, after the chunk header signifier MTrk, there's 4 bytes that specifies the size of the chunk, which I'm lead to believe doesn't include itself or the header signifier. However, in every single MIDI file that I've put in my hex editor, there's always a group of 0 bytes right after, sometimes just one. Are those bytes also included in the size? If so, then what do you do with them? If it's not a VLQ value for Midi event timing, nor the beginning of a Meta event, Should they be discarded? Are they just padding? Also, things like Meta events make playback difficult. If any of you have experience in designing MIDI players, is there a good way to scan ahead for meta events so they can be loaded before the song plays, like text, lyrics, and instrument assignment?
Pseudonymous
set the type of the post as
Admin Post — 4 months ago
Clemens Ladisch
set the type of the post as
Technical Question — 4 months ago
0
Undo
Votes
There are no padding bytes. Many (meta) events at the beginning of a track have a zero delta time.
Please show an example hex dump.
They only way to find events is to parse all events.
Please show an example hex dump.
They only way to find events is to parse all events.
in every single MIDI file that I've put in my hex editor, there's always a group of 0 bytes right after [the MTrk and size], sometimes just one.
After the "MTrk" bytes and the four bytes that indicate the size, if the next byte has a value of zero, then that is the variable-length quantity delta time for the first event. In other words, the first event in the track is at tick zero. It is very common for a track to begin with an event at tick zero.
If the next byte after that is also a value of zero, then that would be an error. The first event in a track must have a "status" byte (a value of hex 80 to EF, F0, F7, or FF).
As Clemens Ladisch suggested, it might be helpful to discuss an example hex dump you are looking at.
Here is what I see in your example:
In the diagram above, the number of bytes in each row's "chunk contents" matches the "size" value of the row.
In this file, every MTrk chunk has contents after the size that begin with a single 00 byte, never multiple 00 bytes. Those single 00 bytes are the variable-length quantity delta time of the first event in each track -- in this file, each track's first event is at tick zero.
(* Also note: The file ends with a stray 0A byte that shouldn't be there. Perhaps the file was written by some programming language's print command in text mode instead of binary mode. Or something like a writeln command when a write command should have been used.)
chunk type size chunk contents
----------- ----------- --------------
4D 54 68 64 00 00 00 06 ...
4D 54 72 6B 00 00 00 5E 00 FF ...
4D 54 72 6B 00 00 14 AD 00 FF ...
4D 54 72 6B 00 00 00 A9 00 FF ...
4D 54 72 6B 00 00 0F 27 00 FF ...
4D 54 72 6B 00 00 0D DF 00 FF ...
4D 54 72 6B 00 00 A8 2F 00 FF ...
4D 54 72 6B 00 00 01 4B 00 FF ...
0A*In the diagram above, the number of bytes in each row's "chunk contents" matches the "size" value of the row.
In this file, every MTrk chunk has contents after the size that begin with a single 00 byte, never multiple 00 bytes. Those single 00 bytes are the variable-length quantity delta time of the first event in each track -- in this file, each track's first event is at tick zero.
(* Also note: The file ends with a stray 0A byte that shouldn't be there. Perhaps the file was written by some programming language's print command in text mode instead of binary mode. Or something like a writeln command when a write command should have been used.)
- Page :
- 1
There are no replies made for this post yet.