Welcome To BBC HD…
…So says the email signature of Andy Quested, head of technology for BBC HD. It’s to him I’ll be working for the next six months or so while I undertake a project to look into multi-channel audio delivery for our High Definition TV channel. I’m only just starting to get stuck in, so there’s a long way to go and I can’t provide much detail yet, but I thought I’d provide you with a quick overview of my work area first of all.
For high definition production, we at the BBC use a technology called Dolby E to squeeze up to 8 channels of audio down a digital connection designed to take 2 channels (AES-EBU). This allows us to incorporate surround sound into our existing stereo workflow with far less investment in new technology, which has to be a good thing. Dolby E uses a virtually lossless codec, which means the degradation to the sound quality should be inaudible (unlike Dolby Digital, the format used to actually transmit the signal to your set top box, which is lossy). So far, so good?
Dolby E and Dolby Digital also carry a bunch of metadata (literally “data about data”) which describes the audio being carried, and importantly controls the output at the end of the chain. So if you’re listening in stereo rather than 5.1 surround, the metadata may have an effect on how the surround is converted to stereo. And have you ever noticed how adverts and trailers on TV are often louder than programmes? Well that’s a contentious issue, and something that we’re trying to avoid. Dolby E/D ideally should help us with that by using… you guessed it… metadata. So you can see that we have to get the metadata right, and that’s a new issue for the TV world, making content generation more complex than it was in the old stereo days.
Then there’s the amount of kit involved in the signal chain which can mess things up. As an example, many consumer decoders (your surround sound amplifier or receiver) have issues when we switch between stereo and 5.1 output. This results in a loud, short ‘splat’ (around 40ms) which won’t be particularly good for your speakers. On the broadcaster’s side of things, there are issues like timing problems to be aware of. When it’s embedded in a video signal, Dolby E is designed such that the audio is inserted at the same frame rate as the video. However if the exact synchronisation of audio and video isn’t correct, equipment can interpret it as standard linear audio instead of a Dolby E stream, which means you get very high values of data being converted into audio which equates to more loud splats.
In these modern days of the BBC, we have outsourced a lot of our infrastructure, so the signal chain is complex. A programme will be originated by an outside broadcast company, BBC Resources or another studio company, then sent to Siemens who run our central communications area. From there it goes to Red Bee who do continuity and so on (“Coming up next on BBC One…”) before heading back to Siemens to be encoded and finally to a transmitter run by someone else. It all works remarkably well, but in a project like mine it means I have a lot of different parties to communicate with. My main focus right now therefore is in communicating with all these parties and finding out what their part of the chain looks like, what issues they have, and what would help them in the future. Later on I’ll be looking into better ways to test our systems, specifically full end-to-end tests that will allow us to check the whole chain and identify problems if they occur.
More detail will come in time. I’ll be sharing my experiences in addressing the problem and letting you know what we’re doing to avoid problems in the future and fix problems we’ve had in the past. After all, no-one wants a re-occurrence of our experimental reverse karaoke broadcast! Feel free to keep in touch via the comments.
I’m an engineer with the BBC and sharing information about my work, but this is my personal website.