Timecode Issues:
A Quick Guide

Imagine this situation: A client sends you a subtitle file to translate, along with the corresponding video. You download them, open both in your subtitling tool, do all the settings, get comfy in your chair before commencing work, aaand...   you notice that the timecodes are off — they don’t quite match the audio. Unsure whether it was you or the client who did something wrong, you wonder: “Okay, now what?”

Sounds familiar, doesn’t it? Happens a lot. So much, in fact, that the second most-asked question I get, right after the one about subtitling rates, is... “What’s going on with my timecodes?” To answer it once and for all — and help people fix their issues — I’ve decided to write this short article.

 

A bit of terminology

To start, let me give you a few quick definitions — just to make sure we’re on the same page.

Frame

One of the many still images that collectively make up a video. Shown in quick succession, they produce the illusion of continuous movement, i.e. a motion picture.

Muybridge_race_horse_gallop-694x416.jpg

Frame rate

The speed at which consecutive frames go one after another in a video. It is measured in frames per second (abbreviated fps) and it commonly ranges from 23.976 to 60, depending on the camera / software used for video capture as well as the intended broadcast method — cinema, television, web streaming, and so on.

Offset

A constant mismatch between where subtitles appear and where they should be. When an offset is positive, your subs come up too late, and when it’s negative — too early. For instance, here’s a −0.5 sec offset:

offs3.jpg

Drift

A progressively increasing mismatch between the subs’ timing and the soundtrack. Usually it goes from zero at the start of the subtitle file and up to seconds or even minutes near its end.

drift.jpg

 

SMPTE [pronounced “simpti”]

The Society of Motion Picture and Television Engineers, a global association of engineers, technologists and executives working in the media and entertainment industry. SMPTE has developed and published over 800 technical standards for broadcast, filmmaking, audio recording, etc.

 

Burned-in timecode (BITC) [pronounced “bitsi”]

An image overlay with timecode information. Used for synchronization, scheduling, and other purposes. Can be in the SMPTE format (hr:min:sec:frames) or the media format (hr:min:sec:msec).

newestbob.png

Drop-frame (DF) and Non-drop-frame (NDF)

This one is a bit technical, so please bear with me. Back in the day, black-and-white television in North America had a frame rate of 30 fps, as it was a convenient exact half of the electrical grid’s 60-Hertz power line frequency. When color television came along in the early ’50s, the TV signal had to be modified to include color information. This change, however, created visual distortions in monochrome TV sets — their older circuits couldn’t handle it well enough. So, to make the signal compatible with both black-and-white and color TVs, the engineers found an interesting solution: to slow down the frame rate by 0.1% — from 30 to 29.97 — which, for complex reasons, actually did the trick and kept image artifacts to a minimum.

But... there was an unfortunate side effect: an hour of SMPTE timecode no longer matched an hour of real time, by exactly 108 frames (0.1%), which spelled disaster for broadcast scheduling and some other related processes. To fix this discrepancy, a new standard was developed, called “drop-frame timecode”. The idea was quite simple: if you skip (“drop”) the first two frame labels of each minute, except each tenth minute, you end up with exactly 108 labels less per hour of footage, making up the difference pretty much perfectly. Problem solved.

Over the following decades, advances in technology have made these two legacy solutions unnecessary, and yet they’ve endured through time, remaining in widespread use to this day. And so, when we say, “drop-frame” (DF), we refer to the standard for 29.97 fps videos that matches their SMPTE timecode with real time, while by “NDF” we mean letting the frames run behind and drift away 0.1% per video hour.

Setting up

 

Okay, so you have a time sync issue. What do you do? Well, before writing to your client, you need to make sure the problem isn’t on your end. Here’s a quick checklist:

1. Did you choose the correct frame rate?

 

Many subtitling tools (especially professional ones) will auto-detect your video’s frame rate to save you time and hassle, but if your software doesn’t do that, you’ll have to adjust it manually in the settings. In that case, you will need to first locate the video’s frame rate attribute as follows:

  • Windows: right-click on the video file → PropertiesDetails

  • MacOS: open the file in QuickTime → WindowShow Movie Inspector

  • Linux: you can use VLC.

Now, if the video is 29.97 fps, you’ll also have to figure out whether to choose DF or NDF. Sadly, there’s only one way to tell without asking the client — and that’s through the burned-in timecode:

  • If the frames jump from :29 straight to :02 at the start of each minute (except each tenth minute) and the BITC uses a semicolon or a period as the last separator (hr:min:sec;frames) — it’s DF.

  • If you have a colon separator (hr:min:sec:frames) and no labels are skipped — it’s NDF.

colo.jpg
colon.jpg

 

Not all videos have a burned-in timecode and not all editors know (or bother) to use the correct notation, so in case the above method doesn’t apply, just go with DF and see if it works okay.

As far as 23.976 fps — which is 24 fps slowed down by 0.1% for easy conversion to 29.97 — it’s always NDF, since there’s no way to keep the same number of labels for this frame rate.

 

2. Did you set up the timecode correctly?

 

When starting a project, one of the things you have to do is align the subtitling tool’s timeline with the BITC, so that they’re in sync. This is where free software struggles, as it often has no functionality for such a setup. On the contrary, many professional tools provide you with a quick and easy — if not automatic — alignment. Here’s how it’s done in EZTitles, for example:

tc_setup.png

 

Yes, believe it or not, timecodes don’t always start at 00:00:00:00 — they can begin at one hour, ten hours, etc. But in the absence of a BITC or any specific client instructions, feel free to leave “all zeroes”.

 

3. Do you have up-to-date codecs installed?

 

Some subtitling tools pre-install or contain correct codecs to ensure smooth video playback. Others don’t. So, just to be on the safe side, get a recent version of a tried-and-true codec pack on your computer system.

For Windows, I usually recommend K-Lite; for Linux — whatever’s best for your distribution; while for MacOS you don’t really need anything.

 

4. Did you fully follow the client’s specs and guidelines?

 

This one is self-explanatory. Whatever you’ve been told to do on the technical side, make sure to comply.

Troubleshooting

 

Okay, you’ve checked all the boxes but the issue persists. Now what?

 

Well, here’s my list of possible scenarios:

 

1. You have a fixed offset

 

2. You have a non-fixed offset

 

3. You have a fixed drift

 

4. You have a non-fixed drift

 

5. You have a small, random mismatch

 

6. You have a software-specific mismatch

 

7. It’s something else

 

 

The above list is by no means exhaustive, but it’s a good framework to have in mind when trying to figure out what went wrong with your timecodes. I’ll be updating it going forward as I come across new information.

 

 

All right, this is it for now. I hope you found this article useful. As always, if you have any questions, thoughts or remarks, feel free to write them in a comment below.

Cheers!