Some times when exporting midi files, by playing them back from timidity I get the message
take2.mid: Illigal Variable-length quantity format.
Although timidity plays such files without problem, in analysing them from other sources (e.g. Python) the tracks can’t be handled because they are “corrupted” as my program reports.
Does any one know what Illigal Variable-length quantity format means and how should I avoid it?
Many thanks
Amir
Probably best would be to post a MIDI file which generates that error so someone else can try to analyze where the problem exists in the file. The error message is too vague to guess which quantity is noted as incorrect.
Sorry for long not answering! I have attached a midi file to this repository, which seems to be faulty!
When I play back this file with timidity Take17_General\ MIDI\ Synth-1.3.mid I get
Playing Take17_General MIDI Synth-1.3.mid
MIDI file: Take17_General MIDI Synth-1.3.mid
Format: 0 Tracks: 1 Divisions: 19200
Take17_General MIDI Synth-1.3.mid: Illigal Variable-length quantity format.
Playing time: ~6 seconds
Notes cut: 0
Notes lost totally: 0
I would very much like to know what this Illigal Variable-length quantity format. is appearing. This leads to problems, for instance when analyzing the file with a programming-lang. For instance trying to read the midi file with Python (pretty_midi.PrettyMIDI(midipath)) a Value Error like this appears:
ValueError: MIDI file has a largest tick of 144115188075998575, it is likely corrupt
I suspect Timidity cannot deal with our MIDI files. You should likely export it instead, to avoid Ardour-specific (but 100% legal) stuff is not included in the file.
Thank you for your reply! I have exported the the file from Ardour, by right clicking on the MIDI region and choosing Export... option. Or did you mean something different with export? How could I avoid Ardour-specific stuff and get a legal midi export?
This is what mf2txt (MIDI file to text converter) shows as the contents of the example file. Does this look basically correct?
MFile 0 1 19200
MTrk
0 SeqSpec 99 01 ea 5b
6530 On ch=1 n=68 v=123
6530 SeqSpec 99 01 ea 5c
9010 On ch=1 n=72 v=104
9010 SeqSpec 99 01 ea 5d
10390 Off ch=1 n=68 v=64
10390 SeqSpec 99 01 ea 5e
13140 Off ch=1 n=72 v=64
13140 SeqSpec 99 01 ea 5f
21960 On ch=1 n=78 v=120
21960 SeqSpec 99 01 ea 60
24990 On ch=1 n=74 v=107
24990 SeqSpec 99 01 ea 61
26100 Off ch=1 n=78 v=64
26100 SeqSpec 99 01 ea 62
27780 Off ch=1 n=74 v=64
27780 SeqSpec 99 01 ea 63
36300 On ch=1 n=64 v=102
36300 SeqSpec 99 01 ea 64
40160 Off ch=1 n=64 v=64
40160 SeqSpec 99 01 ea 65
51180 On ch=1 n=76 v=93
51180 SeqSpec 99 01 ea 66
54490 Off ch=1 n=76 v=64
54490 SeqSpec 99 01 ea 67
70740 On ch=1 n=68 v=70
70740 SeqSpec 99 01 ea 68
74600 On ch=1 n=72 v=103
74600 SeqSpec 99 01 ea 69
75150 Off ch=1 n=68 v=64
75150 SeqSpec 99 01 ea 6a
77080 On ch=1 n=80 v=95
77080 SeqSpec 99 01 ea 6b
77630 Off ch=1 n=72 v=64
77630 SeqSpec 99 01 ea 6c
80110 On ch=1 n=82 v=107
80110 SeqSpec 99 01 ea 6d
81220 Off ch=1 n=80 v=64
81220 SeqSpec 99 01 ea 6e
83420 Off ch=1 n=82 v=64
144115188075935068 Meta TrkEnd
TrkEnd
I do see a suspiciously large value like you pointed out before, in this case 144115188075935068.
@paul is the 19200 at the beginning of the file a correct representation of 19200 ticks per quarter note? I’m kind of skimming the SMF spec I found as I go, that seems like the right field for tick quantization. It seems really high, but Ardour has that supermega clock or whatever is used as the underlying quantum to join music and audio time, so I guess could be right.
Is that final value the delta time stamp at track end time? Because even at 19200 ticks per quarter that is something like 62 billion minutes at 120bpm. Doesn’t seem reasonable.
This is the raw file data for anyone interested:
00000000: 4d54 6864 0000 0006 0000 0001 4b00 4d54 MThd........K.MT
00000010: 726b 0000 0110 00ff 7f04 9901 ea5b b302 rk...........[..
00000020: 9044 7b00 ff7f 0499 01ea 5c93 3090 4868 .D{.......\.0.Hh
00000030: 00ff 7f04 9901 ea5d 8a64 8044 4000 ff7f .......].d.D@...
00000040: 0499 01ea 5e95 3e80 4840 00ff 7f04 9901 ....^.>.H@......
00000050: ea5f c474 904e 7800 ff7f 0499 01ea 6097 ._.t.Nx.......`.
00000060: 5690 4a6b 00ff 7f04 9901 ea61 8856 804e V.Jk.......a.V.N
00000070: 4000 ff7f 0499 01ea 628d 1080 4a40 00ff @.......b...J@..
00000080: 7f04 9901 ea63 c248 9040 6600 ff7f 0499 .....c.H.@f.....
00000090: 01ea 649e 1480 4040 00ff 7f04 9901 ea65 ..d...@@.......e
000000a0: d60c 904c 5d00 ff7f 0499 01ea 6699 6e80 ...L].......f.n.
000000b0: 4c40 00ff 7f04 9901 ea67 fe7a 9044 4600 L@.......g.z.DF.
000000c0: ff7f 0499 01ea 689e 1490 4867 00ff 7f04 ......h...Hg....
000000d0: 9901 ea69 8426 8044 4000 ff7f 0499 01ea ...i.&.D@.......
000000e0: 6a8f 0a90 505f 00ff 7f04 9901 ea6b 8426 j...P_.......k.&
000000f0: 8048 4000 ff7f 0499 01ea 6c93 3090 526b .H@.......l.0.Rk
00000100: 00ff 7f04 9901 ea6d 8856 8050 4000 ff7f .......m.V.P@...
00000110: 0499 01ea 6e91 1880 5240 81ff ffff ffff ....n...R@......
00000120: ffdf 00ff 2f00