Don’t Forget The Kitchen Sync
A couple of weeks ago I told you about the work we’ve been doing on the synchronisation of audio and video (lipsync) in our surround sound signal chain. However, no matter how much work we do, there’s one thing we can’t control, and that’s the equipment in your front room. You might not know this, but your shiny new flat-screen TV (LCD or plasma) introduces somewhere in the region of 40 to 100 milliseconds of delay, which means that if your audio isn’t delayed to match, the sync between the two is quite considerably wrong. Worse still, the audio is ahead of the video, which is much more noticeable than the sound being late.
Why? Well think back to your GCSE (or O-Level!) Physics lessons. Sound travels much slower than light, so you are used to hearing the sound of an event slightly after seeing it, particularly if it happens far away. Just try going to a gig in a stadium, and you’ll notice that if you’re at the far end of the stadium from the stage, the singer’s lips will be moving well before you hear the sound. So audio being late, whilst undesirable on TV, is much more tolerable than the video being late. The latter scenario looks very unnatural indeed with even quite a small error.
Most HD set-top boxes allow you to adjust the audio/video sync on the outputs, usually in 20ms steps. However just by watching TV programmes, it’s hard to judge when the sync is correct. As such, we wanted to do something to help our viewers to get their own setups correct – some of you have been asking for this in comments on our blog posts, and we suspect more will be interested in trying it when given the opportunity. So we’ve been devising a sync test which will be broadcast a few times during each day on BBC HD, starting in a week or two. The test signal is based on work from Andrew Mason, Oliver Haffenden, David Kirby and Alastair Bruce at BBC R&I, and it should allow you to adjust your set-top box to an acceptable level of sync just by watching the sequence and tweaking your settings.
If you want to get even more precise, you can make your own sync test device! The signal has been designed to be easy to monitor with a simple electronic circuit, using a light probe to sense a flash which appears on the screen once a second and an audio input to listen for a ‘clap’ which happens at the same time. The device can then tell you the time offset between the two and hence you can adjust your set-top box to compensate. Details will be posted on the BBC website. The ‘clap’, incidentally, is a recording of two bits of wood being snapped together; believe it or not we found this at least as effective as more ‘high-tech’ alternatives such as a brief burst of tone.
My job in all this has been to ensure that the test signal is in-sync when it gets broadcast, which is trickier than it sounds. Of course we aim to ensure that everything we transmit is in-sync however it’s absolutely impossible to ensure that sync is perfect, not least because the delays introduced by some equipment vary over time. Within a small tolerance of a few milliseconds, the difference is imperceptible anyway so it’s not a problem. The EBUdefines standards for sync that say that when a programme is delivered to a broadcaster like ourselves, audio should be within +10 to -20ms (i.e. no more than 10ms ahead or 20ms behind the video). Of course, to ensure that the signal is within sensible tolerances when a programme actually gets broadcast, each step of the chain has to have sync errors much smaller than this, otherwise the delays could add up to a much larger a total error. When transmitting a signal whose express purpose is to be in-sync we’d like the sync to be even tighter than usual, which means making sure that every step of the chain is as close to ideal as it can be.
The signal started life on an edit suite, and so job number one is to ensure that when it comes off the edit suite and on to tape it stays in sync. Along the way we have the audio encoded to Dolby E, so we’ve already got 3 bits of equipment in play: the edit system, the Dolby encoder and the tape deck. So we do that, check for any offset, correct it in the edit suite and then get back on to tape again. But wait… how do we check the sync? I’m armed with our sync-checker, but in order to use it, we have to decode the Dolby E and play the video out to a monitor, both of which could introduce their own delays! So we have to ensure we know the delays of each component in the chain, isolating them one by one, before we can rely on our measurements. Rule number 1 of testing is that you must ensure that your test equipment isn’t affecting the results, or at least that the effect is known. In this case we can’t test without having an effect, but isolating that effect allows us to get accurate measurements. It means we have to be really careful though – forget one source of sync error and you mess up all your results! That’s my justification for the terrible pun that titles this post…
Then there’s the signal chain to get the test sequence to air. We ingest the tape onto our playout servers (this process could, of course, introduce sync error), then play it out though a presentation mixer and some processing gear then down some fibre optics to Television Centre. From there it goes on through to the Coding and Multiplex centre where the signal is prepared for digital broadcast. All that could introduce a sync error, as could the coding process itself; the audio and video are coded separately and multiplexed back together, then multiplexed in with other channels for broadcast. Argh! So I’m going to work with staff from Red Bee and Siemens (our technology partners in these areas) to run the signal through the off-air chain, a backup set of equipment and connections used if the main signal chain goes down, and also in testing situations like this. We’ll measure the sync error through this whole set of equipment, and if necessary adjust the offset at the encoders to get everything back into sync.
I’m fairly confident that there shouldn’t be a big sync error in this signal chain, as it’s been tested before and we’re broadcasting with it every day, so major errors would be noticeable. However as I mentioned previously, our tolerances for broadcasting this test signal are much tighter than usual, so it will be a great chance to check that everything’s working as well as it can possibly be. Hopefully all will go well, but you never know – I’ll let you know next week!
I’m an engineer with the BBC and sharing information about my work, but this is my personal website.