I've never seen a midi file that uses looping.
Be aware that there's not a standard way to indicate that a MIDI file "uses looping" within the file itself.
However, some kinds of short music might make sense to loop, like some kinds of video game music or a ringtone. If you are using a MIDI player that has an option to loop the entire file, you might want to loop these kinds of MIDI files if desired.
In a case like that, imagine that an End of Track event indicates the music ends with a measure of one quarter note and three quarter rests. Ignoring the End of Track event and looping after the quarter note would mess up the beat. Obeying the End of Track event and looping after the three quarter rests would preserve the beat.
I attach two 'decode' .TXT files for your information.
Geoff, be aware that the program you use to convert MIDI files to text seems to have the following issues:
1. When it converts a position in ticks to a position in seconds, the precision of the calculations seems to be a little bit off.
In your text files, the events labeled with "2.001" seconds are really at 2 seconds exactly, and the events labeled with "4.001" seconds are really at 4 seconds exactly. In the second file, the tempo event labeled with "16.255" seconds is really at 16.25 seconds.
2. When it converts a position in ticks to a position in seconds, it seems to have a problem handling a large number of ticks.
In the first example, it looks like the program couldn't handle the large number of ticks of the first track's End of Track position (3,840,000 ticks) and defaulted to a position of zero seconds.
In the second example, there are two tempos. When the program attempted to convert the first track's End of Track position (also 3,840,000 ticks) to seconds, it looks like the program was able to calculate an amount of seconds for the range covered by the first tempo, but when it tried to add the amount of seconds for the range covered by the second tempo, it seems to have failed to calculate that and used zero instead. So the sum of the two ranges ended up just being the position of the second tempo event.
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).