The division value of 480 ticks per quarter note if fairly high, and the resultant size of the tick numbers in the file, may cause some systems a problem. What data type is your software using for delta time, might you have some overflow?
MIDI time code (MTC) embeds the same timing information as standard SMPTE timecode as a series of small 'quarter-frame' MIDI messages. There is no provision for the user bits in the standard MIDI time code messages, and SysEx messages are used to carry this information instead. The quarter-frame messages are transmitted in a sequence of eight messages, thus a complete timecode value is specified every two frames. If the MIDI data stream is running close to capacity, the MTC data may arrive a little behind schedule which has the effect of introducing a small amount of jitter. In order to avoid this it is ideal to use a completely separate MIDI port for MTC data. Larger full-frame messages, which encapsulate a frame worth of timecode in a single message, are used to locate to a time while timecode is not running.
Does delta time still process the same way mathematically if the file uses SMPTE?
The division value of 480 ticks per quarter note [is] fairly high
Perhaps the problem is that the hour value in the SMPTE offset metaevent is more than 24.
Correction: 96 in not an hour. First SMPTE byte is the SMPTE type, valid values are 24, 25, 29, 30
FF 54 05 hr mn se fr ff
[...] The hour must be encoded with the SMPTE format, just as it is in MIDI Time Code.
[...] The ff field contains fractional frames, in 100ths of a frame, even in SMPTE based tracks which specify a different frame subdivision for delta-times.
HOURS COUNT: x yy zzzzz
x Undefined and reserved for future use. Transmitter must set this bit to 0 and receiver should ignore!
yy Time Code Type:
0 = 24 Frames/Second
1 = 25 Frames/Second
2 = 30 Frames/Second (Drop-Frame)
3 = 30 Frames/Second (Non-Drop)
zzzzz Hours Count (0-23)
Geoff, be aware that the [DECODE] program you use to convert MIDI files to text seems to have the following issues: [...] 3. When it displays an SMPTE Offset meta event, it is incorrectly displaying the entire first byte as an hours value ("33 hours") instead of correctly interpreting the high bits as indicating the time code type (time code type is 25 frames per second and hour value is 1 hour).
As for the SMPTE, when did the spec change to allow for the use of the hight bits in the '[hour]' value for 'time code type'. Was this parameter active when the software was written in 1991/2.
Hm, I don't know. I don't use SMPTE time myself, but when I noticed the SMPTE Offset hour value in a sequencer I use [Sekaiju] was different than the hour value in text file you made, I peeked in the specs to see what could be going on.
Geoff: nice catch!
a fixed version is online.
Attaching a test file with a 1 minute SMPTE offset. MS Media Player ignores it.
I believe 99.99% of other players will ignore it too.
Try your program with the other test files at https://github.com/jazz-soft/test-midi-files
Or you can even add some more test cases to the repo.