Paul White takes a closer look at SMPTE and MIDI Time Code, and their role in tape‑to‑MIDI sync.
The Society of Motion picture and Television Engineers devised SMPTE, the timecode that bears their name, to sync soundtracks to films, so that separately‑recorded dialogue could be added after filming, without having to rely on sprocketed tape and manual lining‑up of start points.
Later, it was discovered that SMPTE time code was also a useful way of synchronising one tape machine to another. Both machines carry a track of code, and a synchroniser box compares the time positions of the two codes. If the codes are not identical, a control signal is derived which changes the speed of the slave tape machine, forcing it to move back into sync with the master machine.
Initially, such SMPTE systems were very complicated and expensive, but now that we have dedicated, inexpensive microchip sets capable of handling SMPTE generation and reading, SMPTE is cheap enough to use in MIDI studio applications. The code is based on real time, measured in hours, minutes and seconds, with further subdivisions to accommodate individual frames of TV and film material. This is in direct contrast to MIDI Clock, which is a direct multiple of tempo. Because SMPTE is independent of tempo, a whole tape can be recorded or 'striped' with code before any recording or programming starts — I like to think of this as being similar to printing the 'cm' and 'mm' divisions on a ruler. Before going any further, it might help to see what these invisible markings actually tell us.
Strictly speaking, SMPTE code covers only the American TV format of 30 frames per second (fps) and film at 24fps, the European equivalent being EBU code, which relates to 25fps TV. It's now common to combine both codes under the title SMPTE/EBU, but most people still refer to the code as SMPTE, whatever its format. Apart from the more common 24, 25 and 30 fps formats, the standard also includes 'drop frame', which is used when converting film to TV. The system gets its name because whole frames of picture are periodically discarded, to eliminate cumulative timing errors which would otherwise build up, due to mathematical remainders which occur in the conversion maths.
Drop frame is not used in audio‑only applications; it is more usual to set the SMPTE format to the local TV standard: 25fps in the case of Europe's PAL and SECAM broadcasting systems, or 30fps in the USA or other countries which use the NTSC system (or 'never the same colour twice' as it tends to be known). Because the frame rates of film and TV are still too coarse a measure for audio — where even tiny timing differences can throw the feel of a piece — additional resolution is achieved by interpolating between individual frames.
When using SMPTE to sync a MIDI sequencer to tape, the SMPTE code is normally recorded on the highest‑numbered tape track, and the track output fed back into the converter box. Noise reduction should be avoided if possible, because it can introduce errors into the code. Because sequencers can't read SMPTE directly, a conversion has to be done somewhere along the line, to generate a data format the computer can understand. This could involve a conversion to MIDI Time Code (MTC), or in the case of C‑Lab's original Unitor box (which was used with Creator and Notator software on the Atari ST computer), the interface communicated directly with the processor inside the ST (see picture).
In addition to converting SMPTE into a form the computer can read, however, it is necessary to convert the SMPTE time information into musical tempo, and this is handled either by the computer used to run the sequencing software, or by a dedicated SMPTE‑to‑MIDI sync box. The initial tempo of the piece of music and the SMPTE location of the song start, plus the degree and location of any subsequent tempo changes are stored in the form of a 'tempo map', which must be created before the sequence can be sync'ed to tape. Most of the current generation of sequencers can build their own tempo maps, which are stored along with the sequence data, making the whole system very simple to use.
MIDI Time Code
The phrase 'MIDI Time Code', or MTC, often crops up when talking about sync'ing MIDI devices to each other — but what exactly is MTC, and what are its benefits when compared to, say, SMPTE or MIDI Clock sync? Most textbooks dismiss MTC by saying that it's the MIDI equivalent of SMPTE, but that's not really the whole story. It's true that some MTC systems work by taking SMPTE from tape and then turning it into MTC (Philip Rees' TS1 unit, for example, reviewed in SOS March '95, is capable of this) — but then the Alesis BRC can generate MTC directly from the ADAT's own subcode without SMPTE necessarily being involved at all. Essentially, MTC follows the same format as SMPTE in that it is independent of musical tempo and expresses elapsed time in hours, minutes, seconds and frames, and all the common SMPTE variants have an MTC equivalent.
Standard MIDI Clock sync doesn't include any position information — it's rather like the sprocket holes in cine film — so if a sync pulse gets lost, the sequencer will happily follow along one pulse late. SMPTE, on the other hand, comprises a continuous stream of positional data, so if a short section of code gets lost or corrupted, the system knows exactly where it's supposed to be the next time a piece of valid code is read. MTC also includes positional information, but because it has to share the MIDI data highway with other information, its data is sent in short bursts — four to each SMPTE frame. It takes eight of these 'quarter frame' messages to carry enough data to make up one complete set of location data, which means that the receiving MIDI device must read two frames of code before it knows where it's supposed to be.
Technically, MTC can't pass on positional information as quickly or as accurately as SMPTE, but for practical tape‑to‑MIDI sync applications, a little clever software writing on the part of the sequencer designers ensures that there's no practical difference.
If MTC has a weakness, it's that its position in the MIDI data stream can get jostled about when a lot of data is being sent; if you have a multi‑port MIDI interface, it's usually best to make sure the port carrying the MTC isn't clogged with other MIDI data. 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 timing jitter. In really adverse situations, this may be serious enough to be noticeable.