Hello!
MIDI specification on SMF is a bit confusing regarding storing a tempo map in a MIDI file:
for a format 1 file, the tempo map must be stored as the first track
Does it mean a first track chunk must contain only tempo map? Or other events allowed there, but tempo map for the first chunk only?
Another info from the spec:
tempo maps (which describe the tempo throughout the track, and may also include time signature information, so that the bar number may be derived)
So tempo map can contain only Set Tempo and Time Signature events?
Max,
A Tempo Map is not an entity on its own, it's a series of Meta Events each at a particular Delta Time that define the tempo at a particular point within an SMF.
So, very frequently, there is just one Set Tempo event at the start of the song in the first track alongside many other Meta Events, e.g. Time Signature, Key Signature, Marker, Copyright Notice and so on.
But then further Set Tempo events may be required, occasionally alongside Time Signature and Key Signature events occuring throughout the SMF all within the first track.
An example:-
Yes, I know all those things. My question is tempo map must be always placed in first track chunk? And should be this chunk separate or tempo map can be palced inside first track chunk along with notes data for example? And can I place Copyright Notice event in second chunk? So what exact events make up a tempo map?
The Standard says all tempo events must be in track 1, however I saw many files with the tempo events in other tracks, and all players I tried played those files correctly.
It does not matter where you put the copyright notice, It will not be audible anyway 🙂
I understand all that 🙂 I just want to make spec clear for me. What is tempo events? Set Tempo and Time Signature only?
[quotePost id=14749]Does it mean a first track chunk must contain only tempo map? Or other events allowed there, but tempo map for the first chunk only?[/quotePost]
No. Other events are also allowed in the first track.
Further to the above, the Standard Midi File specification that I have says that the Tempo items SHOULD be in the first track. Does not say MUST be, which is quite different. So if they are elsewhere, this is not WRONG, although it may not be ideal. Some software MIGHT look for tempo items in the first track, and MIGHT have a problem if they are not, or are not ALL there, but I would say that the software is wrong to assume that they MUST be in the first track ONLY.
As Tempo items affect everything, and most tracks are likely to be channel specific, it is reasonable - for simple tidyness - to put tempo items in the first track.
But I'm being pedantic?
geoff
Geoff, can you please say what spec do you use? I use The Complete MIDI 1.0 Detailed Specification (document version 96.1 third edition) taken from midi.org. And it uses "must" word. But I agree with all you said.
Max,
The version I have is older than the one you refer to.
It's dated 29th Nov 1989. But that may be the document rather than the official spec. The offical spec referred to is noted as v 0.06 dated March 1st 1988. This is a doc covering SMF (Standard Midi Files) ONLY. I think I downloaded it from CompuServe prob in the early 90s.
This document is presented as official from the International MIDI Association.
I also have a PDF version marked as v 1.1, dated 1999. This is marked as being produced by someone else, but based on the earlier official version. The wording here seems to be the same.
However, while comparing the two docs, I note there is an inconsistency. When referring to the Tempo meta-event specifically, the wording says SHOULD in more than one place. However, then is also a specific reference to a 'tempo map', and here the specs I have do use the word MUST. Most midi files have a single use of a tempo and time base command, does that constitute a 'tempo map'? I can certainly accept that if there are multiple tempo/time base settings, spread through the file, then it would be quite reasonable that these OUGHT to be together in the first track and therefore MUST would be reasonable - these could well constitute a 'tempo map'?
Is this muddying the waters even more?
Geoff
Pretty strange to see the tech spec which causes confusions and opinions 🙂 But we have what we have. Hope SMF2 will be more clear and unambiguous. Thanks to all who took part in the discussion!
The latest version of the Complete MIDI 1.0 Detailed Specification, as stored here for download in the Specs section of the MMA web site is the Third Edition 96-1-4.
If you look in that document at the Standard MIDI Files 1.0 section, and then at the part that describes Formats 0, 1 and 2, in the third paragraph where it's talking about tempo maps it uses the word "must" when referring to type 1 files. I quote "for a format 1 file, the tempo map must be stored as the first track,"
Agreed, it uses "should" in other parts of the document, but I feel this sentence makes it absolutely clear.
I think we should interpret "should" as that track 1 is the correct place for tempo events, but they might not always be there because of non-standard programming..
However, having said that, I too have come across tempo, time signature and key signature events dotted all over various, shall I call them, non-standard MIDI files.
A good, well-written sequencing program should, in my view, be able to handle these misplaced events and, upon re-saving the file after editing, move them to the correct place, that is into track 1.
I'd just like to reiterate, in different words, that a tempo map is a concept not an actuality.
A tempo map can be viwed as the sum of all Set Tempo and Time Signature events stored (hopefully, if the program is well written) within track 1, alongside various other bits of meta data. A SMPTE may also represent part of that tempo map data.
Max, it's not unusual in my experience to find spedifications confusing. They are often written by a committee or at least more than one person.
Many years ago when I was working in Germany, before a major exhibition, my team had to sort out why the German ISDN network wouldn't communicate with the French network.
One of my protocol analysts found the problem - a difference in interpretation of the standards. Mark you, these particular standards occupied a whole shelf.
Any clearer?
JohnG.