Monografia Tiny6410 - Patricia_Aliel

Universidade de São Paulo
Escola de Engenharia de São Carlos
Departamento de Engenharia Elétrica
Sistema de reconhecimento de áudio
Projeto em Sistemas Digitais
Alunos:
Aliel Kauchakje Pedrosa - 6813495
Patrcia Pires Otoni - 6911470
São Carlos
Julho / 2012
Resumo
Fez-se um estudo sistemático, durante todo o primeiro semestre letivo do ano de 2012, do kit Friendly
Arm Tiny 6410, que conta com processador ARM11. Tinha-se, por objetivo inicial, a implementação de um
programa de identificação de áudio, familiarização com a arquitetura ARM e as diferenças entre a mesma e a
arquitetura x86 e sistemas operacionais embarcados baseados em Linux.
Sumário
1 Sistemas Embarcados
5
2 ARM
6
3 Linux
8
3.1
A estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.1
BootLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.2
Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.3
Root filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
Distribuições
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4 Cross-compilação
11
5 Kit Tiny6410 - FriendlyArm
13
6 Apresentação do Projeto
14
6.1
Interação com o usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
6.2
Processamento e busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
6.3
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
7 Sistemas Operacionais
7.1
7.2
7.3
15
Qtopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
7.1.1
Instalação do Qtopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
7.1.2
Problemas com o Qtopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Endebian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
7.2.1
O dpkg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
7.2.2
O APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
7.2.3
Instalação do Emdebian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.2.4
Problemas com o Emdebian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
XUbuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.3.1
O Xubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.3.2
A instalação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1
8 Audio fingerprinting e aplicações
19
8.1
Geração da ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2
Primeira tentativa: OpenFP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2.1
O FFmpeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2.2
A biblioteca libfftw3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2.3
O processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.2.4
A impossibilidade de implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Echoprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3.1
O processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3.2
Branqueamento do sinal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3.3
Onset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
8.3
9 A interface WEB
23
10 Conclusão
25
A PHP utilizado no site
26
2
Lista de Figuras
3.1
Componentes principais de um sistema Linux embarcado . . . . . . . . . . . . . . . . . . . . . .
8
4.1
Janela do BuildRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
5.1
Foto da placa que constitui o kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
7.1
Imagem do Qtopia rodando na placa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
7.2
Imagem do XUbuntu rodando na placa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
9.1
Imagem do site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
9.2
Formulário de Upload do site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.3
Retorno da música identificada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3
Introdução
Motivados pelo atual desenvolvimento do mercado de equipamentos (ultra)portáteis, desperta-se, nos alunos de
engenharia, interesse por sistemas embarcados. O desenvolvimento de aplicativos para sistemas baseados em
arquiteturas não usualmente encontradas em computadores domésticos tem importância comercial significativa
e crescente. Com a idéia de se consolidar e adquirir conhecimentos em Linux embarcado e arquitetura ARM,
se um projeto de um reconhecedor de áudio com o uso do kit FriendlyArm Tiny 6410 foi proposto. Apesar da
aplicação em alto nı́vel, os desafios do projeto começam com a instalação do sistema operacional, situação na
qual os alunos responsáveis pelo projeto devem fazer compromissos e tomar decisões que influenciam em todo
desenvolvimento do mesmo.
4
Capı́tulo 1
Sistemas Embarcados
Sistemas embarcados podem ser definidos como sistemas desenvolvidos com foco em uma determinada atividade, assim o hardware e o software so fortemente acoplados.Assim, as aplicações de software so elaboradas
para a execução em hardwares especı́ficos.
Os sistemas embarcados so utilizados em diversas arquiteturas, cada uma focada em uma determinada
aplicação .
Por exemplo, tem-se os sistemas mais básicos com arquiteturas de 8 bits (pode-se citar PIC 12F,16F,18F
e o clássico 8051), os quais tem aplicações mais simples, como sensoriamento remoto, controle de máquinas de
lavar, dentre outros.
Dentre os de 16 bits, pode-se citar os MSP430 e os dsPIC. Tais dispositivos so utilizados em aplicações que
exigem um processamento matemático maior, como controle de sistemas mecânicos e industriais.
Por fim, tem-se os sistemas de arquiteturas 32 bits, os quais so mais complexos e se aproximam dos
computadores pessoais. O desenvolvimento para esta famı́lia de sistemas acaba acontecendo mais a nı́vel de
aplicação , e no a nı́vel baixo como os sistemas que envolvem programação de componentes de hardware. Os
dispositivos mais famosos so os ARM e MIPS.
5
Capı́tulo 2
ARM
ARM, acrônimo para Advanced RISC Machine, é uma arquitetura para processadores amplamente utilizada
para sistemas embarcados. Por conter um conjunto de instruções reduzido(RISC), processadores com tal
arquitetura apresentam menor consumo frente a processadores com conjunto de instruções CISC, vantagem
explorada nos diversos equipamentos portáteis como tocadores MP3, celulares e tablets, por exemplo.
A arquitetura ARM comeou como um projeto em 1983 na Arcon Computers de Cambridge, Inglaterra, para
desenvolver um processador que fosse similar ao já usasdo MOS Technology 6502. Esse projeto foi finalizado
e lanou-se ento a primeira verso em 1985, denominado ARM1.
O desenvolvimento continuou, e o nome original (Arcon RISC Machine) deixado de lado quando a ARM
Ltda. foi criada e assumiu as patentes e o desenvolvimento da arquitetura ARM. Atualmente a arquitetura já
conta com sua 11 verso, mas as verses antigas ainda so usadas e desenvolvidas, já que o uso de cada famı́lia é
voltado para uma área especı́fica de mercado.
Existem também várias extenses especializadas para alguma função ou processamento, como o Jazelle e o
Thumb.
As principais caracterı́sticas da arquitetura so:
• Processador de 32 bits;
• 16 registradores de uso geral;
• Conjunto de instruções extensı́vel com o uso de co-processadores;
• Instruções de três endereos;
• Capacidade de executar instruções de 16 bits usando a arquitetura Thumb;
• Baixo consumo de energia;
• Tamanho do núcleo reduzido;
• Arquitetura LOAD/STORE: Operações de processamento de dados no operam diretamente com o
conteúdo da memória, soment com o conteudo de registradores;
6
Portanto, a arquitetura ARM é implementada em mais de 75% dos processadores de 32 bits atuais principalmente devido sua versatilidade de uso em diversas aplicaoes práticas, pela boa performance que apresenta
e pela constante atualização de novas verses que so lanadas pela ARM.
7
Capı́tulo 3
Linux
O sistema Operacional Linux surgiu em 1991, escrito por Linus Torvalds, e desde então ele tem crescido cada
vez mais, aumentando assim sua popularidade entre os desenvolvedores e usuários do mundo todo. Isso se
deve principalmente ao fato dele possuir o código aberto, o que contribuiu para o aumento do suporte e apoio
de uma grande parte de desenvolvedores, que ajudaram no desenvolvimento do sistema, deixando-o com mais
funcionalidades e recursos. Assim, surgiu-se então o Linux Embarcado, extremamente útil para aplicações
especı́ficas em microcontroladores e o qual será abordado nos tópicos a seguir.
3.1
A estrutura
Um sistema Linux embarcado é composto basicamente por 3 componentes principais: BootLoader, Kernel e
Root filesystem, como mostrado na figura 5.1.
Figura 3.1: Componentes principais de um sistema Linux embarcado
3.1.1
BootLoader
Primeiramente, o BootLoader é o componente responsável por inicializar o hardware para a entrada e ação do
kernel. De forma geral, ele verifica os componentes de hardware presentes, inicia a memória RAM e carrega o
8
Kernel no devido endereo de memória, dando inı́cio a sua execução . Existem vários bootloaders, tanto para
dispositivos embarcados quanto para ambientes Linux em computadores e servidores, como o GRUB e LILO.
Um dos mais comuns e utilizados em sistemas embarcados é o U-Boot (Foi utilizado no projeto).
No kit utilizado, FriendlyARM Tiny6410, a empresa disponibilizou uma versão do U-Boot devidamente
configurado para a utilização na placa, a qual veio no DVD-A do kit, dentro da pasta Linux.
No entanto, o arquivo U-boot deve ser escolhido de acordo com a instalação do sistema que se quer executar.
Por exemplo, caso queira fazer uso do sistema instalado na memória NAND deve-se usar o arquivo(Deve-se
observar também a memória RAM, no caso do kit Tiny6410, pegou-se o arquivo para 256MB de RAM ). E,
da mesma forma, caso se queira rodar o sistema por meio do cartão de memória deve-se escolher o arquivo
apropriado.
Em ambos os casos,será gerado um arquivo chamado u-boot.bin, que deve ser carregado na placa através
do utilitário DNW, também disponibilizado no DVD-A do kit.
3.1.2
Kernel
Em seguida, na estrutura do Linux, está o Kernel, o qual é a base do Sistema Operacional. É ele quem gerencia
os dispositivos de hardware e a interação destes com os softwares em execução , ou seja, ele gerencia o acesso
à memória, ao disco, aos dispositivos do sistema, aos barramentos de comunicação , à CPU, aos recursos da
rede, dentre outras coisas mais.
A comunicação entre as aplicações de usuário e o Kernel é realizada por meio das System Calls (chamadas
ao sistema), que basicamente são uma série de funções que passam ao kernel as ações a serem executadas,
como leitura do disco-rı́gido, acesso a um endereo da memória, etc.
3.1.3
Root filesystem
O sistema de arquivos é o que cuida da leitura e escrita, é nele que ficam armazenados os softwares e demais
bibliotecas, arquivos e configurações do sistema e usuário. Root filesystem pode ser traduzido para o português
como sistema de arquivos raiz, que basicamente é o espao reservado para armazenamento de arquivos no
sistema.
Para o Linux existem quatro tipos principais de sistemas de arquivos: EXT3, JFFS2, YAFFS2 e UBI.
O root filesystem no Linux tem sempre a mesma estrutura de pastas, as quais seguem sempre um mesmo
padrão.
3.2
Distribuições
Por ser um sistema operacional de código aberto, o Linux possui várias distribuições , as quais consistem de
maneira geral na associação do Kernel com softwares de aplicação . Como exemplo de distribuições pode-se
citar:
Debian; Ubuntu; Fedora; Slackware; OpenSuse.
Como o Linux e a maior parte dos softwares incluı́dos em distribuições são livres, qualquer organização
ou indivı́duo suficientemente motivado podem criar e disponibilizar (comercialmente ou não) a sua própria
9
distribuição . Isso faz com que hoje haja registro de mais de 300 distribuições ativamente mantidas, embora
menos de 20 delas sejam largamente conhecidas. Pode-se obter uma lista atualizada e dividida em categorias
das distribuições de Linux no site [1] .
Todas as distribuições tem suas vantagens e desvantagens, a escolha dependerá das necessidades a serem
exigidas para a aplicação . No entanto, deve-se atentar a alguns pontos ao se escolher, como verificar se a
versão é muito antiga, se suporta todo o hardware, se inclui os pacotes necessários, dentre outros.
Para saber as caracterı́sticas de cada uma, pode-se pesquisar nos artigos do BR-Linux [2], ou consultar os
sites de cada uma dela.
10
Capı́tulo 4
Cross-compilação
Cross compilação consiste em compilar um pacote para uma arquitetura especı́fica (No caso do projeto, a ARM)
utilizando uma outra arquitetura para a compilação , para isso é necessário um cross-compilador. Utilizou-se
ento o BuildRoot.
Para fazer uso do BuildRoot, basta baixar o pacote da verso mais recente no site [3], descompactá-lo em
uma pasta de preferência e, dentro desta pasta digitar o comando:
make menuconfig
Após digitar esse comando aparecerá a janela mostrada na figura 4.1:
Figura 4.1: Janela do BuildRoot
Cada item do menu é responsável por uma configuração especı́fica. Assim deve-se escolher a arquitetura
para a qual deseja compilar na opção Target Architecture. A Tarchet Architecture Variant é responsável por
escolher a famı́lia de processadores especı́ficas dentro da arquitetura selecionada. A próxima opção , Target
ABI, seleciona a interface de aplicação binária a ser usada no projeto, para sistemas embarcados usa-se EABI.
Em Packages Selection for the target é onde se escolhe os pacotes a serem compilados. De maneira geral,
11
tais pacotes esto no BuildRoot para serem adicionados na compilação do Linux a ser executada. No entanto,
no projeto o BuildRoot foi utilizado apenas para compilar tais pacotes e no o Linux inteiro, uma vez que de
inicio a distribuição escolhida no apresentava os aplicativos necessários para a execução do projeto.
Ao sair do cross compilador, um arquivo .config é criado com as configurações salvas para compilação . E
ento, digita-se o comando make para iniciar a compilação .
Como interessava apenas os pacotes adicionais compilados, uma opção no BuildRoot, denominada Enable
compiler cache foi marcada para que na próxima vez que se executasse o make apenas os pacotes que ainda
não foram compilados deveriam ser compilados, o que causou uma diminuição de tempo enorme no processo
de cross-crompilação . Tal opção encontra-se dentro de Build options.
Após concluı́do, os arquivos compilados encontravam-se dentro da mesma pasta descompactada do BuildRoot, porém dentro da pasta output/target. Assim, caso no se tenha escolhido uma imagem de sistema
de arquivos a ser compilada, será gerada uma cópia contendo todos os diretórios do sistema Linux (listados
acima), e, dentro de seus respectivos diretórios estaro os arquivos dos pacotes compilados.
12
Capı́tulo 5
Kit Tiny6410 - FriendlyArm
O kit Tiny 6410, fabricado pela chinesa FriendlyArm, foi utilizado para desenvolvimento do projeto. O kit
conta com um processador Samsung S3C6410 ARM11 de 533MHz, 256MB de memória RAM e Flash de 1GB.
A placa de desenvolvimento possui entradas USB, 4 portas serial DB9, saı́da e entrada de áudio, saı́da para
TV, porta Ethernet, um display 4,3 TouchScreen resistivo e diversos outros dispositivos detalhados no manual
de instruções que acompanha o kit e também disponı́vel na internet.
Dois DVDs acompanham o kit com manuais em inglês, softwares para auxı́lio na instalação do sistema
operacional e quatro opções de sistemas operacionais a se instalar: Windows CE, Android, Linux e XUbuntu.
Figura 5.1: Foto da placa que constitui o kit
13
Capı́tulo 6
Apresentação do Projeto
Almejou-se, como objetivo da disciplina, o projeto de um identificador musical. O identificador musical é
particionado na parte interativa com o usuário e na parte de processamento e busca de dados.
6.1
Interação com o usuário
Essa etapa tem como principal elemento uma webpage, construda em PHP, e um aplicativo Java. Se o
usuário deseja identificar uma música, este deve clicar no botão adequado na página, que o redireciona para
um aplicativo construdo em Java onde existem opções para gravação de um trecho da música que se deseja
identificar. Após a gravação do trecho escolhido um arquivo Wave é criado com os dados do áudio digitalizado,
clica-se em um botão Enviar e o áudio gravado é então enviado ao servidor, localizado na placa. Após rotinas de
processamento e busca, informações pertinentes música, como artista, nome da faixa e álbum são retornadas
ao usuário.
6.2
Processamento e busca
Para que possa ser identificado, o arquivo Wave passa por uma etapa de processamento através de um software
que roda na placa. Com os dados obtidos pode-se então fazer a busca das informações pertinentes, localizadas
num banco de dados existente na internet. Detalhes sobre o processo de processamento e busca serão fornecidos
nas seções próximas.
6.3
Implementação
Os próximos capı́tulos detalharão todo o processo do projeto, desde a instalação e escolha de um sistema
operacional adequado à aplicação final.
14
Capı́tulo 7
Sistemas Operacionais
7.1
Qtopia
Qtopia era o nome dado à plataforma de aplicações em Linux embarcado mantida por uma subsidiária da
Nokia. Sua última versão, 4.4.3, foi lançada em 2009, tendo antes sido utilizada comercialmente em alguns
poucos celulares e ”hand-helds”.
Anexada pela FriendlyArm em versão 2.2.0 ao CD do kit que compões a placa, a distribuição se mostrou de
uso relativamente fácil, uma vez que conta com uma interface intuitiva, com recursos já integrados(como player
de aúdio e vı́deo, aplicativos com compatibilidade com a câmera, módulo GSM, Bluetooth, Wi-Fi, acesso ao
conversor A/D, LEDs e Buzzer, por exemplo) e uma ampla gama de exemplos de utilização com a placa para
aplicações voltados para controle do Hardware que compõe a placa.
Devido à facilidade de uso, extremamente intuitivo, o Qtopia foi o primeiro sistema a ser instalado e testado.
Figura 7.1: Imagem do Qtopia rodando na placa
7.1.1
Instalação do Qtopia
Um roteiro para instalação do Qtopia se encontra no Manual de Instalação que acompanha o kit.
7.1.2
Problemas com o Qtopia
Com a distribuição descontinuada, o repositório de pacotes disponı́veis para o Qtopia deixou de existir, limitando assim o desenvolvimento de aplicações na placa àquelas utilizando apenas os pacotes já pré-existentes.
Assim, ao se compilar os pacotes necessários com a utilizao do BuildRoot e ao transferı́-los os para o
kit, percebeu-se que os mesmos não se comportavam muito bem devido a configurações exigidas no ato da
15
instalação , e que não foram realizadas pelo fato de não terem sido instalados, e sim, ?implantados?. Como
exemplo, tem-se o SSH (Secure SHELL), o qual não foi possı́vel configurá-lo corretamente para possibilitar
o acesso remoto. Caso a ferramenta APT (Advanced Packaging Tool) estivesse instalada este problema não
ocorreria, uma vez que ela mesma faz realiza as configuraes necessárias. Dessa forma, tentou-se também
compilar o APT , o que também não foi possv́el frente a falta de informações para os ajustes necessários da
ferramenta.
Portanto, optou-se por escolher outra distribuição .
7.2
Endebian
O Emdebian - Embedded Debian uma distribuição Linux similar ao Debian, mas com recursos e tamanho
ajustado para soluções embarcadas, onde a disponibilidade de memória e armazenamento é limitada e crı́tica.
Uma grande vantagem frente a outras distribuições é a possibilidade do uso de pacotes pré instalados
advindos do Debian.
Após o problema com o Qtopia optou-se pelo Emdebian principalmente pela possibildiade do gerenciamento
de pacotes dpkg e método de atuazação APT e pela confiabilidade da distribuição e garantia de atualizações
constantes.
7.2.1
O dpkg
O dpkg é o software base encontrado no Debian para gerenciamento de pacotes, sendo usado então para
instalação , desistalação e obtenção de informações pelos pacotes utilizados no Debian. Baseado em C, C++ e
Pearl, o dpkg é pouco utilizado diretamente, sendo ferramentas de mais alto nı́vel como APT e aptitude mais
utilizadas.
7.2.2
O APT
O APT, acrnimo para ”Advanced Packaging Tool”, é uma interface que permite a administração de pacotes em
diversos sistemas, incluindo o Debian. Trabalhando com os principais pacotes responsáveis pela manipulação
de pacotes, o APT facilita a instalação e configuração dos pacotes, fazendo com que o processo seja feito de
forma automática e por vezes invisı́vel ao usuário.
Inicialmente o APT foi desenvolvido para trabalhar como uma plataforma de interação do usuário com o
dpkg para gerencialmento de pacotes no Debian, entretanto, após crescida popularidade, o APT foi portado
para outros sistemas baseados em Linux e ainda para o sistema MAC OS X.
Instalação de pacotes com o APT
Para exemplificar o uso do APT e evidenciar sua utilidade pode-se dar o exemplo de instalação de um pacote
como o FFmpeg, utilizado pelo programa OpenFP que será visto na seção sobre Audio Fingerprints”. Para a
instalação do FFmpeg basta que se digite na linha de comando: $ sudo apt-get install FFmpeg
O pacote é então instalado e configurado convenientemente.
16
7.2.3
Instalação do Emdebian
A instalação do Emdebian para a placa FriendlyArm Mini6410, similar à utilizada no projeto, é documentada
e pode ser encontrada em: http://code.google.com/p/mini6410-debian/wiki/Tutorial.
Seguiu-se, passo a passo, as instruções para instalação do sistema que consistem em criar o sistema de
arquivos, preparar o cartão SD, copiar o sistema de arquivos, compilar o kernel e o u-boot, preparar outro
cartão de memória que conterá o kernel e o bootloader e assim, após todos os passos, proceder com o boot.
7.2.4
Problemas com o Emdebian
A maior atrativo oferecido pelo Emdebian frente ao Qtopia seria o controle e manejo facilitado de pacotes.
Houve, entretanto, uma falha no dpkg que não foi consertada mesmo em diversas tentativas. Optou-se então
por se testar mais uma distribuição , uma vez que o maior atravivo desta era impraticável.
7.3
7.3.1
XUbuntu
O Xubuntu
Normalmente utilizado com interface gráfica GNOME, a distribuição Ubuntu é a mais utilizada em computadores pessoais. Com cerca de 800Mb em sua versão mais atual, a distribuição se mostra inadequada para os
rescursos limitados da placa FriendlyArm Tiny 6410.
O Xubuntu é uma distribuição derivada do Ubuntu com interface XFCE e com funcionalidades limitadas
frente ao Ubuntu. Devido ao seu tamanho diminuto e pouco consumo de memória RAM necessário, a distribuição é adequada para certas aplicações embarcadas e é recomendada pela FriendlyArm, que a disponibiliza
em CDs junto com a placa.
Para o projeto escolheu-se o Xubuntu por suas similaridades com o Ubuntu e, principalmente, pelas facilidades trazidas pelo gereciamento de pacotes APT e método de atualização dpkg.
A interface gráfica, embora presente, foi de pouca importância para o projeto, uma vez que todo o uso da
placa era feito remotamente através de SSH.
Figura 7.2: Imagem do XUbuntu rodando na placa
7.3.2
A instalação
Como as outras distribuições recomendadas pela FriendlyArm para a placa utilizada, o Xubuntu pode ser
instalado na NAND Flash ou rodar diretamente do cartão SD.
17
Rodando o Xubuntu do cartão SD
Para se rodar o sistema através do cartão SD deve-se, primeiramente, gravar o Superboot no cartão através
do utilitário ”SD − F lasher.exe”. Feito isso, deve-se copiar a pasta de imagem, onde se localizam o arquivo
”uzImage”, que é a imagem do kernel, e o arquivo ”rootf s ubuntu.ext3”, que é a imagem do sistema de
arquivos EXT3, contida no CD para o cartão e em seguida modifica-se o arquivo ”images/F riendlyARM.ini
e altera-se os parâmetros ”Action = Run”, que habilita a execução pelo cartão, e ”OS = Ubuntu”. Seleciona-se
na placa a opção SDBOOT e insere-se o cartão preparado.
Gravando O Xubuntu na NAND
O procedimento é o mesmo para os outros sistemas operacionais e é descrito no manual que acompanha o kit.
18
Capı́tulo 8
Audio fingerprinting e aplicações
Dá-se o nome de ”Audio fingerprinting”ou ”Acoustic fingerprinting” geração determinı́stica de um conjunto
resumido de parâmetros obtidos de uma amostra de sinal de aúdio, a impressão digital do sinal, que podem
ser utilizados para a identificação do sinal original.
Para a geração da impressão digital de um sinal procura-se, diferentemente de analizadores de áudio
digital, fazer com que o sistema utilizado obtenha dados relevantes sensação fisiológica que resulta o sinal
e não apenas uma comparação binária. Não se faz importante então o formato da música, seja ele ”.wav”,
”.mp3”ou qualquer outro, a impressão digital gerada deve ser similar para um mesmo sinal de áudio, uma vez
que, para um humano, se escutaria a mesma música independentemente do formato.
O sistema de geração de impressão digital deve ainda ser robusto quanto a pequenas flutuações de intensidade sinal-ruı́do, ruı́dos externos ao sinal, variações de tonalidade, de volume e tempo. Como exemplo pode-se
supor um experimento onde um humano escuta uma música num ambiente silencioso e após escuta o som
num bar, com ruı́dos de conversa, ventiladores, copos e distorções inerentes ao sistema de som instalado, mas
mesmo assim pode-se reconhecer a canção tocada. Um sistema de geração de impressão digital de áudio deve,
idealmente, funcionar como o humano que liga o nome da canção a ela indendente das adversidades, em nı́veis
razoáveis, impostas.
O sistema pode ser separado em algumas partes, sendo a primeira a obtenção e digitalização do sinal:
determina-se qual o tamanho da amostra necessária para que uma impressão digital (ID) seja satisfatoriamente
gerada. Uma ID é satisfatoriamente gerada se os dados nela contidos podem ser utilizados para a identificação
atraves da ID do sinal original. O sinal ser obtido ”over the air”, quando o sinal é proveniente de um microfone
ou outro transdutor e imeditamente faz-se o processamento e busca no banco de dados, ou pode-se fazer um
sistema que compara sinais antes digitalizados, não havendo necessidade de um sistema que trabalhe com a
velocidade do anterior. Para sistemas ”over the air”se exige grande robustez, velocidade de processamento e
ainda que a amostra necessária não seja demasiado grande.
A segunda etapa é o processamento do sinal e análise para se gerar o ID, onde diversas abordagens podem ser
utilizadas, pode-se utilizar transformadas para análise em frequência, bancos de filtros, transformadas Wavelet
para análise em frequência e tempo, pode-se fazer análise de entropia, energia, técnicas de visão computacional
e diversos outros métodos, todos ainda em estudo. Na próxima seção serão descritos os sistemas testados e o
implementado.
19
A última etapa consiste em tomar o ID obtido e compará-lo a um banco de dados com IDs previamente
selecionadas associadas aos dados relevantes que se deseja reaver.
Deve-se lembrar, novamente e enfaticamente, que o sistema não é uma busca por ”meta-tags”ou comparação
bit a bit de dados de áudio digitalizado: o sistema de impressão digital de áudio tenta fazer com que o
computador ”escute”, tomando tão quanto possı́vel parâmetros fisiológicos da audição, os sinais e os possa
associar.
Diversas aplicações podem derivar de um sistema de ”Acoustic fingerprint”: de deduplicadores de ”playlists”, checagem de utilização de canções com copyright, separação de músicas em uma ”playlist”desorganizada
por artista ou estilo, ou simplesmente a curiosidade ao se escutar uma música que não se conhece.
8.1
Geração da ID
Inicialmente desejava-se programar um software capaz de, através da análise de alguns parâmetros obtidos
através da amostra, se criar uma impressão digital de forma robusta e rápida. Tal tarefa se mostrou, entretanto,
árdua e, devido ao pouco tempo disponı́vel para a realização total do projeto optou-se pela implementação
de um gerador de impressão digital open source já disponı́vel. Duas soluções foram testadas, sendo uma
delas efetiva. Ambas serão analizadas, uma vez que possuem abordagens distintas para o mesmo problema e
fornecem dados e ferramentas importantes para uma possı́vel futura implementação autoral.
8.2
Primeira tentativa: OpenFP
O software OpenFP é uma solução para a criação de impressões digitais de áudio e comparação da mesma em
um banco de dados open source, baseado em C e Python, que utiliza como ferramentas principais o software
FFmpeg e a biblioteca para C libfftw3.
8.2.1
O FFmpeg
O FFmpeg é um software de licença GNU e construı́do em C para manipulação e execução de dados multimı́dea
em quase todos os formatos corriqueiramente utilizados. O FFmpeg tem multifuncionalidades, incluindo
conversor de formatos de vı́deo, servidor multimı́dea para apresentações ao vivo, rotinas para manipulação de
dados de áudio e vı́deo, dentre muitas outras funcionalidades que o fazem ser utilizados em uma infinidade de
projetos, notadamente: Facebook, YouTube, VLC, MPlayer.
8.2.2
A biblioteca libfftw3
Desenvolvida no MIT pelos engenheiros Matteo Frigo e Steven G. Johnson, FFTW é acrônimo para Fast
Fourier Transform in the West, e é uma biblioteca C para o cálculo da transformada discreta de Fourier(TDF)
em uma ou mais dimensões, para dados reais ou complexos. é uma opção bem documentada para aplicações
que exijam o cálculo da TDF e manipulações extensas de sinais em linguagem C.
20
8.2.3
O processamento
Numa primeira etapa o áudio é recebido e interpretado com auxı́lio do FFmpeg, faz-se então necessário que
o áudio de entrada esteja salvo em um dos formatos reconhecidos por este programa. Após interpretação
do arquivo de áudio é feito um janelamento e em seguida faz a TDF do sinal, com auxı́lio da libfftw3, para
criação de seu espectro de potência. O espectro de potência é então reduzido a banda de potência relevantes
e em seguida o sinal passa por um filtro passa-baixas para eliminação de ruı́do. O sinal é então quantizado,
impondo um valor zero ou um para uma banda comparando-se o valor de sua energia com um limiar. A
sequência binária resultante é a impressão digital principal. Para uma busca mais rápida em um banco de
dados extenso, faz-se ainda uma ID secundária. Para tanto faz-se uma análise cepstral(mel-cepstrum) do sinal,
que é uma representação curta do espectro de potência do som.
Os dados, agora binários da ID e ID secundária são comparadas com outras IDs num banco de dados,
permitindo a recuperação dos dados do sinal.
8.2.4
A impossibilidade de implementação
O programa apresentava uma função para busca no banco de dados que se esperava estar disponivel na internet,
entretanto, provavelmente por falta de atualização, o repositório estava indisponı́vel, inviabilizando o projeto.
Os criadores doprograma foram contatados, mas não houve resposta. Partiu-se então em busca de uma nova
aplicação que atendesse os requisitos do projeto.
8.3
Echoprint
O Echoprint é um sistema open source de identificação de audio, que permite que aplicativos que exijam o
uso de assinaturas de áudio sejam implementados com facilidade. O sistema Echoprint é robusto e possui
funcionalidade ”over the air”. Seu banco de dados é composto por um arquivo com cerca de 130000 músicas
listadas.
8.3.1
O processamento
Assim como o OpenFP, o Echoprint aceita como entrada diversos formatos de áudio. O áudio é então tratado
em etapas.
8.3.2
Branqueamento do sinal
O branqueamento por sinal tem por fim tornar o sinal com suas componentes descorrelacionadas e variância
unitária. Para o branqueamento aplica-se uma transformação linear inversı́vel de forma que as obsrvações tenham matriz de covariância identidade. Pode-se demonstrar ainda que o branqueamento reduz a complexidade
do problema. O sinal é, em seguida, decomposto em subbandas e segue-se para a detecção de onset.
21
8.3.3
Onset
Define-se onset como o começo de um som, como por exemplo, uma nota musical, onde a amplitude do sinal
vai de zero até um primeiro pico.
O conceito de onset não deve ser confundido com o de transiente ou ataque de uma nota. Os três conceitos,
apesar de correlatos, são distintos e possuem também aplicações distintas.
O ataque de uma nota é o intervalo de tempo onde a amplitude do envelope cresce. O transiente, por sua
vez, é mais dificilmente definido: informalmente pode-se definir o transiente como um perı́odo onde o sinal
evolui de forma não-trivial. Em instrumentos acústicos o transiente é equivalente ao perı́odo de duração do
decaimento do sinal do sistema quando excitado por um impulso. O onset coincide, dadas as definições , em
grande parte dos sinais com o inı́cio do transiente.
Detecção de onset
Obtenção de algoritmos para detecção de onset é uma área prolı́fica de pesquisa. Diversos métodos para
análise vem sendo estudados, desde análise de Fourier análises em multiresolução, com informações no tempo
e frequência.
O caso mais realı́stico que se pode considerar numa análise para detecção de onset é o caso em que se tem
sinais polifônicos, onde diversas fontes sonoras interferem, positivamente, uma com as outras. Sendo sinais
de áudio aditivos e oscilatórios, não se pode enxergar mudanças a partir do sinal original no tempo. Faz-se
necessário o uso de sinais intermediários que revelem uma estrutura local do sinal original, este sinal é chamado
de sinal de detecção. O estudo das funções de detecção fogem do escopo do trabalho e podem ser encontrados
em J.P. Bello et al..
Deteção de onset modificada
Para detecção de onset no Echoprint utiliza-se a mesma idéia de detectores de onset padrão, entretanto, para
melhores resultados e aumento de robustez divide-se o espectro em oito bandas distintas.
A magnitude do sinal em cada banda é comparada com um limiar exponencialmente descrescente e um
onset é gravado quando o sinal excede tal limiar e a amplitude de tal limiar é então aumentada em 1.05 vezes.
Um algoritmo adaptativo regula o limiar e aumenta ainda mais a robustez de detecção dos onsets.
Uma descrição precisa do sistema de detecção , filtros e ainda sistema de busca utilizado no Echoprint foi
publicada por seus autores em um White Paper que pode ser encontrado nas referências.
22
Capı́tulo 9
A interface WEB
Para a construção da interface WEB utilizou-se a linguagem PHP, a qual foi escolhida pela experiência de um
dos membros do grupo, e também pela praticidade e facilidade de manipulação da mesma. Dessa forma, foi
criada uma página bem simples, a qual tem dois botões: o primeiro que de ideia inicial seria um aplicativo em
Java para gravar o áudio no computador do cliente e enviá-lo ao servidor, e o segundo no qual o programa de
reconhecimento da musica é executado e as informações da mesma são retornadas.
Assim, no decorrer do projeto, tentou-se de várias formas implementar o aplicativo Java para a gravação
no áudio, nesse caso é chamado de Applet, visto que rodaria somente no browser. No entanto, descobriu-se
que a ação de gravar algo pelo browser do computador do cliente é proibido nas leis da internet, e assim a
linguagem Java bloqueia a execução de tal aplicativo. Para que seja permitida a gravação , o aplicativo deveria
ser registrado, o que causaria um certo custo. E o grupo optou por não fazê-lo.
A saı́da encontrada pela dupla para tal problema foi a de realizar apenas o upload do arquivo para o
servidor, que nesse caso é o kit Tiny6410. Para isso, utilizou-se também da linguagem PHP para implementar
um formulário de upload, onde o usuário deve enviar a musica no formato .wav e com o nome de mus.
No entanto, o formulário para upload mostrou-se uma limitação quanto ao tamanho do arquivo a ser
enviado ao servidor. Dessa forma, não se pode enviar um arquivo de tamanho maior que 2Mb. Pela ausência
de tempo este problema não pode ser corrigido, porém acredita-se que ele seja facilmente resolvido.
É importante ressaltar que o site apenas faz a interação do usuário com o servidor, uma vez que o programa
de reconhecimento de áudio é executado no servidor e apenas retorna as informações na interface web. Os
arquivos em PHP de toda a interface estão no Apêndice 2. As figuras mostram a tela principal do site, o
formulário de upload do arquivo e as informações retornadas pelo servidor, respectivamente.
23
Figura 9.1: Imagem do site
Figura 9.2: Formulário de Upload do site
Figura 9.3: Retorno da música identificada
24
Capı́tulo 10
Conclusão
O projeto desenvolvido no laboratório foi um primeiro contato com o processador ARM11 e uma introdução
aos sistemas embarcados. Embora encarado com dificuldades, o projeto foi efetivo e, em cada erro e tropeço
um novo conceito foi consolidado. Muito embora o cronograma inicial não tenha sido cumprido com rigor,
todas as tarefas foram cumpridas, não obstante tempo extra de trabalho, além das quatro horas semanais,
fora dispensado.
A aplicação desenvolvida tem apelo comercial elevado e cientı́fico notável: integrou-se, num só projeto,
sistemas embarcados, programação e processamento de sinais, conceitos não triviais de tais domı́nios foram
essenciais para a compreensão dos problemas e surgimento de soluções .
O desenvolvimento do projeto e conclusão do mesmo despertou no grupo grande interesse por sistemas
embarcados e sistemas baseados em Linux, de forma se abriram novas portas e um novo caminho, seja para
mercado ou academia.
25
Apêndice A
PHP utilizado no site
home.php
<!−−
To c h a n g e
and open
this
the
template ,
template
in
choose
the
Tools
|
Templates
editor .
−−>
<!DOCTYPE HTML PUBLIC ”−//W3C//DTD HTML 4 . 0 1
T r a n s i t i o n a l //EN”>
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
c h a r s e t=UTF−8”>
< t i t l e ></ t i t l e >
</head>
<body BACKGROUND=” l i n u x 0 2 A . j p g ”>
<?php
echo
’ <br><br> <br><c e n t e r ><a
<br><br><br><br></f o n t ><a
h r e f =” a u d i o f p . php ”
h r e f =” e c h o p r i n t . php ”
t a r g e t =” p r i n c i p a l ”><img
t a r g e t =” p r i n c i p a l ”><img
s r c = ” b t n 0 2 . png”</ c e n t e r ></a>
s r c = ” b t n 0 1 . png”</a>
’;
?>
</body>
</html>
topo.php
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
c h a r s e t=i s o −8859−1” />
</head>
<body BGCOLOR= ”#363636”” >
<f o n t
s i z e =”8”
f a c e =”Verdana ”
c o l o r =” w h i t e”><c e n t e r ><s t r o n g > F r i e n d l y A r m
<f o n t
s i z e =”6”
f a c e =”Verdana ”
c o l o r =”#C6E2FF”><c e n t e r ><s t r o n g > Audio
Tiny 6410 </ s t r o n g ></c e n t e r > </ f o n t >
F i n g e r P r i n t </ s t r o n g ></c e n t e r > </ f o n t >
</body>
</html>
esquerda.php
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
c h a r s e t=UTF−8”>
< t i t l e ></ t i t l e >
</head>
<body
b g c o l o r =”#696969”
l i n k =”#00008B”
v i n k =”#696969”
a l i n k =”#FFFFFF”>
<?php
echo
’ <f o n t
s i z e =”4”
f a c e =”Verdana ”
c o l o r =”#C6E2FF”><c e n t e r >Menu</ c e n t e r ></f o n t >
26
<br><a
h r e f =”home . php ”
t a r g e t =” p r i n c i p a l ”>Home</a>
<HR s i z e =5 ALIGN=LEFT>
’;
//#C6E2FF
//#9C9C9C
?>
</body>
</html>
topo.php
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
c h a r s e t=i s o −8859−1” />
</head>
<body BGCOLOR= ”#363636”” >
<f o n t
s i z e =”8”
f a c e =”Verdana ”
c o l o r =” w h i t e”><c e n t e r ><s t r o n g > F r i e n d l y A r m
<f o n t
s i z e =”6”
f a c e =”Verdana ”
c o l o r =”#C6E2FF”><c e n t e r ><s t r o n g > Audio
Tiny 6410 </ s t r o n g ></c e n t e r > </ f o n t >
F i n g e r P r i n t </ s t r o n g ></c e n t e r > </ f o n t >
</body>
</html>
uploader.php
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
c h a r s e t=UTF−8”>
< t i t l e ></ t i t l e >
</head>
<body BACKGROUND=” l i n u x 0 2 A . j p g ”>
<?php
$ t a r g e t p a t h = ”/ v a r /www/ ” ;
$target path = $target path
.
basename (
$ FILES [ ’ u p l o a d e d f i l e ’ ] [ ’ name ’ ] ) ;
i f ( m o v e u p l o a d e d f i l e ( $ FILES [ ’ u p l o a d e d f i l e ’ ] [ ’ tmp name ’ ] ,
echo
”
}
” The
has
been
file
”.
basename (
$target path ))
$ FILES [ ’ u p l o a d e d f i l e ’ ] [ ’ name ’ ] ) .
uploaded ” ;
else{
echo
” T h e r e was an
error
uploading
the
file ,
please
try
again ! ” ;
}
?>
</body>
</html>
audiofp.php
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
< t i t l e ></ t i t l e >
<s t y l e
t y p e =” t e x t / c s s ”>
d i v . quad1
{
w i d t h : 4 0 0 px ;
p a d d i n g : 1 0 px ;
b o r d e r : 3 px
solid
black ;
m a r g i n : 1 0 px ;
}
d i v . quad
{
w i d t h : 2 0 0 px ;
p a d d i n g : 1 0 px ;
b o r d e r : 3 px
solid
black ;
m a r g i n : 1 0 px ;
}
</ s t y l e >
27
c h a r s e t=UTF−8”>
{
</head>
<body BACKGROUND=” l i n u x 0 2 A . j p g ”>
<c e n t e r ><f o r m
<i n p u t
e n c t y p e =” m u l t i p a r t / form−d a t a ”
t y p e =” h i d d e n ” name=”MAX FILE SIZE”
<br><c e n t e r ><d i v
<c e n t e r ><d i v
c l a s s = ” quad1”>< f o n t
c l a s s = ” quad1”>< f o n t
<br><c e n t e r ><d i v
<i n p u t
s i z e =”3”
s i z e =”3”
c l a s s = ” quad1”>< f o n t
t y p e =”s u b m i t ”
a c t i o n =” u p l o a d e r . php ” method=”POST”>
v a l u e = ” 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ” />
v a l u e =”Upload
f a c e =”Verdana ,
f a c e =”Verdana ,
s i z e =”3”
A r i a l ”> <c e n t e r >O nome do
A r i a l ”> <c e n t e r >O a r q u i v o
f a c e =”Verdana ,
deve
arquivo
dever
ser :
mus. </ c e n t
e s t a r em f o r m a t o wav. </ c e n t e r >
A r i a l ”><i n p u t name=” u p l o a d e d f i l e ”
t y p e =” f i l e ” /><b r />
F i l e ” /></ f o n t ></d i v ></c e n t e r ><br>
</form></c e n t e r >
<!−−<br><br><c e n t e r ><a p p l e t
code = ” AudioApplet . c l a s s ” width = ”450”
h e i g h t = ”230” > </ a p p l e t ></c e n t e r >−−>
</body>
</html>
echoprint.php
<html>
<head>
<meta h t t p−e q u i v =”Content−Type ”
c o n t e n t =” t e x t / html ;
c h a r s e t=UTF−8”>
< t i t l e ></ t i t l e >
<s t y l e
t y p e =” t e x t / c s s ”>
d i v . quad
{
w i d t h : 2 0 0 px ;
p a d d i n g : 1 0 px ;
b o r d e r : 3 px
solid
black ;
m a r g i n : 1 0 px ;
}
</ s t y l e >
</head>
<body BACKGROUND=” l i n u x 0 2 A . j p g ”>
<?php
s h e l l e x e c ( ’ . / e c h o p r i n t −c o d e g e n
E v e r b l a . wav 30 60 >t e s t e ’ ) ;
$ r e s = s h e l l e x e c ( ’ c u r l −F ” q u e r y=@ t e s t e ”
f i l e p u t c o n t e n t s (” r e s . txt ” ,
$music = s h e l l e x e c (” grep
h t t p : / / d e v e l o p e r . e c h o n e s t . com/ a p i / v4 / s o n g / i d e n t i f y ? a p i k e y =026LJ5LL1TJYWIDMY ’ ) ;
” $res ”);
’ t i t l e ’ −r
res . txt ”);
$ p o s t i t l e B e g i n = s t r r p o s ( $music , ” t i t l e ” ) ;
$ p o s t i t l e E n d = s t r r p o s ( $music , ” message ” ) ;
$ t i t l e = s u b s t r (” $music ” , $ p o s t i t l e B e g i n + 9 ,
$postitleEnd − $postitleBegin − 13;
$ p o s a r t i s t B e g i n = s t r r p o s ( $music , ” a r t i s t n a m e ” ) ;
$ p o s a r t i s t E n d = s t r r p o s ( $music , ” i d ” ) ;
$ a r t i s t = s u b s t r (” $music ” , $ p o s a r t i s t B e g i n + 15 ,
// e c h o
e c h o ’< br><c e n t e r ><d i v
<br><br><c e n t e r ><d i v
$posartistEnd − $posartistBegin − 19);
$res ;
c l a s s = ” quad”>< f o n t
c l a s s = ” quad”>< f o n t
s i z e =”3”
s i z e =”3”
f a c e =”Verdana ,
f a c e =”Verdana ,
?>
</body>
</html>
28
A r i a l ”> <c e n t e r > ’ . $ t i t l e . ’ </ c e n t e r ></f o n t ></d i v ></c e n t e r >
A r i a l <c e n t e r > ’ . $ a r t i s t . ’ </ c e n t e r ></f o n t ></d i v ></c e n t e r >’
Referências
[1] LWN.net
[2] Br-Linux - www.brlinux.net
[3] Built Root - http://buildroot.uclibc.org/
[4] Echoprint - echoprint.me
[5] D. Ellis, B. Whitman, A. Porter, ECHOPRINT - AN OPEN MUSIC IDENTIFICATION SERVICE,
ISMIR 2011
[6] J. Bello, L. Daudet, S. Abdallah, C. Duxbury, M. Davies, M. Sandler, A Tutorial on Onset Detection
in Music Signals, IEEE Transactions on speech and audio processing
[7] http://code.google.com/p/mini6410-debian/wiki/Tutorial
[8] Manual FriendlyArm Tiny6410
[9] G. Leitão, Separação de fontes de sinais de áudio, 2009
[10] MusicBrainz - The Open Music Encyclopedia, musicbrainz.org
[11] OpenFP - open-fp.sourceforge.net
[12] J. Haitsma, T. Kalker, A Highly Robust Audio Fingerprinting System
[13] Cheng Y., Music Database Retrieval Based on Spectral Similarity, International Symposium on Music
Information Retrieval (ISMIR) 2001, Bloomington, USA, October 2001
29