Notifications
Clear all
Topic starter
Please note that I may be wrong, but I'd like a sanity check to make sure I'm right. The variable-length quantity method of storing numbers in MIDI files is very unusual and takes up more space than necessary...what were they thinking?
The example time signature of 500,000 µsec per quarter-note used in the example in the file format document of GM1 RP-001_v1-0_Standard_MIDI_Files_Specification_96-1-4.pdf has an 8-bit per byte hex value of "07 A1 20". However, the example indicates that the variable-length quantity is "07 A1 20" and when I do the math with high bit of all except the last byte set I get "9E C2 20" I just want to double check that the document has it wrong. I spent several hours playing with the sample code as well as several versions of my own code and comparing the example conversions before realizing that the document has must have a mistake. Using the defined "variable-length quantity" specification to store the Tempo is very unusual. It would be nice if someone would at least provide a notice that the example is wrong...if that's the case. Or perhaps a more intuitive code sample than the "clever" way the specification document does it.
Posted : 12/12/2021 3:19 am
In the format of a Meta Event -- FF -- only the length value is a variable-length quantity. The data can use all 8 bits of each byte.
In a Tempo Meta Event -- FF 51 03 tt tt tt -- only the single byte "03" is a variable-length quantity, representing 3 data bytes follow. The tempo data itself is always 3 bytes in length and does not use variable-length quantity encoding. In the example Tempo Meta Event "FF 51 03 07 A1 20", hex 7A120 is decimal 500,000 microseconds per quarter note (120 quarter notes per minute).
Related post: Re: Which items can be variable length? in a MIDI file.
Posted : 12/12/2021 4:11 am
[quotePost id=12661]Please note that I may be wrong, but I'd like a sanity check to make sure I'm right. The variable-length quantity method of storing numbers in MIDI files is very unusual and takes up more space than necessary...what were they thinking?[/quotePost]
Rest assured, you are wrong. 😀
You appear to be confusing the length of the payload with the payload itself. Read the spec more closely or look at what @Bavi_H posted. Every meta event has a length value that tells you how many bytes the payload consists of. Knowing the format of meta events means you don't have to know what a meta event is to be able to successfully read it. You process events that are important to your application and ignore events that are not.
What they were thinking is that the length value takes up the minimum number of bytes necessary to indicate the payload length, which very successfully saves space.
Posted : 12/12/2021 8:21 am
Topic starter
[quotePost id=12664]Rest assured, you are wrong. :D[/quotePost]
I got that...thanks. I felt like I was going blind after reading the spec.
[quotePost id=12664]What they were thinking is that the length value takes up the minimum number of bytes necessary to indicate the payload length, which very successfully saves space.[/quotePost]
The hex value of 16384 is 4000 and if stored as is only requires 2 bytes: 40 00. The variable-length quantity storage method requires 3 bytes as: 81 80 00. It's provided
in that file spec as an example. That's what I'm talking about...limiting only 7 bits per byte for each part of the number. It's a moot point anyway because it's been done and widely distributed for decades.
Posted : 12/12/2021 10:00 pm
