1. Um pouco de história

Todos os leitores que são donos de uma estação de rádio já ouviram queixas devidas a programas ou promoções que deviam ter ido para o ar mas não foram...porque alguém se esqueceu, quer de as pôr no ar quer de as programar para irem para o ar à hora certa.

Nós na Acutron tínhamos já alguma experiência a utilizar portadoras embebidas nos canais de audio das emissões para fins de controle remoto, e depois de algumas conversas com profissionais da especialidade tournou-se-nos evidente que o hardware que tínhamos desenvolvido para aplicações de controle remoto, como era completamente comandado por software, podia ser aplicado na resolução do problema da auditoria de programas, da forma correcta, ou seja automáticamente.

O hardware de que dispúnhamos consistia no sistema de comando RCT1/RCR1. O sistema mistura ao sinal uma portadora digitalmente modulada, quer no extremo grave quer no extremo agudo, permitindo a transmissão de tramas com detecção e correcção de erro, tramas que podem servir para uma grande variedade de aplicações, desde fechar um contacto numa estação remota a partir da cabeça de rede, mandar um pacote de informação série para controlar um qualquer equipamento remoto através de uma porta série situada no receptor, ou ainda deixar uma mensagem a alguém no alto da montanha onde se encontra o transmissor.

2. Quando as ideias são levadas à prática

A ideia foi levada à prática quando a BBC Radio Five Live nos pediu que desenvolvêssemos um sistema que pudesse identificar qualquer programa no ar com uma duração superior a 7 segundos, difundida de qualquer suporte, analógico ou digital.
Resumindo, o sistema tinha que ser inaudível enquanto operasse e tinha que tolerar variações de nível de 10 dB para mais ou para menos no nível nominal de trabalho, impostas pelos operadores de consola. Pior ainda, o sistema deveria efectuar todo o trabalho em mono, não nos permitindo utilizar os nossos clássicos métodos de marcação por fase de modo a impedir as tramas de serem ouvidas, e ainda de nos permitir identificá-las com clareza, mesmo quando embebidas em programação de grande densidade.

Finalmente, o sistema devia tolerar grandes variações de fase e frequência de resposta tal como impostas pelas cartucheiras, e ser imune às brancas de sinal de até meio segundo típicas de alguns sistemas baseados em fita, bem como às consequências da actuação dos sistemas de compressão de dados utilizados no mercado. No que respeita à interface com o utilizador, teria de ser criada uma interface muito simples sòmente baseada em botões em ambiente Windows™, permitindo uma operação simples e evitando um treino longo dos operadores.
O sistema devia identificar cada trecho préviamente marcado presente no ar e registar a ocorrência num computador com sistema operativo Windows™, utilizando um dos formatos de ficheiro de base de dados corrente no mercado. Os campos a gravar incluiam o nome, a data e a hora de criação, bem como um identificador único.

A solução para o problema que tínhamos em mãos requereu uma subtil mistura de conhecimentos no âmbito do hardware para lidar com um ambiente onde o sinal útil coexistia com sinais de programa fortíssimos, em condições de relação sinal-ruído negativas (neste caso o ruído é o sinal do programa...) bem como no âmbito do processamento rápido de comunicações e bases de dados relacionais em ambiente Windows™.

3. Como desenvolvemos o sistema

Desenvolvemos o sistema ao qual chamámos SNOOPER (bisbilhoteiro) como uma junção de três partes.

A primeira consiste numa estação de gravação, onde o material a lançar no ar é gravado no suporte final, e marcado com uma trama digital descrevendo o seu conteúdo, utilizando um computador ligado a um codificador Larsen RCT1 modificado. A esta parte chamámos STAMP (selar).

O objectivo da segunda é o de detectar os trechos, em que o audio entra num descodificador Larsen RCR1 modificado o qual liga a um computador que regista a ocorrência dos trechos de interesse (aqueles que foram préviamente marcados com tramas digitais). A esta porção chamámos SNOOP (bisbilhotar).

Finalmente, a terceira parte é puramente computacional e permite ao operador consultar os dados da auditoria, relacionando-os com os do registo de material disponível e ordenando os resultados por data, por evento, mostrando ou escondendo os eventos internos do sistema, e assim por diante. A esta parte chamámos CHECK (verificação).

Essas três partes deliniam as três fases em que o sistema actua em funcionamento real, tal como pode ser visto no diagrama junto:

Primeiro um operador marca o trecho a ser detectado num cartucho, faixa de disco rígido ou MiniDisc. Alguém lançará o trecho marcado no ar posteriormente. O sistema detectá-lo-á e anotará a sua ocorrência num ficheiro do disco rígido do computador. Mais tarde, alguém irá recolher as bases de dados de criação e de ocorrência que o sistema criou e as analizará no écran.

No que respeita ao hardware, tivémos que entrar em sérios compromissos para conseguir resultados finais aceitáveis. O nosso sistema utiliza uma portadora cuja amplitude é digitalmente modulada. A modulação é feita com perfeito sincronismo com a passagem por zero do sinal da portadora, de modo que se esta for inaudível e situada no extremo grave o sinal modulado será também inaudível. De modo a conseguir uma rejeição aceitável das grandes variações de amplitude, fomos obrigados a aumentar a janela de tempo na qual é efectuada a detecção de cada bit do sinal, de modo a encaixar o tempo de equilíbrio de um filtro de portadora mais selectivo. Todavia, o aumento do tempo do sinal de marcação podia impedir-nos de detectar faixas muito curtas...

Do lado do firmware, o sistema utiliza uma trama estruturada, com sincronismo, contagem de bytes e soma de verificação. Cada byte transmitido utiliza detecção de paridade. Estas características resultam na possibilidade de efectuar detecção e correcção de erro, dado que o sistema consegue regenerar um byte perdido sabendo a sua localização e adivinhando o seu conteúdo através da soma de verificação.
A política seguida foi a de nunca mostrar uma leitura errada ao operador, permitindo ao mesmo tempo erros devidos ao desaparecimento de um byte completo (1 segundo).

O software de utilizador foi construído à volta de livrarias que tínhamos construído para o sistema de automatização WinAir, e caracteriza-se por uma interface de utilizador que usa sómente botões, como podem ver na cópia de écran incluída, de modo a evitar a confusão dos operadores não treinados. O programa de detecção é uma aplicação iconizada que trabalha mesmo quando o operador desce a uma sessão de DOS no seu PC. Para conseguir tal assegurando um funcionamento fiável mesmo sob Windows™ 3.11, tivémos de escrever extensões ao núcleo do Windows™ sob a forma de driver virtual de dispositivo, utilizando código de assembler de 32 bit. De facto, a maior parte do software faz apelo a código de 32-bit para acelerar os processos, quer se trate de manipulação de bases de dados, quer se trate de desenhar no écran.

O resultado final foi um sistema robusto e fácil de utilizar, o qual permite facilitar a vida aos rádiodifusores, e feito a partir de hardware pré-existente, o que permite melhorar a sua compatibilidade e diminuir o seu custo.