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.
