Down The Sync?

Last time, I told you a bit about my work looking into multichannel audio for BBC HD. I’m getting settled into this project now, and I’m starting to build a decent map of the Dolby E signal chain. I’ve met most of our technology partners and made contact with a few more. Here’s some of what I’ve found out so far…

It became clear pretty quickly that synchronisation is a big deal in the world of Dolby E. Really there’s 2 issues here:

  • Traditional signal synchronisation, whereby video and audio signals’ timing is adjusted to match a common reference, causes big problems in a Dolby E environment.
  • Like any coding system, the encoding and decoding of Dolby E has latency involved. Therefore matching the delays between video and audio paths becomes critical to ensuring accurate lip sync.

So right now that’s what I’m focussing on. Already I’ve discovered that we’ve got a number of gremlins in the system, but the folks at Red Bee and Siemens are working hard to make things better. In the mean time I’m getting under their feet asking for piles of information about their equipment setups, but hopefully also contributing in a helpful way too.

Those of you who watch BBC HD will shortly be seeing the fruits of my labours on air in fact. A short while ago I was discussing the signal chain in one of the many technical areas that our signal passes through, and I walked away with some schematics. I took them back to my desk and quickly found a problem… the processing delays in the audio chain weren’t being correctly compensated for in the video chain, meaning that all BBC HD output had its audio a frame behind the video. In other words, the lip sync was off by 40ms. This isn’t exactly what we want! I won’t name and shame, especially because the blame can’t necessarily be attributed to any individual or organisation, but suffice to say that it was more of a paperwork mess-up than a  technical one. It transpires that the technical area in question was working to an old version of our working practices, which specified a frame of offset was to be kept between audio and video until point of transmission. This means that you can whack the audio through a decoder (with 1 frame of delay) and get sound out of it that was in sync with the video. We now work in a different way however; audio and video should always be kept in sync, and the person decoding the audio has the responsibility to delay the video to match. This ought to be less confusing, but it seems it didn’t work out that way!

What made this issue even more tricky to spot previously was that in the early days of BBC HD (remember it started as a trial service on a shoestring budget and only recently became a fully-fledged BBC service) we had problems with video kit introducing unpredictable delays. In particular, equipment working flat out was producing delays which actually varied over time, making accurate measurement and compensation a nightmare. So with video delays being introduced and no real way to be sure of what they were, an extra 40ms delay in the audio chain (as I spotted) was not only difficult to notice, but may have actually been helping us until recently! Andy Quested (Head of technology for BBC HD) commented in a response to his own blog post. Now we’ve upgraded some of the kit, we’re starting to iron out these issues, and hence come across new ones like one I found here. Since it was found, Andy undertook some consultation with colleagues at BBC R&I in Kingswood Warren, and a change to correct this problem has now been agreed and will be on air very soon. Phew! [Update - it’s been changed, so the sync should now be improved.]

Meanwhile in our playout centre, I’ve been running around with Red Bee’s engineers trying to understand the timing issues there. They’ve put in a great deal of effort to attempt to make sure everything is OK, and have done lots of good work.  Their synchronisers are mostly a model which performs a “Dolby E re-align” process before synchronising, which makes sure the Dolby audio data is in-sync with the video data before worrying about synchronising the whole lot with an external reference. This ensures that the audio doesn’t get mangled in the process, so there’s a big tick in that box. However they’ve had issues with what happens between programmes when switching sources (i.e. from programme to programme or to/from trailers). If you pay very close attention, you may notice quiet clicks on the audio or brief silences, usually around half a second after we transition from one video source to another. We’re working through these issues together with some input from Dolby, and I’m hoping to get to the bottom of things soon, at which point I’ll explain more.

Beyond simply problem-solving, my task here is really to help prevent future problems and collate some understanding about the use of multichannel audio technologies in order to improve our operations in future. In Red Bee, the lip sync seems to be pretty much spot on after extensive testing that they’ve done. However what’s happened is that they’ve done some tests on how delayed the audio gets compared with the video and then delayed the video to compensate. This works just fine, but it makes part of me a little nervous. It’s here that you’ll see the difference in approach between myself and the playout engineers; they have a service to keep on air and they want it to look and sound as good as possible. They do that well, but my priority is different; where they want to know that things to work, I want to know why they work. (Actually, they want that too, it’s just priority number 2 for them and priority number 1 for me!) I want a diagram with all the bits of equipment and their associated delays, and I want it to add up! I’m in the process of drawing that diagram, but as yet I can’t quite make it add up. I’m catching up with my colleagues there tomorrow to do some arithmetic, and you never know, we might get somewhere.

Of course there’s lots I haven’t told you here, but I don’t want to bore you. More detail will come soon, as well as some information on the other questions I’m trying to answer, such as “just what do you do when you want to put Dolby E into a file-based workflow?”.  Feel free to comment below.

I’m an engineer with the BBC and sharing information about my work, but this is my personal website.