A system meant to automate station auditing, developed for the BBC

1. Background

All of you readers that have been running a broadcast station, have certainly heard complaints due to programs or promotions that should have been broadcasted, but simply were not...because somebody just forgot about it, either issuing it manually, or programming it to go on the air at the right time.

We at Acutron got some experience on remote control using the audio on the airwaves as a carrier, and after some chats with industry pros it become readily apparent that the hardware we had developed for remote control purposes, since it was totally controlled by software, could in fact be used to solve the problem of broadcast event logging, the right way, automatically.

The hardware we had consisted on the RCT1/RCR1 control system. This system superimposes a digitally-modulated carrier, either at the bottom or at the top of the spectrum, allowing the transmission of digital frames with error-detection and correction, frames that may be used to serve a variety of purposes, such as for example closing a contact at a remote broadcast station from the network head, sending a serial packet to control some equipment on the other side by means of a serial port at the receiver, or just e-mail something to somebody up the hill where the transmitter is located.

2. When ideas come to practice

The idea came to practice when BBC Radio Five Live asked us to develop a system that could identify any available on-the-air material which duration was over about 7 seconds, either analog or digitally recorded.
To be brief, the system had to be inaudible in actual operation and had to withstand 10dB up or down departures from normal working levels, imposed by console operators. Worse than else, the system should do that in mono, precluding us from using our standard stereo phase-concealing methods to prevent frames from being heard, as well as to provide us with positive frame-identification under heavy program material.

Finally, the system should allow for heavy phase and frequency response variations as the ones present when using cart machines, and be immune to half second program dropouts typical of many tape-based systems, as well as to the artifacts of commonly-used data reduction systems. In what user interface was concerned, a very simple Windows™ all-button user interface should be designed allowing for easy operation avoiding lengthy operator training.
The system should identify each properly marked track present on air and to record the event on a Windows™-based computer, using an industry-standard database format. Fields to record included name of piece being played, date and time of creation, duration and an unique identification number.

Solution to the actual problem we had in hands required a blend of expertise in hardware in order to master the media where the useful signal co-existed with large amounts of program signal, under negative signal-to-noise ratios (noise is the program signal, in this case...) as well as very fast communications and relational database handling under Windows™.

3. How the system was designed

We designed the system, which was readily called SNOOP as a 3-piece package.

The first one is a recording station, where the material to be launched on air is recorded on the final media, and marked with a digital frame describing its content, using a computer coupled to a modified Larsen RCT1 encoder, and is called STAMP.

The second one is meant to detect the pieces, where the incoming audio enters a modified Larsen RCR1 decoder that is coupled to a computer which logs the interesting events (those that have digital frames built-in). This part of the process was called SNOOP.

Finally, the third and last is purely computational and allows an operator to retrieve the log data, relating it with the original media data and sorting the results by date, by event, showing or hiding the internal system events, and so on. This last part was called CHECK.

This three-piece outfit implies the three phases that the system undergoes under actual operation, as can be seen on the accompanying diagram:

First an operator will mark-up the track to be detected in a cart, hard disk piece or minidisc, then somebody launches the track on-air at a later time. The systems will then detect it and log it to hard disk. At a later stage, somebody will collect both the media database and the logging database that the system created and inspect its contents on screen.

In what concerns hardware, we had to compromise strongly to get acceptable final results. Our system uses a carrier which amplitude is digitally-modulated. Modulation is in perfect sync with the carrier zero-crossing so if the carrier is in itself inaudible and at the bottom end of the spectrum the modulated signal will also be inaudible. To get acceptable rejection of very wide amplitude variations, we had to increase the time window in which we detect each bit in the signal, in order to allow for the settling time of a steep carrier filter. However, the increased marking signal time could prevent us from detecting very short tracks...

On the firmware side, the system uses a structured frame with built-in sync, byte count, and checksum. Each byte sent uses parity detection. This allows for error detection and correction, since the system is capable of regenerating a single erroneous byte in the frame knowing its position and guessing its value from the checksum. The followed policy was never to show an erroneous reading to the operator, at the same time allowing for a single byte dropout (1 second).

The user software was built around the libraries we had made for the WinAir automation system and features an interface that solely uses buttons, as can be seen on the enclosed screen copy, to prevent untrained operator confusion. The detecting software is an iconized application that works even if the operator performs a DOS session on his/her PC. To do that ensuring that the system will run even on Windows 3.11 we had to write extensions to the Windows kernel in the form of virtual device drivers, using 32-bit assembler code. Most of the software in fact uses 32-bit assembler to speed up the processes, either in what database handling or screen drawing is concerned.

The end result was a reliable and easy to use system, meant to ease the life of broadcasters, and built around existant hardware, thus improving compatibility and decreasing system costs.