MuVis: Localização e Visualização de Músicas

Ricardo José São Pedro Dias

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Júri

Presidente: Doutor Joaquim Armando Pires Jorge

Orientador: Doutor Manuel João Caneira Monteiro da Fonseca

Vogais: Doutor David Manuel Martins de Matos

Outubro 2009

Resumo

Com o crescimento e consumo acelerado de música em formato digital, surge a ne-cessidade de novas soluções para visualizar e explorar estas bibliotecas.

Actualmente, as soluções existentes para explorar colecções musicais têm um con-junto de limitações, que se tornam mais evidentes com este crescimento. Entre os prin-cipais condicionalismos podemos destacar: a não utilização da informação do conteúdomusical; não permitirem compreender a organização da colecção; e a criação de playlists

ser apenas baseada em metadados (tags).Com este trabalho pretendemos desenvolver uma solução que efectivamente colmate

as limitações relativas à não utilização de informação do conteúdo musical (para pesquisa,filtragem, visualização, etc.) e à compreensão de colecções de grandes dimensões. Paraatingir estes objectivos desenvolvemos uma solução que combina três componentes: téc-nicas de visualização de informação, técnicas de recuperação de informação musical efiltragem dinâmica, para oferecer aos utilizadores uma solução eficiente, flexível e fácilde usar, na exploração interactiva de colecções musicais.

Os principais resultados experimentais indicam que a nossa aplicação é mais fácil deutilizar que outros sistemas, e permite uma navegação rápida e eficaz onde os utilizadoresapresentam uma maior compreensão das colecções musicais. Os benefícios da combina-ção de informação textual e baseada no conteúdo musical, que nos permitiu aplicar fil-tragens por similaridade, foram também realçados pelos testes realizados, principalmentedevido à dificuldade dos utilizadores em definirem o conceito de similaridade.

As técnicas de visualização usadas foram efectivamente consideradas uma mais-valia,permitindo aos utilizadores descobrirem músicas (através de uma filtragem dinâmica ba-seada em tags e informação de similaridade). A criação de playlists também foi conside-rada como eficaz e de extrema facilidade de utilização.

Palavras-chave: Exploração de colecções musicais, Visualização de Informação, Recu-peração de Informação Musical, Treemaps Ordenados, Filtragem Dinâmica, Audio Snip-

pets

Abstract

Along with the growth of digital music consumption, the need for new solutions forbrowsing and exploring music libraries arises. However, the current main solutions forbrowsing and searching through music libraries have several limitations, such as: don’tuse content-based information; don’t allow users to understand the collection organiza-tion; the creation of playlist remains based on textual metadata.

Starting from these limitations, we developed a new solution that combines three maincomponents: information visualization techniques (based on semantic ordered treemaps),music information retrieval techniques and dynamic filtering, to offer users a more effici-ent, flexible and yet, easy to use solution for browsing music libraries.

Experimental evaluation reveals that our application is easy to use, and allows usersto perform a more effective and fast navigation, while having a deeper knowledge oftheir library. The used techniques were considered as a strong value, allowing users todiscover music and interactively browse their libraries. Satisfaction inquiries showedusers satisfaction on browsing, filtering and creating playlists.

Keywords: Music Library Browsing, Information Visualization, Music Information Re-trieval, Ordered Treemap, Dynamic Filtering, Audio Snippets

Conteúdo

1 Introdução 11.1 Descrição do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Solução Desenvolvida . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Contribuição e Resultados Atingidos . . . . . . . . . . . . . . . . . . . . 41.5 Organização da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Trabalho Relacionado 62.1 Visualização / Recuperação de Informação Musical . . . . . . . . . . . . 7

2.1.1 Recuperação de Informação Musical . . . . . . . . . . . . . . . . 72.1.2 Visualização de Informação . . . . . . . . . . . . . . . . . . . . 152.1.3 Outros sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.1 RIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.2 Visualização de Informação . . . . . . . . . . . . . . . . . . . . 37

2.3 Contribuição, Objectivos e Requisitos da Solução Proposta . . . . . . . . 382.4 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Estudo com Utilizadores 423.1 Descrição do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.1 Hábitos e comportamentos dos utilizadores . . . . . . . . . . . . 443.2.2 Necessidades e requisitos dos utilizadores . . . . . . . . . . . . . 45

3.3 Implicações de desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 A solução 484.1 Panorama da solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1.1 Componentes de Extracção e Recuperação . . . . . . . . . . . . 49

I

4.1.2 Componente de Visualização . . . . . . . . . . . . . . . . . . . . 514.2 Arquitectura revisitada . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.1 Arquitectura Model - View - Controller . . . . . . . . . . . . . . 554.3 Componente de Extracção de informação . . . . . . . . . . . . . . . . . 56

4.3.1 Características extraídas . . . . . . . . . . . . . . . . . . . . . . 584.4 Componente de Recuperação de Informação . . . . . . . . . . . . . . . 604.5 Componente de Visualização de Informação . . . . . . . . . . . . . . . 64

4.5.1 Gestor das Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . 664.5.2 Gestor da playlist . . . . . . . . . . . . . . . . . . . . . . . . . . 684.5.3 Tocador áudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.5.4 Ferramentas de filtragem . . . . . . . . . . . . . . . . . . . . . . 724.5.5 Explorador do sistema de ficheiros . . . . . . . . . . . . . . . . . 77

4.6 Interface da Aplicação - Protótipo não funcional . . . . . . . . . . . . . . 794.7 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Concretização da solução 835.1 Plataforma de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 835.2 Arquitectura da Vista de Treemap . . . . . . . . . . . . . . . . . . . . . 84

5.2.1 Algoritmo do Treemap . . . . . . . . . . . . . . . . . . . . . . . 855.3 Ferramentas de Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . 865.4 Modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.5 Mecanismos de extracção e recuperação de informação . . . . . . . . . . 89

5.5.1 Extracção de informação . . . . . . . . . . . . . . . . . . . . . . 905.5.2 Recuperação de informação . . . . . . . . . . . . . . . . . . . . 90

5.6 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6 Avaliação Experimental 926.1 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.1.1 Descrição e Execução da avaliação experimental . . . . . . . . . 966.2 Análise de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.2.1 Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.2 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.2.3 Tempo de Execução das Tarefas . . . . . . . . . . . . . . . . . . 996.2.4 Utilização de componentes . . . . . . . . . . . . . . . . . . . . . 1016.2.5 Satisfação com o MuVis . . . . . . . . . . . . . . . . . . . . . . 1036.2.6 Funcionalidades do MuVis não avaliadas . . . . . . . . . . . . . 105

6.3 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

II

7 Conclusões e trabalho futuro 1077.1 Sumário da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.2 Conclusões finais e Contribuições . . . . . . . . . . . . . . . . . . . . . 1097.3 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

I Guião dos Testes com Utilizadores 120

II Questionário de Satisfação 122

III Estudo com Utilizadores - Questionário 130

III

Lista de Tabelas

2.1 Análise comparativa entre os sistemas e técnicas de visualização descritos. 392.2 Objectivos para a solução proposta. . . . . . . . . . . . . . . . . . . . . 40

4.1 Resultados da inspecção das colecções de cinco utilizadores. . . . . . . . 734.2 Categorias utilizadas para o filtro Beat. . . . . . . . . . . . . . . . . . . 75

6.1 Medidas consideradas na avaliação conduzida. . . . . . . . . . . . . . . 956.2 Tarefas da avaliação experimental. . . . . . . . . . . . . . . . . . . . . . 996.3 Respostas dos utilizadores ao questionário de satisfação (1). . . . . . . . 1046.4 Respostas dos utilizadores ao questionário de satisfação (2). . . . . . . . 105

IV

Lista de Figuras

2.1 Espectro das especificidades na detecção de similaridade entre músicas. . 132.2 Interface do SonicVisualiser após o processamento de uma música. . . . . 152.3 Visualização do disco do Strike-A-Tune. . . . . . . . . . . . . . . . . . . 182.4 Vista do Globe of Music. . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 PlaySOM no modo de selecção de linha. . . . . . . . . . . . . . . . . . 212.6 Representação de um Smoothed Data Histogram. . . . . . . . . . . . . . 222.7 Diferentes vistas da navegação 3D, no melhoramento de Islands of Music. 242.8 Interface do MusicBox. . . . . . . . . . . . . . . . . . . . . . . . . . . 252.9 Interface do LivePlasma. . . . . . . . . . . . . . . . . . . . . . . . . . . 262.10 Interface do Musicovery. . . . . . . . . . . . . . . . . . . . . . . . . . . 282.11 Interface do MusicRainbow. . . . . . . . . . . . . . . . . . . . . . . . . 292.12 Aplicação do algoritmo Slice-and-dice. . . . . . . . . . . . . . . . . . . 302.13 Aplicação do algoritmo Squarified Treemap. . . . . . . . . . . . . . . . 302.14 Aplicação do algoritmo Ordered Treemap. . . . . . . . . . . . . . . . . 312.15 Aplicação do algoritmo Quantum Treemap. . . . . . . . . . . . . . . . . 312.16 Aplicação do algoritmo Spatially Ordered Treemap. . . . . . . . . . . . 322.17 Interface do PhotoMesa. . . . . . . . . . . . . . . . . . . . . . . . . . . 332.18 Interface do SPG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.19 Aplicação Muscape. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Principais géneros musicais que compõem as colecções dos participantes. 443.2 Preferências dos utilizadores na pesquisa de músicas. . . . . . . . . . . . 463.3 Preferências dos utilizadores na criação de playlists. . . . . . . . . . . . 46

4.1 Perspectiva geral da arquitectura. . . . . . . . . . . . . . . . . . . . . . . 494.2 Exemplo de pesquisa de músicas semelhantes na nossa solução. . . . . . 514.3 Vista de lista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4 Vista de Treemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5 Interface do MuVis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

V

4.6 Diagrama do padrão arquitectural MVC. . . . . . . . . . . . . . . . . . 554.7 Arquitectura do componente de Extracção de informação. . . . . . . . . 564.8 Fluxo do carregamento da colecção musical na solução. . . . . . . . . . 574.9 Arquitectura do componente de recuperação de informação. . . . . . . . 614.10 Fluxo de comunicação na pesquisa de músicas semelhantes. . . . . . . . 624.11 Arquitectura geral do componente de visualização de informação. . . . . 644.12 Estrutura interna do módulo Gestor de Vistas. . . . . . . . . . . . . . . . 674.13 Vista simples da playlist. . . . . . . . . . . . . . . . . . . . . . . . . . . 684.14 Vista de gestão da playlist. . . . . . . . . . . . . . . . . . . . . . . . . . 694.15 Estrutura interna do módulo Gestor de Playlist. . . . . . . . . . . . . . . 704.16 Interface do tocador de áudio. . . . . . . . . . . . . . . . . . . . . . . . 714.17 Arquitectura interna do Tocador de Áudio. . . . . . . . . . . . . . . . . . 724.18 Exemplo de um filtro no MuVis: duração. . . . . . . . . . . . . . . . . . 724.19 Aplicação do padrão Decorator no módulo de Filtragem Dinâmica. . . . . 764.20 Arquitectura interna das ferramentas de filtragem. . . . . . . . . . . . . 774.21 Explorador do sistema de ficheiros. . . . . . . . . . . . . . . . . . . . . . 784.22 Estrutura interna do módulo do Explorador do sistema de ficheiros. . . . 794.23 Versão inicial da interface utilizador. . . . . . . . . . . . . . . . . . . . 804.24 Versão final da interface utilizador. . . . . . . . . . . . . . . . . . . . . 814.25 Versão inicial da interface da inspecção de artista (zoom do treemap). . . 814.26 Versão final da interface da inspecção de artista (zoom do treemap). . . . 814.27 Versão inicial da interface de criação de playlists. . . . . . . . . . . . . . 824.28 Versão inicial da interface de criação de playlists. . . . . . . . . . . . . . 82

5.1 Arquitectura do componente de filtragem. . . . . . . . . . . . . . . . . . 875.2 Modelo de dados do MuVis (diagrama ER). . . . . . . . . . . . . . . . . 89

6.1 Interface do MuVis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.2 Interface do Windows Media Player. . . . . . . . . . . . . . . . . . . . . 966.3 Participante a realizar as tarefas no MuVis. . . . . . . . . . . . . . . . . 976.4 Participante a preencher o questionário de satisfação. . . . . . . . . . . . 986.5 Resultados para tempo de execução das tarefas. . . . . . . . . . . . . . . 1006.6 Tempo total na execução das tarefas. . . . . . . . . . . . . . . . . . . . 1016.7 Número de operações de filtragem executadas nas aplicações. . . . . . . 103

VI

Capítulo 1

Introdução

Neste capítulo descrevemos o âmbito do problema identificado na navegação, exploraçãoe visualização de colecções de música em formato digital, apresentamos os objectivos aatingir, resumimos a solução desenvolvida, apresentamos os resultados obtidos na avalia-ção e descrevemos a organização desta dissertação.

1.1 Descrição do problema

Actualmente, as colecções de música em formato digital crescem a um ritmo acelerado,uma vez que todos os dias novas músicas são lançadas no mercado [27]. Adicionalmente,a popularidade dos ficheiros MP3, consequência directa da explosão da Internet1, mudouradicalmente a forma como as pessoas guardam, acedem e compram músicas. Ouvir vá-rias horas de áudio num pequeno dispositivo, comprar músicas pela Internet de uma formarápida e confortável, são apenas algumas das mudanças culturais que temos presenciadona última década. Por exemplo, estima-se que o número de músicas disponíveis numa lojaonline seja quatro vezes maior do que as músicas existentes numa loja física de grandesdimensões (p. ex: megastore).

As soluções existentes actualmente para ouvir música no computador, concebidasprincipalmente através da utilização de informação semântica acerca das faixas, emboratenham sido desenhadas para suportar bibliotecas de dimensão arbitrária, na verdade,apresentam algumas limitações quando sujeitas a colecções grandes. As principais res-trições encontram-se na forma de navegação/exploração das bibliotecas, que é difícil,contrariamente à simplicidade e eficácia que se pretende. Apesar de existirem soluçõeseficientes, com capacidade de criar perfis de utilização/audição das faixas e sofisticados

1http://www.internetworldstats.com/stats.htm, consultado em 05/07/2009.http://www.internetworldstats.com/emarketing.htm, consultado em 05/07/2009.

1

mecanismos de pesquisa de música utilizando informação semântica (p. ex: tags asso-ciadas às faixas, como o género, nome do artista, etc.), a visualização desta informaçãonão tem revelado grande progresso, nem inovação, de tal forma que a maior parte dosutilizadores não conhece a sua biblioteca por completo [68]. De notar também que aflexibilidade na criação de playlists continua também a deixar muito a desejar.

Desta feita, podemos formular o problema evidenciado acima. As soluções existentesactualmente apresentam um conjunto de limitações, nomeadamente: não permitem aoutilizador ter uma visão geral da sua colecção pessoal, de modo a compreenderem a suacomposição; não tiram partido da informação contida na música (p. ex: para filtragemdas colecções); continuam a não ser fáceis de navegar e explorar, porque os mecanismosde visualização são os tradicionais; e finalmente, a criação de playlists apenas tira partidodas tags associadas às músicas.

1.2 Objectivos

Como vimos, as soluções existentes para ouvir e organizar música, não são fáceis deutilizar para colecções de grandes dimensões e não permitem uma utilização simples eeficaz de forma a proporcionar uma visão geral da colecção ao utilizador.

Nesta dissertação pretendemos desenvolver uma nova abordagem para navegar, explo-rar e visualizar colecções de música digital da ordem dos milhares de faixas (entre 1.000a 10.000 músicas) de forma fácil e eficiente. A solução a desenvolver proporcionará aoutilizador uma interacção simples e rápida com a biblioteca musical, de uma forma visual,assim como uma visão geral da sua colecção. A utilização de um conjunto de filtros per-mitirá de uma forma interactiva e progressiva explorar a colecção e pesquisar por músicasque respeitem os critérios. Esta filtragem será baseada em informação semântica, mastambém em informação extraída do conteúdo das músicas.

O nosso objectivo último é permitir ao utilizador que, de uma forma visualmente atrac-tiva, possa rápida e interactivamente filtrar a sua biblioteca, permitindo-lhe ouvir músicasque gosta e conhece, mas também descobrir novas músicas semelhantes, aumentando as-sim o conhecimento sobre a sua biblioteca pessoal. Para atingir os objectivos a que nospropomos desenvolvemos a solução que apresentamos nesta dissertação.

1.3 Solução Desenvolvida

Com esta dissertação propomos uma solução que se baseia na conjugação de três áreascientíficas: técnicas de visualização de informação, técnicas de Recuperação de Informa-

2

ção Musical (semântica e baseada no conteúdo – descritas na secção 2.1.1) e filtragemdinâmica da biblioteca musical.

A nossa solução explora uma nova técnica de visualização, baseada em Treemaps [70],para disponibilizar ao utilizador uma forma distinta de interacção com as suas músicas eproporcionar-lhe uma visão geral da sua colecção musical. Combinando esta técnica commecanismos de Recuperação de Informação Musical, o utilizador poderá não só navegarna sua biblioteca de acordo com filtros baseados em informação semântica, mas tambématravés da utilização de filtros baseados em informação do conteúdo das faixas musicais,como por exemplo, características para inferência de similaridade entre faixas, álbuns eartistas. Desta forma, o utilizador terá um maior controlo sobre a sua colecção pessoal,permitindo-lhe inclusive descobrir músicas com as quais não estava familiarizado.

A flexibilidade da nossa solução também é melhorada, devido à conjugação dos ele-mentos referidos acima, permitindo assim que o utilizador construa manual ou automati-camente playlists mais ricas e atractivas.

A solução desenvolvida foi concretizada através de uma aplicação desktop Java quepermite a navegação e exploração da biblioteca musical através da aplicação de um con-junto de filtros. Dada a complexidade da solução apresentada, dividimos a arquitectura dosistema em três componentes principais, que garantem, respectivamente, a visualização,a extracção de características e a recuperação de informação.

O componente de visualização suporta toda a interacção com o utilizador e disponibi-liza um mecanismo extensível para suportar novas “vistas” sobre a mesma biblioteca.

O componente de extracção de características é responsável por extrair, recolher eguardar todas as informações necessárias sobre as faixas áudio, recorrendo para isso amecanismos de extracção de informação semântica (tags) e a mecanismos de extracçãode informação sobre o conteúdo das músicas.

Por fim, o componente de recuperação de informação, assume um papel muito rele-vante, uma vez que permite não só recuperar informação semântica associada às músicas(p. ex: título da música, nome do artista, etc.), mas também recuperar informação so-bre similaridade musical. A informação sobre similaridade musical é registada a váriosníveis, indo desde o nível de granularidade mais fino, as músicas, até álbuns e artistas.

A avaliação experimental à nossa solução mostrou que os utilizadores conseguem re-alizar as tarefas típicas mais rápida e eficazmente do que no sistema comparativo, e quegostaram mais da nossa solução. No final, os utilizadores conseguiram descrever gene-ricamente a colecção musical, e afirmaram que essa compreensão os ajudou na concreti-zação das tarefas. De facto, os resultados dos questionários de satisfação mostraram queos utilizadores ficaram satisfeitos com o desempenho da nossa solução, na execução das

3

tarefas pretendidas.

1.4 Contribuição e Resultados Atingidos

Neste trabalho a nossa contribuição principal situa-se no desenvolvimento de uma solu-ção que combina visualização e filtragem interactiva para explorar colecções de música.Baseada em informação textual (tags) e informação de conteúdo musical, a nossa solu-ção permite aos utilizadores explorarem as suas colecções de uma forma rápida e de fácilinteracção. Os resultados registados mostraram também que a materialização tanto dacolecção como dos filtros (utilizando o conceito de treemaps), ajudam os utilizadores acompreender as colecções e a efectuar pesquisas mais diversificadas. Apresentamos emseguida as principais contribuições do trabalho apresentado nesta dissertação:

1. Mecanismo de filtragem dinâmica e interactiva, baseado em técnicas de visualiza-ção e recuperação de informação

2. Combinação de informação textual (tags MP3 - ID3) com informação de conteúdopara explorar e filtrar as músicas

3. Criação interactiva de playlists baseada na filtragem dinâmica

4. Arquitectura modular e extensível, que potencia o desenvolvimento de trabalho fu-turo

1.5 Organização da dissertação

Esta dissertação descreve e valida a solução proposta. No documento aqui apresentadocomeçamos por analisar, no capítulo 2, o trabalho relacionado sobre o estado da arte dasáreas de Visualização de Informação e Recuperação de Informação Musical (RIM). Estaanálise serve de fundamento ao problema identificado e também de orientação para asolução proposta.

Em seguida apresentamos os resultados obtidos da realização de um estudo com utili-zadores. Este estudo foi realizado com o intuito de compreender o perfil dos utilizadoresde sistemas áudio e algumas preferências na utilização deste tipo de soluções (capítulo 3).Apresentamos ainda neste capítulo as implicações do estudo realizado na concepção dasolução proposta.

Nos dois capítulos seguintes (capítulo 4 e 5) apresentamos os principais módulos ecomponentes da solução e suas interacções, para o funcionamento da nossa abordagem,

4

aprofundando depois para uma explicação da concretização efectuada, das condicionantestecnológicas e principais algoritmos de funcionamento da solução.

No capítulo 6 apresentamos os principais resultados da avaliação realizada à soluçãodesenvolvida. Neste capítulo elaboramos também uma análise e reflexão dos resultados.

Na última parte desta dissertação, apresentamos as principais conclusões, indicandoas principais contribuições, bem como uma reflexão sobre o trabalho futuro a desenvolver(capítulo 7).

5

Capítulo 2

Trabalho Relacionado

Neste capítulo descrevemos a análise realizada ao trabalho relacionado com os objecti-vos desta dissertação. Como já referido anteriormente, os nossos objectivos consistemem conjugar técnicas de Visualização de Informação com técnicas de Recuperação de In-formação Musical para criar uma nova abordagem de exploração de colecções musicais.Assim, nas próximas secções, analisamos os trabalhos mais relevantes destas duas áreas,mostrando que a sua complementaridade pode contribuir para a criação de soluções maispoderosas.

Ao analisar as técnicas de Visualização de Informação pretendemos demonstrar osesforços realizados para visualizar colecções musicais e as contribuições destas soluções,bem como os problemas que elas apresentam e não resolvem.

Ao analisar as técnicas de Recuperação de Informação Musical1, para além de pro-videnciarmos um conhecimento básico das técnicas de extracção e recuperação de infor-mação de músicas, pretendemos compreender a importância da utilização deste tipo detécnicas quando conjugadas com visualização, e quais as vantagens e desvantagens nautilização deste tipo de abordagens.

Por fim, partindo das observações registadas na análise e trabalho relacionado, defini-mos objectivamente a nossa solução para as questões observadas, esclarecendo qual é anossa contribuição. A definição de objectivos e requisitos para a solução proposta encerrao presente capítulo.

1Ao longo desta dissertação iremos utilizar o termo Recuperação de Informação Musical e a sua abrevi-atura (RIM) para nos referirmos à mesma definição.

6

2.1 Visualização / Recuperação de Informação Musical

Existem duas áreas de investigação que, conjugando os resultados mais promissores deambas, constituem boas soluções para responder às questões mais pertinentes identifica-das no capítulo 1. As duas áreas em discussão são: Recuperação de Informação Musicale Visualização de Informação. Nos últimos anos, a RIM tornou-se numa das áreas maisimportantes de investigação e pesquisa. De uma forma genérica, podemos descrever aRIM como sendo uma área científica interdisciplinar, que visa a extracção de informaçãode peças musicais, assim como a sua pesquisa. A Visualização de Informação, permite apartir de um conjunto de dados de entrada, gerar um conjunto de dados de saída, em quea informação é apresentada ao utilizador de uma forma que facilita a sua compreensãoe legibilidade, dependendo do objectivo daquela técnica de visualização em particular.Existem várias técnicas de visualização (p. ex: treemaps, SOMs, etc.), que dependem devários factores, entre os quais importa destacar os dados de entrada. Nas secções seguintesanalisamos a duas áreas acima referidas.

2.1.1 Recuperação de Informação Musical

Métodos tradicionais, tais como transmissões de rádio ou lojas de venda de CDs, estão acair em desuso, e a serem substituídas por formas mais personalizadas de ouvir e com-prar música, como por exemplo, o Last.fm2, o Pandora3 ou a iTunes Store4. A área deRecuperação de Informação Musical, de uma forma mais ampla do que a já introduzida,corresponde a todas as estratégias que permitem aceder a colecções musicais, de formaa preencher as necessidades de pesquisa e navegação nas mesmas. Actualmente, a maiorparte dos sistemas existentes, incluindo todos os sistemas comerciais, utilizam um sis-tema de metadados (informação semântica associada à música) para organizar e efectuarpesquisas em colecções musicais. No entanto, à medida que a dimensão das colecçõesaumenta (para milhares, ou inclusive, milhões de faixas), torna-se virtualmente impossí-vel manter uma consistência entre todas as descrições de metadados, não só porque nãoexistem standards, mas também porque existem muitos utilizadores responsáveis por es-tas descrições. Desta forma, surge a necessidade de utilizar técnicas de RIM que tenhamcomo base o conteúdo das músicas, extraindo algumas características a partir do sinal áu-dio. Apresentamos em seguida uma visão global sobre esta área, mostrando uma possívelestrutura em que esta se divide (recorrendo a uma série de tarefas), técnicas e característi-

2http://www.last.fm/, consultado em 05/08/2009.3http://www.pandora.com/, consultado em 05/08/2009.4http://www.apple.com/itunes/, consultado em 05/08/2009.

7

cas a extrair do áudio para detectar similaridade musical, e terminamos mostrando algunsdos sistemas mais promissores, destacando a ligação destes com a área de Visualizaçãode Informação.

RIM baseada no conteúdo

RIM baseada no conteúdo é uma área envolvida no desenvolvimento de processos auto-máticos e inteligentes de processar música. O principal objectivo desta área é a obtençãode um conjunto de informações acerca das músicas++. Para se conseguir atingir este ob-jectivo a maior parte da investigação em recuperação de informação tem tido o foco nadescrição automática da música e na avaliação dos métodos propostos.

Podemos esquematizar as tarefas deste campo definindo um conjunto de casos de uso,que indicam o tipo de pesquisa, o tipo de similaridade pretendida entre as faixas áudio,e a forma do resultado de saída. Estes casos de uso podem ser situados numa escalade especificidades, nas quais o tipo de pesquisa e o tipo de resultado a obter definem aespecificidade. Esta escala divide-se em três categorias: sistemas com elevada especifi-cidade, que efectuam comparações com base no conteúdo do sinal áudio; sistemas comespecificidade intermédia, que efectuam comparações com base em características de altonível das músicas, tais como a melodia; e sistemas com baixa especificidade que efectuamcomparações com base em características de baixo nível (ver tabela 1 em [8]). Uma listamais exaustiva e detalhada pode ser encontrada no relatório efectuado por Donald Byrd5.

Existem três estratégias básicas para resolver os problemas apresentados nos casos deuso. Cada estratégia é adequada para uma dada especificidade. A primeira estratégia é ba-seada em metadados (informação embutida ou associada aos objectos áudio) e é adequadaa tarefas com baixa especificidade; a segunda abordagem é usar descritores de alto níveldo conteúdo da música, técnica adequada para pesquisas com especificidade intermédia aalta. A última estratégia é baseada nas características de baixo nível que se podem extrairdas peças musicais, e que é adequada para todas as especificidades. Apresentamos umadescrição sumária das três estratégias identificadas.

Metadados

Os metadados, também designados por informação semântica, são os precursores dos sis-temas RIM. Existem dois tipos de metadados usados para descrever as músicas: factuaise culturais.

5http://www.informatics.indiana.edu/donbyrd/MusicSimilarityScale.html, consultado em 10/12/2009.

8

Enquanto os metadados factuais representam verdades absolutas sobre uma faixa (p.ex: nome do artista, nome do álbum, ano de publicação, nome da faixa, duração, etc.), osmetadados culturais contêm conceitos mais subjectivos. Os problemas associados à in-formação factual podem limitar a utilização de metadados. Garantir a coerência na gene-ralidade dos campos de texto, por exemplo, para consistências linguísticas, capitalização,caracteres internacionais, caracteres especiais e ordem dos nomes próprios, é essencialpara um funcionamento útil [21].

Os metadados culturais contêm informação subjectiva ou cultural acerca de uma mú-sica e são também utilizados para pesquisa de faixas. Entre as classes comuns deste tipode metadados de destacar o estado de espírito (mood), género e estilo musicais. A maiorparte dos sistemas actuais utiliza uma combinação destas categorias de metadados. Aconstrução de métodos automáticos para atribuir metadados culturais e factuais a músicastambém tem sido alvo de muita investigação. Alguns sistemas juntam informação de pre-ferências do utilizador, por exemplo, o número de vezes que uma faixa em particular foitocada, e usa essa informação para efectuar recomendações aos utilizadores.

No entanto, para um sistema baseado em metadados funcionar, as descrições das mú-sicas têm que ser o mais correctas possíveis e o significado do vocabulário utilizado nosmetadados tem que ser partilhado e amplamente compreendido.

Apesar de toda a sua utilidade, os metadados não conseguem resolver todas as tarefasde recuperação de informação musical, devido às complexidades evidenciadas em cima.Porém, a verdade é que os sistemas comerciais que existem actualmente baseiam-se emmetadados e como tal, não permitem facilmente encontrar músicas que os utilizadoresainda não conhecem, ou não sabem como as procurar. Esta surge como uma oportunidadepara os métodos baseados no conteúdo. Estes prometem ser capazes de complementaros métodos baseados em metadados e dar aos utilizadores acesso a novas músicas, queratravés de processos de auto-descoberta, quer disponibilizando um mecanismo de procuraescalável à totalidade da biblioteca digital. Salientamos no entanto, que estes métodos sãoconsiderados um complemento dos métodos de metadados, e não uma substituição destes.

Descrição de Alto Nível do conteúdo musical

Um ponto de partida evidente para a RIM baseada no conteúdo é utilizar os conceitosmusicais, tais como a melodia ou a harmonia, para descrever as músicas. Estes conceitosrepresentam as chamadas características de alto nível do conteúdo musical. A informaçãode alto nível sobre música, descreve o tipo de conhecimento que um ouvinte sofisticadoteria sobre uma peça musical, ainda que este soubesse ou não que tinha esse conheci-mento.

9

Embora conceptualmente estas características sejam simples de compreender, a ex-tracção é extremamente difícil e de investigação intensa no MIREX. O MIREX (Music

Information Retrieval Experimental Exchange) é um concurso realizado anualmente como intuito de avaliar os sistemas de RIM desenvolvidos, e que disponibiliza uma plataformapara avaliação [16, 64]. Desta forma, o MIREX tornou-se num indicador importante doestado da arte de muitas tarefas na área de RIM. Um resumo dos principais resultados de2007 sobre tarefas de alto nível encontra-se na tabela 3 em [8], evidenciando a fragilidadedos sistemas actuais em extrair estas características de forma eficaz.

Entre as principais características de alto nível que se podem extrair de uma peçamusical, para além das já referidas melodia e harmonia, encontram-se o ritmo, o tom e aestrutura de acordes. Apresentamos a seguir uma breve descrição destas características edas principais técnicas de extracção.

O ritmo é a pulsação da música, é o que dá movimento e vivacidade à música. Semritmo, a música não existe. As técnicas mais relevantes são as apresentadas em [14,22, 25, 58, 60], e consistem genericamente em organizar os sinais áudio numa estruturahierárquica de batidas.

A melodia é uma sucessão dos sons musicais combinados. É a voz principal, quedá sentido a uma composição musical. As técnicas mais relevantes para identificação damelodia são as apresentadas em [18, 23, 24, 42, 45], e a técnica principal é baseada nosubharmonic summation spectrum.

A harmonia é um conjunto agradável de sons, e diz-se que uma peça musical é har-moniosa, quando os sons numa sucessão são agradáveis ao ouvido de quem ouve. Aestrutura de acordes e tonalidade permitem identificar, por exemplo, a estrutura da mú-sica. Enquanto o tom corresponde a um intervalo utilizado na escala musical diatónica(escala usada no Ocidente: Dó-Ré...-Si), um acorde é um conjunto de notas que respei-tam o tom usado na música. Os sistemas mais bem sucedidos [26,32,62] utilizam HMMs(Cadeias de Markov de parâmetros escondidos).

As características de alto nível representam conceitos que estão directamente ligadoscom a percepção que os utilizadores têm das músicas, no entanto, como já referido, sãodifíceis de extrair. Outra abordagem é a apresentada na secção seguinte, que correspondeà descrição do conteúdo musical com recurso a características de baixo nível. Estas ca-racterísticas não representam directamente conceitos musicais, perdendo-se a percepçãodas características pelos utilizadores, mas permitem sintetizar a partir delas algumas dascaracterísticas apresentadas nesta secção.

10

Descrição de Baixo Nível do conteúdo musical

As características de baixo nível descrevem o áudio sob a forma de características acústi-cas que são geralmente bem definidas e determinadas com base na análise directa do sinaláudio. Embora sejam bem compreendidas e aceites, uma desvantagem destas caracterís-ticas é que não dizem muito sobre a estrutura genérica da música, e o seu significado nãoé partilhado pela maioria dos utilizadores sem conhecimentos técnicos desta área. Entreas características de baixo nível conhecidas, importam destacar as seguintes: Loudness,Spectrum Powers, Brightness, Bandwidth, Pitch e Cepstrum.

Loudness (Intensidade) também chamada de volume ou pressão sonora refere-se àpercepção da amplitude da onda sonora do áudio, e é geralmente caracterizada pelo qua-drado da energia do sinal computado da STFT (Short-Time Fourier Transform), em deci-béis.

Spectrum Powers é um espectro que inclui o espectro total e todos os powers dassub-bandas, e são sempre representados sob a forma de logaritmos.

Brightness é uma medida da frequência mais elevada do sinal e é computada comosendo o centróide da STFT e guardada sob a forma de logaritmos.

Bandwidth (Largura de banda) é a medida da faixa de frequência, em hertz, de umsistema ou sinal. A largura de banda é um conceito central em diversos campos de co-nhecimento, incluindo teoria da informação, rádio, processamento de sinais, electrónicae espectroscopia. Neste caso corresponde a faixa de frequência ocupada pelo sinal áudio.

Pitch (Altura) refere-se à forma como o ouvido humano percebe a frequência dossons, e corresponde ao período fundamental de uma onda sonora do discurso humano.

Cepstrum é uma operação matemática que consiste em extrair a Transformada deFourier do espectro do sinal na forma logarítmica. O significado físico desta transforma-ção pode ser interpretado como uma informação do ritmo das mudanças nas diferentesbandas do espectro de um sinal qualquer. O cepstrum pode ser ilustrado recorrendo aouso dos Mel-Frequency Cepstral Coeficients (MFCC’s).

As técnicas de extracção das características descritas acima são as mais variadas e têmvindo a ser desenvolvidas e aperfeiçoadas ao longo dos últimos anos (usando ferramentascomo as apresentadas na secção 2.1.1), porém, não efectuamos aqui uma descrição maisdetalhada por não constituírem o foco principal do nosso trabalho. Para informações maisdetalhadas consultar [8].

11

Similaridade entre peças musicais

A extracção isolada das características por si só, não permite efectuar tarefas complexas,como por exemplo, determinar o grau de similaridade entre duas peças musicais. Noentanto, usando como base os resultados descritos para a extracção de características debaixo e alto nível, podemos inferir sobre a similaridade entre faixas musicais.

A similaridade entre faixas musicais pode ser feita a vários níveis e com vários pro-pósitos. A figura 2.1 mostra o espectro de especificidades para as tarefas de detecção desimilaridade. Enquanto as tarefas do lado esquerdo são as que requerem um grau ele-vado de similaridade do áudio (sistemas de especificidade elevada ou média), as tarefasdo lado direito apenas requerem um grau de similaridade baixo do conteúdo da música oude conceitos relativos (sistemas de especificidade intermédia ou baixa).

Do lado esquerdo do espectro encontram-se técnicas que pretendem encontrar o mesmoconteúdo áudio. Assim, no extremo deste lado do espectro, encontramos sistemas definger-printing (“impressão digital única” de uma música), ou seja, sistemas que pro-curam identificar gravações específicas em novos contextos, tal como os apresentadosem [69] e [1].

Mais perto do centro do espectro, existem sistemas com especificidade elevada-intermédiacujo objectivo principal não é encontrar exactamente as mesmas músicas, mas aquelas quese encontram numa vizinhança de similaridade muito próxima. Neste contexto, surgi-ram alguns sistemas para identificação de conteúdos de áudio misturado (versões remix),em [6] e [7]. A grande motivação por trás destes sistemas é a pretensão de normalizar asgrandes colecções musicais para que as mesmas gravações não sejam incluídas nas pes-quisas de um utilizador e para permitir que na recomendação a um utilizador apareçamtodas as versões das gravações, incluindo: transmissões de rádio, instrumentais, remixs,etc.

Na parte da baixa-intermédia similaridade (centro - lado direito), encontramos siste-mas onde o utilizador procura conteúdo musical específico, mas não necessariamente amesma faixa musical. Alguns exemplos de aplicações deste tipo de técnicas: encontraro mesmo trabalho do mesmo artista mas gravado numa altura ou local diferente; encon-trar o mesmo trabalho tocado por artistas diferentes (cover songs), já estudados em [19]e [59] com uma precisão de 52% determinada pelo MIREX em 2007; e uma infinidade deoutras aplicações. Estes são os problemas mais complicados e desafiantes de detecção desimilaridade com base na recuperação de informação musical.

Finalmente, no extremo do lado direito, um trabalho muito citado para detecção desimilaridade ao nível do artista ou género musical é o de Logan e Salomon [39]. Estesautores conduziram experimentações de similaridade numa base de dados de 8000 faixas,

12

Figura 2.1: Espectro das especificidades na detecção de similaridade entre músicas.

de diferentes géneros musicais. O algoritmo utilizado para agrupamento foi o K-means,usando como dados de entrada os MFCC’s extraídos de cada faixa. Os resultados obti-dos reportaram uma precisão de 50% de músicas relevantes nas primeiras 5 músicas decada pesquisa. Recentemente, este trabalho foi estendido por Aucouturier e Pachet [3],que usaram modelos de mistura gaussianos (GMM) de MFCC’s, atingindo dessa feitamelhores resultados.

Tal como evidenciado na figura 2.1, existe um buraco no espectro das especificidades.Embora enormes esforços tenham vindo a ser realizados no sentido de desenvolver téc-nicas de RIM, capazes de preencher esse buraco e fazer a transição entre os sistemas deambos os lados, a verdade é que este problema continua por resolver. Esta fora do âmbitodesta dissertação qualquer pretensão em resolver este questão.

Nesta secção não esgotámos as técnicas nem os métodos existentes para detecção desimilaridade entre faixas musicais, uma vez que existem inúmeras formas de efectuareste processamento. No entanto, mostrámos que a detecção de similaridade é um passoextremamente importante para conseguirmos construir sistemas que sejam eficazes noacesso e recuperação de músicas de uma biblioteca digital. Estas técnicas permitem criaruma diversidade de aplicações como as descritas acima e como as que iremos analisar nasecção 2.1.2, sobre visualização de informação, tornando computacionais, factores quesão humanamente mais triviais de identificar.

Apresentamos em seguida alguns sistemas de RIM que permitem não só extrair al-gumas das características referidas nos capítulos anteriores, como também desenvolvernovas soluções e melhores algoritmos para as tarefas de RIM.

Sistemas de RIM

Actualmente, um conjunto de ferramentas e plataformas que combinam as várias técni-cas de RIM, entre as quais extracção de características, recuperação musical, e avaliaçãoautomática estão a ser desenvolvidos. Apresentamos em seguida alguns dos sistemas quemais se têm destacado, na área de investigação e avaliação das técnicas de recuperação de

13

informação musical:

1. MARSYAS6: Music Analysis, Retrieval and Synthesis for Audio Signals [66] é umconjunto de blocos de software escritos em C++, desenvolvidos na Universidade dePrinceton, e na Universidade de Victoria, Canada, cujos objectivos são a extracçãode características do áudio, aplicação de técnicas de aprendizagem e actividadesde recuperação musical em colecções musicais. É uma plataforma de extracção decaracterísticas de baixo nível, estando por isso orientada a investigadores e progra-madores.

2. CLAM7: Biblioteca escrita em C++ para áudio e música [2] foi desenvolvida naUniversidade Pompeu Fabra (UPF), em Barcelona, Espanha. É uma ferramentabastante similar ao MARSYAS uma vez que disponibiliza também uma plataformapara extracção de características e síntese de música. No entanto, estende o conceitodo MARSYAS por disponibilizar um conjunto de interfaces gráficas de utilizador,permitindo aos investigadores produzir aplicações tendo como público-alvo utiliza-dores de música sem conhecimentos de programação.

3. M2K8: Music to Knowledge é uma plataforma desenvolvida na Universidade do Il-linois, Urbana-Champaign, cujo objectivo primário é a avaliação de sistemas de re-cuperação de informação musical [17]. Estende também o conceito do MARSYASe do CLAM porque disponibiliza uma interface gráfica para construir sistemas derecuperação de informação musical. M2K também suporta avaliação automáticadas tarefas descritas para recuperação de informação musical e como tal é umacomponente chave das avaliações efectuadas na MIREX.

4. OMRAS29: Online Music Recognition and Searching II é uma plataforma de Re-cuperação de Informação Musical distribuída, em desenvolvimento conjunto noGoldsmiths, Universidade de Londres, e no Queen Mary, Universidade de Londres.Expandindo os conceitos das plataformas apresentadas anteriormente, a OMRAS2tem como principal objectivo integrar um conjunto de sistemas de RIM num pacotede software orientado ao utilizador, que consiga ajudar investigadores, estudiososda música, e profissionais do comércio musical a explorar o uso de métodos basea-dos no conteúdo das músicas. Os componentes já existentes desta plataforma são:SonicVisualiser, uma ferramenta de extracção e visualização de características de

6http://sourceforge.net/projects/marsyas, consultado em 05/08/2009.7http://clam.iua.upf.edu/, consultado em 05/08/2009.8http://www.music-ir.org/evaluation/m2k, consultado em 05/08/2009.9http://omras2.org, consultado em 05/08/2009.

14

Figura 2.2: Interface do SonicVisualiser após o processamento de uma música.

baixo nível, que utiliza um paradigma de editor áudio para os investigadores ins-peccionarem a informação extraída automaticamente dos ficheiros áudio (ver figura2.2); o MusicOntology, um esquema de metadados construído pelo World Wide

Web Consortium’s Resource Description Framework (RDF) para descrever músicae recursos de software na rede semântica; AudioDB, uma base de dados de carac-terísticas de baixo nível que é escalável para guardar e pesquisar características degrandes bibliotecas digitais de música, e FFTExtract, uma ferramenta para extrac-ção de características com recurso à utilização da FFT (Fast Fourier Transform).

2.1.2 Visualização de Informação

Ter uma biblioteca digital de música de elevadas dimensões é, como já foi referido, umarealidade actual. No entanto, de que vale ter todas estas músicas se não somos capazes deefectuar uma navegação e visualização eficaz de modo a ter uma visão global da colecção?

Apresentamos em seguida algumas técnicas de visualização (que assentam em téc-nicas de RIM analisadas na secção anterior) que ajudam a atingir estes objectivos. Assoluções analisadas são diversas e utilizam técnicas de visualização que vão desde osSelf-Organizing Maps [28] e grafos, até Treemaps [63, 5, 4, 70] e outras técnicas menoscomuns.

A escolha destas técnicas (e sistemas) em detrimento de outras, deve-se ao facto destasapresentarem resultados interessantes em relação à navegação e permitirem uma forma

15

diferente e inovadora de estruturar e organizar as bibliotecas digitais, usando técnicas quenão são exclusivas da visualização de informação ou de RIM.

Como grande parte das técnicas/sistemas apresentados têm como estrutura base paraa organização das bibliotecas digitais o Self-Organizing Map (abreviadamente SOM), co-meçamos por apresentar uma descrição sumária deste, para facilitar a compreensão dosrestantes sistemas analisados.

Self-Organizing Map (SOM)

O SOM, desenvolvido por Kohonen [28], é uma estrutura de redes neuronais não supervi-sionada com “re-alimentação” que permite efectuar um mapeamento entre um conjunto dedados de entrada de dimensão elevada, para um espaço de duas dimensões. Esta estruturapreserva todas as características de uma rede neuronal artificial: é não supervisionado, écompetitivo e auto-organizável, o que o torna bom para agrupamento e visualização deinformação.

O SOM consiste num conjunto de i nós distribuídos por uma grelha bidimensional(embora também seja possível efectuar um mapeamento para 1D ou 3D), onde cada ele-mento está ligado a um vector de pesos. Cada vector de pesos tem duas componentes, osdados e a localização. O algoritmo para construção do SOM é bastante simples, como sepode constatar na descrição apresentada a seguir.

O primeiro passo do algoritmo é a inicialização dos vectores de pesos, estritamentenecessária para produzir resultados legítimos e razoáveis. São escolhidos aleatoriamentevalores próximos de 0 e atribuídos a todos os elementos de um nó vector de pesos.

Para cada iteração do algoritmo, selecciona-se aleatoriamente um vector de entradae procura-se no mapa de vectores de peso, o que melhor representa a amostra, usandopara o efeito um método para detecção de similaridade. O método mais frequentementeutilizado é a distância euclidiana. O vector vencedor é depois actualizado de acordo coma função de aprendizagem para se tornar mais parecido com o vector de entrada.

O próximo passo consiste em escalar os vizinhos para que estes também reflictama actualização efectuada no nó vencedor. A função usada é irrelevante desde que sejadecrescente, levando a que quanto mais longe os vizinhos estiverem, menos aprendem. Onúmero de vizinhos seleccionados também decresce com o tempo para que as amostrasprimeiro se movimentem para a área onde potencialmente vão estar, e depois possam irlutando pela sua posição.

Finalmente, o algoritmo volta a executar-se. Em média, o algoritmo repete-se mais de1000 vezes. O resultado do processo de aprendizagem do SOM é um mapa topologica-mente ordenado dos sinais de entrada no espaço 2D.

16

Importa salientar que o SOM pode ser treinado com base em qualquer conjunto decaracterísticas de entrada, daí que esta técnica seja uma das mais utilizadas ao longode todos os trabalhos estudados, por exemplo, para efectuar o agrupamento de músicassemelhantes em géneros musicais.

No entanto, esta estrutura apresenta algumas desvantagens, entre as quais importadestacar a sua complexidade computacional, especialmente quando o conjunto de dadosa processar é elevado porque necessita de muitas iterações para o mapa convergir; o factode não permitir a visualização correcta e eficiente de um padrão que exista num espaçode dimensão elevada (por exemplo, métodos tradicionais de recuperação de informação,modelo dos cosenos ou da distância euclidiana); a estabilidade da estrutura, embora pro-videncie muita informação sobre os dados de entrada aos utilizadores, impede que seconsigam efectuar ajustes de acordo com as necessidades destes, e compromete a flexibi-lidade das aplicações que a usam.

Nas secções seguintes procederemos à análise de algumas técnicas e sistemas de vi-sualização de informação musical, muitas das quais usam como estrutura base para orga-nização das colecções digitais o SOM aqui descrito, com as modificações necessárias acada sistema.

Strike-A-Tune

Geralmente, as pessoas, dependendo do seu estado de espírito, preferem ouvir músicas deum determinado estilo musical ou artista, em detrimento de uma música em particular.

Em [54] uma nova abordagem para visualizar colecções pessoais é apresentada. Tendopor base o conceito de navegação fuzzy (“confusa”), o Strike-A-Tune é uma interface quepermite aos utilizadores navegar de uma forma desorganizada nas suas próprias colecções,impelindo-os a descobrir músicas tocadas com menor frequência, combinando aspectosde navegação precisa e de navegação aleatória.

Neste sistema, existe um tambor, com o qual os utilizadores interagem, e uma re-presentação visual do disco do tambor (ver figura 2.3). Na visualização do disco sãomostrados anéis divididos em segmentos onde são mostradas as músicas e as informa-ções sobre estas. Anéis mais próximos do centro têm menos músicas, mas mais detalhes.Actualmente, as músicas estão posicionadas no anel de acordo com a similaridade com amúsica do centro (com base na similaridade de metadados). Músicas em anéis mais pertodo centro são mais similares à música do centro do que as músicas mais afastadas. Cadamúsica é ainda colorida de acordo com uma terceira dimensão, o género.

Quando o utilizador bate num local do tambor, a música associada a essa posição émapeada para o centro do disco e os anéis são repovoados com base na similaridade com

17

Figura 2.3: Visualização do disco do Strike-A-Tune.

a música seleccionada, começando a mesma a ser tocada. Batidas mais fortes mostramuma animação na rotação em torno do centro até se atingir a música seleccionada. Estaanimação foca a atenção do utilizador em torno do segmento do anel seleccionado. Maisimportante é que, devido ao feedback táctil do tambor, o utilizador está sempre conscientedo instrumento nas suas próprias mãos, permitindo de certa forma que a interface sejamais tangível.

Uma característica deste sistema é o facto de algumas músicas menos conhecidas ouesquecidas pelo utilizador, ganharem uma hipótese de virem a ser tocadas. No entanto,apenas músicas semelhantes à que o utilizador seleccionou poderão ser tocadas.

Strike-A-Tune constitui uma forma inovadora e interessante de navegação, combi-nando vantagens de navegação precisa e fuzzy, e que tem o seu foco principal na inte-ractividade e tangibilidade. No entanto, apresenta um conjunto de limitações, entre asquais importa destacar que não permite a escolha de uma música em particular ou umaselecção por géneros para orientar a navegação (por exemplo para estruturar o anel e ori-entar a navegação), e principalmente porque utiliza técnicas de similaridade baseadas emmetadados, que apresenta as desvantagens já evidenciadas acima. A organização do anelpoderia ser melhorada se utilizasse o conteúdo da música para determinar a similaridadeentre músicas.

Globe of Music

O Globe of Music, apresentado em [33], é outra alternativa à visualização de uma colec-ção musical. Utilizando um SOM esférico, treinado com base em características de baixonível, a visualização e navegação são efectuadas através de um Sistema de InformaçãoGeográfico (SIG), o NASAWorldWind10, um projecto de software livre desenvolvido noNASA Ames Research Center.

10http://worldwind.arc.nasa.gov/, consultado em 05/08/2009.

18

Este sistema apresenta três componentes essenciais: a extracção de características(são utilizadas as Statistical Spectrum Descriptor (SSD) avaliadas por Lidyin [34]); oGeoSOM (SOM esférico proposto por Wu et al. em [71], que permite uma abordagemeficiente em relação a espaço/tempo para procura de vizinhos; reduz o grau de distorçãodos dados através da remoção de fronteiras/limites, e possui processo de treino semelhanteao de um SOM normal); e o WorldWind, SIG da NASA que permite explorar a Terranum ambiente 3D, e outros mundos, através de um mecanismo de extensões, que permiteacrescentar ao sistema novas funcionalidades/mundos (ver figura 2.4).

A informação mostrada no globo está distribuída em camadas, que existem acima doterreno e permitem definir propriedades associadas a uma determinada posição, dadasas coordenadas de longitude e latitude, com uma altura definida. No Globe of Music,existe uma camada que contém uma imagem de fundo e ícones para cada música inserida.Estes ícones são texturados com imagens decorativas e ligados aos ficheiros das músicas.Apontando para um ícone com o rato, é mostrada a informação sobre a faixa.

Importa referir também que as fronteiras/limites e os nomes dos locais são represen-tados no WorldWind através de ficheiros binários. No Globe of Music, estes ficheiros sãoutilizados para mostrar sectores do globo relacionados com um neurão do GeoSOM, epara definir nomes de locais, neste caso o nome do artista e da faixa, para as coordenadaspara as quais os ícones estão colocados. Este facto é importante, porque permite a visua-lização dos sectores nos quais o globo está dividido, e também a utilização da ferramentaintegrada de procura, para localizar músicas através do método convencional de pesquisade texto, sem necessidade de esforço acrescido.

Porém, este sistema apresenta algumas falhas de navegação, como reportado pelosutilizadores após uma fase de testes; não permite que o utilizador consiga compreendera organização do mapa pelos diferentes géneros musicais sem ser através da audição dasmúsicas, e por fim, não disponibiliza um mecanismo eficiente para pesquisa de músicas,sem ser com recurso ao método tradicional de pesquisa textual.

PlaySOM

O PlaySOM [44] é uma interface para explorar colecções musicais, baseada no treino deum Self-Organizing Map (SOM), que permite interactivamente a exploração da colecçãomusical com base na similaridade entre as faixas áudio (as características utilizadas comentrada para treinar o SOM são as apresentadas em [35], denominadas Rhythm Patterns).

PlaySOM permite que os utilizadores interajam com o mapa principalmente por pan-

ning, zooming semântico (nível de zoom que influencia a quantidade de dados que sãomostrados) e seleccionando faixas. Os utilizadores podem mover-se no mapa, fazer zoom

19

Figura 2.4: Vista do Globe of Music.

em áreas de interesse e seleccionar as músicas que pretendem ouvir. Desta forma, con-seguem explorar as suas colecções pessoais, gerar playlists com base na similaridade dasfaixas e ouvir as músicas no programa ou exportar as mesmas para ouvir noutros progra-mas.

Existem essencialmente duas formas de interacção com o PlaySOM:

1. Modo de selecção rectangular: é utilizado para seleccionar músicas de uma regiãoem particular do mapa (não se preserva a ordem pela qual as faixas são selecciona-das);

2. Modo selecção de linha: permite que o utilizador seleccione um conjunto de mú-sicas, por debaixo de uma trajectória, respeitando a ordem de desenho da linha.Desta forma é possível gerar uma playlist efectuando uma transição suave entre osdiferentes grupos de músicas (ver figura 2.5). Uma utilização possível desta funci-onalidade é a de gerar playlists grandes para funcionalidades de auto-dj.

Em suma, PlaySOM é uma boa interface para explorar interactivamente colecçõesde músicas digitais, possuindo mecanismos de interacção interessantes (por exemplo, omodo de selecção de linha) e as características mínimas de um tocador de áudio comum.

Islands of Music

Pampalk [52] apresenta um sistema para a exploração de bibliotecas de músicas, que usauma metáfora de ilhas, mares e montanhas onde a estrutura inerente à colecção musicalse reflecte no arranjo das mesmas. Este sistema é semelhante a outros já apresentadosna medida em que utiliza também uma organização estruturada com base no conteúdodas peças musicais. Em Islands of Music, as ilhas representam géneros musicais e as

20

Figura 2.5: PlaySOM no modo de selecção de linha.

montanhas/vales nas ilhas representam subgéneros. As ilhas estão situadas de tal formaque géneros similares estão perto e podem estar ligados por uma passagem, enquanto osgéneros diferentes estão separados por um mar profundo.

O sistema utiliza um SOM treinado com características obtidas a partir do melhora-mento de modelos Psico-acústicos (Rhythm Patterns) para determinar similaridades entremúsicas. O utilizador pode navegar e encontrar músicas de duas formas:

1. Usar as músicas conhecidas para o utilizador como marcadores das ilhas;

2. Usar etiquetas que descrevem algumas propriedades relevantes das músicas.

Para visualização dos grupos formados pelo SOM, é utilizada a técnica Smoothed

Data Histogram (SDH) [53] para simplificar a identificação de zonas interessantes nomapa e para se obter a visualização de ilhas (ver figura 2.6). O conceito essencial destemapa é o da estimação da densidade das zonas, ou seja, utilizar a densidade de probabili-dades para representação das densidades das zonas do mapa (ideia: uma zona com maismúsicas é mais “densa” do que uma que tem menos músicas - geralmente marcada comouma ilha).

Para criar a metáfora dos mapas, a densidade é visualizada utilizando um códigode cores que vai desde o azul-escuro (mar fundo) até ao azul claro, de amarelo (praia)até verde-escuro (floresta) a verde-claro (montanhas) a cinzento (rochas) e finalmente abranco (neve). Este código é corroborado pelo artigo de codificações de cores em [47].

O processo de extracção de características é dividido em 2 fases principais:

21

Figura 2.6: Representação de um Smoothed Data Histogram.

1. Specific Soundness Sensation - a loudness sensation por frequência de banda emintervalos de tempo pequenos (6 segundos) é calculada a partir dos dados da música(raw music data);

2. Rhythm Patterns - calcula-se uma representação independente do tempo para cadapeça musical (o rhythm pattern). Este contém informação de como batidas fortes erápidas são tocadas de acordo com as respectivas frequências de bandas.

Este sistema apresenta um novo mecanismo de extracção de características, com baseno melhoramento de algoritmos pré-existentes. No entanto, este novo mecanismo é rela-tivamente mais complexo, uma vez que recorre a métodos matemáticos computacional-mente pesados (por exemplo: transformadas de fourier) e arrasta com ele alguns proble-mas: algumas músicas são mal classificadas, porque existem algumas simplificações epropriedades do áudio que não são levadas em conta, ou porque algumas músicas sim-plesmente têm um género musical complicado de categorizar. Apesar dos bons resultadosobtidos nas avaliações com utilizadores, a biblioteca de 359 músicas parece pouco rele-vante, uma vez que se encontra distante dos valores normais para uma colecção pessoal(acima de mil) [27].

22

An Innovative 3D User Interface for Exploring Music Collections Enriched withMeta-Information from the Web

Baseado no trabalho desenvolvido em Islands of Music [47], este sistema permite tambémcriar uma paisagem de ilhas virtuais, com a diferença de se navegar num cenário em 3D.Tal como o seu predecessor, esta solução usa o SOM como técnica de agrupamento dasmúsicas, treinado com recurso ao Rhythm Fluctuation Patterns [52], e o SDH para geraro seu perfil em 3D.

A interface deste sistema é controlada com recurso a um game pad, como os utilizadospara os videojogos, providenciando 4 formas diferentes de navegação e visualização (verfigura 2.7):

• Visualização da informação de etiquetas do mp3 (a estratégia para etiquetar o SOMé a apresentada em [29]);

• Sensação do áudio no espaço 3D: enquanto o utilizador explora a colecção, é au-tomaticamente apresentado ao utilizador os “thumbnails musicais” (30 segundoscalculados aleatoriamente) das músicas próximas da que estamos a ouvir, dandofeedback ao utilizador do estilo musical da região corrente;

• Enriquecimento do cenário com palavras obtidas da web (técnicas de web-retrieval,para enriquecer a paisagem com informação semântica e visual. Em vez de mostraro nome da música e o artista na paisagem, o utilizador pode escolher as palavrasque descrevem a música ouvida, ou imagens que estão relacionadas com esta - eti-quetagem do SOM). Apenas de destacar que para se obterem os termos, procura-seo nome do artista no Google11, e obtemos os resultados das primeiras 100 páginas;analisam-se os resumos obtidos, reduzindo o esforço. Para evitar a ocorrência depalavras totalmente não relacionadas, usa-se um dicionário de domínio específico,que neste caso é uma versão reduzida do dicionário utilizado em [48];

• Enriquecimento do cenário com imagens retiradas da web relacionadas com os des-critores semânticos e com os artistas (as imagens são obtidas com recurso ao mé-todo de busca disponibilizado pelo Yahoo12, enviando o nome do artista e o termona pesquisa).

Este sistema, apesar da mais-valia representada por todos os melhoramentos efectua-dos, desde o áudio 3D à recuperação através da web, é uma passagem do sistema Islands

11http://www.google.pt, consultado em 01/04/2009.12http://www.yahoo.com, consultado em 01/04/2009.

23

Figura 2.7: Diferentes vistas da navegação 3D, no melhoramento de Islands of Music.

of Music em 2D para uma versão em 3D. Embora os conceitos de controlo através de umgame pad e de navegação pela cena 3D sejam interessantes, este sistema apenas resultaquando o utilizador está a usar a plataforma de suporte física para ouvir música.

MusicBox

Em [36], Lillie apresenta o MusicBox, uma nova solução para exploração de colecçõesmusicais que organiza as bibliotecas num espaço a duas dimensões, com o objectivo derepensar a forma como as pessoas estão habituadas a ver e organizar as suas colecções.

O MusicBox vai além das estratégias convencionais que utilizam tags, e alarga o seudomínio para incluir características como tempo, timbre, e ainda uma sumarização daspropriedades acústicas de uma música, extraídas de outro projecto de Lillie, denominadoSoundsieve13. Complementarmente, o MusicBox também utiliza informações extraídasda web (web retrieval).

Na figura 2.8 podemos ver a interface do protótipo desenvolvido. A localização dasfaixas é determinada pela redução de dimensão do conjunto de características extraídasdas faixas musicais.

Neste sistema, podemos navegar livremente no espaço bidimensional da colecção paraencontrar as músicas que procuramos. Nesta representação, objectos similares aparecempróximos, e é possível distinguir agrupamentos (clusters) de álbuns, artistas, músicas egéneros. Depois de escolhermos uma vista em particular, podemos desenhar um caminhoentre as nossas músicas para criar uma playlist inteligente capaz de, por exemplo, tocarmúsicas escalando tempo, ou agrupando músicas com fingerprints semelhantes entre os

13http://www.flyingpudding.com/projects/soundsieve/, consultado em 20/08/2009.

24

Figura 2.8: Interface do MusicBox.

diversos géneros. Existe também um enorme esforço para que o utilizador controle avisualização e possa filtrar a informação que está a ver em qualquer momento (exemplosde filtros: duração das músicas, número de secções da música, género, etc.).

Entre as principais vantagens do MusicBox, importa salientar:

1. Contrariamente às soluções actuais baseadas em navegação e filtragem de listas,esta representação espacial enfatiza novas relações entre diferentes peças musicaise tipos de música, motivando o utilizador para explorar essas relações;

2. A representação 2D construída automaticamente é útil por si só porque cria um es-paço organizado de forma “intuitiva” que resume um conjunto de dados de elevadadimensão;

3. Playlists “inteligentes” capazes de discernir sobre certos critérios de filtragem econfiguração.

No entanto, nem tudo é bom neste sistema. Entre as principais desvantagens destasolução importa referir a complexidade na compreensão da solução e do modo como fun-ciona a aplicação (referido principalmente para utilizadores dito “normais”); e também,tal como já foi sendo descrito ao longo deste capítulo, não foi essencialmente concebidacom o intuito de visualizar colecções de dimensões elevadas (a aplicação foi testada comum máximo de 500 músicas nos testes com utilizadores). Apresenta também o incon-veniente de não permitir que o utilizador compreenda facilmente a organização da suacolecção pessoal, sem ser através da exploração intensiva desta.

25

Figura 2.9: Interface do LivePlasma.

Em suma, o MusicBox constitui uma forma inovadora de visualizar música e explorarcolecções musicais, e que mostra claramente que existem vantagens resultantes da com-binação entre metadados e conteúdo musical para desenvolver técnicas de visualização decolecções musicais.

LivePlasma

Em 2005, Frederic Vavrille desenvolveu o LivePlasma 14 e disponibilizou-o na internet.O LivePlasma utiliza informações recolhidas da Amazon15 sobre similaridade entre

itens, para criar mapas de similaridade entre artistas (com ligações entre artistas pararealçar as relações entre estes). Esta similaridade entre itens é determinada através doprocessamento dos objectos que os clientes compram em conjunto com outros [37].

Os utilizadores do sistema LivePlasma introduzem o nome do artista, e a aplicaçãoapresenta um mapa com artistas similares. Os utilizadores podem pesquisar, criar outrosmapas, descobrir artistas, bem como guardar e partilhar os seus mapas (figura 2.9).

No entanto, com o LivePlasma, uma das maiores limitações dos algoritmos de filtroscolaborativos torna-se claro: para poder receber recomendações, o utilizar tem que forne-cer ao sistema um artista que este já conheça. Para um sistema como o da Amazon, quefaz as recomendações baseadas nas escolhas de compra ou no que os utilizadores estãoactualmente a ver, esta abordagem faz sentido; porém, e para a navegação em colecçõesmusicais quando estamos à procura de um novo som que não conseguimos descrever fa-cilmente? Um sistema como o LivePlasma, que não tem uma representação do conteúdodo áudio, não consegue fazer este tipo de recomendações.

14http://www.liveplasma.com/, consultado em 07/08/2009.15http://www.amazon.com, consultado em 07/08/2009.

26

Musicovery

Em 2006, Frederic Vavrille expandiu o seu LivePlasma com um serviço denominado Mu-sicovery16.

O Musicovery é um sistema web que permite criar webrádios configuráveis. Esteserviço possui todas as funcionalidades que o seu predecessor - visualizar artistas seme-lhantes como uma rede - mas que possui uma nova e notável funcionalidade: um painelonde os utilizadores podem seleccionar o mood (estado de espírito) pelo qual pretendemcomeçar a pesquisar as músicas.

Musicovery mostra resultados pertinentes em forma de rede (nós ligados entre si) epermite que se ouçam as músicas que estamos a ver (figura 2.10).

Este sistema disponibiliza filtragem por mood, “dançabilidade”, popularidade, ano delançamento e género. Este é um bom exemplo da crescente tendência no surgimento desites que disponibilizam novas formas de ouvir e pesquisar música aos utilizadores. Aabordagem do mood é absolutamente simples: o algoritmo por detrás da interface classi-fica todas as faixas de acordo com duas características qualitativas que podem ser repre-sentadas num espaço a duas dimensões. O utilizador só tem que dizer, “Quero músicasum pouco energéticas, e positivas” e os artistas (músicas) mais próximos são mostrados.Inúmeros modelos clássicos de determinação do mood, tais como o de Russell [55] ouThayer [65], classificam o mood baseado na sua localização num espaço 2D.

O mood de uma peça musical pode ser inferido através de algumas características doáudio, por exemplo, “tempo”, pitch, ritmo, harmonia e melodia. No entanto, não é clarocomo Vavrille realizou o mapeamento entre música e mood, ficando aqui em aberto esteaspecto. De salientar que, porque o mood pode ser inferido automaticamente a partir dapeça musical, e porque providencia uma forma “intuitiva” para os utilizadores de pesqui-sar música, algumas aplicações áudio têm vindo a incluir esta funcionalidade.

O Musicovery resolve o principal problema apontado no seu antecessor: a selecçãoinicial do mood elimina o requisito de escolher inicialmente um artista para começar aexploração, dando um ponto de partida para que os utilizadores explorem a colecção semessa restrição.

No entanto, o Musicovery aparenta apenas utilizar similaridade entre itens baseadanos padrões de compra dos utilizadores; as suas recomendações seriam fortalecidas sefossem combinadas com informação do conteúdo musical.

16http://musicovery.com/, consultado em 07/08/2009

27

Figura 2.10: Interface do Musicovery.

MusicRainbow

O MusicRainbow [50] é um sistema desenvolvido por Pampalk e Goto para explorarcolecções musicais e fazer recomendações, que utiliza a similaridade entre artistas comfundamento base.

A aplicação desenvolvida por Pampalk e Goto determina a similaridade entre artistasextraindo um conjunto de características do áudio usando um algoritmo de “travelingsalesman”. Os artistas são depois colocados num rainbow circle (“arco-íris circular”)(figura 2.11). Os arcos coloridos reflectem o género de cada artista.

Adicionalmente, os autores enriqueceram a interface com informação textual reco-lhida de páginas web dos artistas. Utilizando um Griffin Powermate knob os utilizadorespodem rodar o MusicRainbow e seleccionar os artistas que desejam ouvir (é utilizado ummecanismo de audio summarization para fornecer aos utilizadores uma visão rápida sobrecada artista - este mecanismo é semelhante à criação de snippets para músicas [40]).

Existem três aspectos de realçar neste projecto:

1. A introdução de informação contextual obtida através da web, para combinar coma informação semântica disponível nas músicas (acrescida das características pas-síveis de serem extraídas do áudio);

2. A utilização de audio summarization para permitir rapidamente aos utilizadoresterem uma percepção genérica dos artistas à medida que navegam;

28

Figura 2.11: Interface do MusicRainbow.

3. Os utilizadores navegam ao nível do artista, mas a similaridade do áudio é determi-nado ao nível das faixas musicais.

No entanto, e apesar da sua inovação na interacção com a biblioteca áudio, o Mu-sicRainbow apresenta uma interface um pouco complexa para a compreensão por partedos utilizadores comuns e a necessidade de um dispositivo específico para interagir coma aplicação (Griffin Powermate Knob).

Treemaps

O Treemap é uma técnica de visualização desenvolvida por Schneider and Johnson [63],criada originalmente para visualizar ficheiros num disco rígido. A ideia principal consistiaem ultrapassar a limitação existente nas representações de árvores, onde o espaço para avisualização era utilizado de forma muito ineficiente.

Nos treemaps, todo o espaço para representação é utilizado para visualizar a árvoresubjacente, onde cada nó tem um nome e um determinado tamanho. Cada rectângulo narepresentação do treemap corresponde a um (ou mais) atributos dos dados de entrada (p.ex: o tamanho dos rectângulos folha pode manifestar o tamanho de um ficheiro individual,enquanto o tamanho de rectângulos não folha corresponde à soma de todos os seus filhos).

O treemap é construído através de uma subdivisão recursiva do espaço de visualiza-ção, existindo diversos algoritmos para efectuar esta partição do espaço. As principaistécnicas são:

• Slice-and-dice layoutEste foi o algoritmo de particionamento apresentado originalmente, sendo por issoo mais simples de todos (figura 2.12). Em cada nível, a orientação das linhas muda

29

Figura 2.12: Aplicação do algoritmo Slice-and-dice.

Figura 2.13: Aplicação do algoritmo Squarified Treemap.

(de horizontal para vertical e de vertical para horizontal). A ordem dos nós é man-tida, sendo visualmente demarcada pelas sombras dos rectângulos respectivos. Otamanho de cada rectângulo reflecte a dimensão no nó folha subjacente. No entanto,e apesar da sua estabilidade, apresenta o problema de alguns rectângulos poderemser demasiado “finos” e dificultar a sua “selecção”.

• Squarified Treemaps [5]Este algoritmo é adequado para estruturas de dados hierárquicas de grandes dimen-sões. Apresenta a vantagem de elementos quadrados serem mais fáceis de detectare “seleccionar”, usando dessa forma o espaço de visualização de uma forma maiseficiente, e ultrapassando a limitação do algoritmo original (figura 2.13). Permitetambém que a visualização esteja mais fiel aos dados, no entanto, mudanças na es-trutura subjacente provocam mudanças drásticas na visualização, provocando umavisualização descontinuada da informação. Aplicado em situações onde legibili-dade, usabilidade e actualização de dados são importantes. Apresenta a desvanta-gem da ordem dos nós não ser mantida.

30

Figura 2.14: Aplicação do algoritmo Ordered Treemap.

Figura 2.15: Aplicação do algoritmo Quantum Treemap.

• Ordered Treemaps [4]Esta técnica preserva a ordem dos nós na estrutura em árvore e, colmatando a des-vantagem dos Squarified Treemaps, permite que modificações nos dados sejam fei-tas sem alterações bruscas da visualização (figura 2.14). Apresenta um layout maiscompreensível da informação do que o algoritmo original, embora assuma um com-promisso entre a legibilidade da visualização e a suavidade na modificação dos da-dos.

• Quantum Treemap [4]Baseado directamente no algoritmo dos Ordered Treemaps, foi desenhado para vi-sualizar imagens ou outros elementos indivisíveis, no entanto, ocasionalmente, pro-duz representações menos desejáveis, uma vez que muito espaço é desperdiçado(figura 2.15).

• Spatially Ordered TreemapRecentemente, e com o intuito de aproveitar o facto da posição dos nós não repre-sentar nenhuma característica dos dados, Wood e Dykes [70] desenvolveram umnovo algoritmo com o objectivo de aproveitar esta característica para aumentar alegibilidade dos treemaps. Este algoritmo, baseado no algoritmo Squarified Tree-

31

Figura 2.16: Aplicação do algoritmo Spatially Ordered Treemap.

map [5], tenta ordenar os nós mantendo uma consistência na representação a duasdimensões, relacionando a ordem dos nós com a distância euclidiana à origem (onó do topo esquerdo da visualização). O mapa é assim ordenado de acordo comum factor de similaridade dos nós ao nó do topo esquerdo da representação. Destaforma permite que se possam efectuar pesquisas que envolvam identificar relaçõese tendências nos dados de entrada.

Para além da componente dimensão dos treemaps (e da ordenação espacial introduzidapelos Spatially Ordered Treemaps), a cor e anotações, bem como o bordo dos rectângu-los podem ser utilizados para disponibilizar mais informação acerca dos nós da árvoresubjacente. Numa tentativa de melhorar a satisfação dos utilizadores e a aparência dostreemaps, permitindo que estes compreendessem a informação hierárquica dos treemaps,Wijk e Wetering desenvolveram um algoritmo de visualização, denominado Cushion [67].Este algoritmo tenta tirar partido de como o sistema humano visual está treinado para in-terpretar variações em sombras numa superfície iluminada para desenhar os rectângulosdos nós subjacentes.

Os treemaps têm sido utilizados nas mais diversas abordagens de visualização (p. ex:na aplicação PhotoMesa, um navegador de álbuns de fotografias, utilizando técnicas dezooming e treemaps - figura 2.17)

Em suma, os treemaps permitem representar grandes quantidades de informação nasua visualização a duas dimensões, sendo de fácil compreensão. Os treemaps são adap-táveis tanto para árvores pequenas como muito profundas. Apresentam a vantagem depermitir que os utilizadores tenham uma visão genérica da estrutura de dados subjacente,mais rapidamente do que outras técnicas de visualização (p. ex: visualização tradicionalde nós e arcos – grafos).

32

Figura 2.17: Interface do PhotoMesa.

Embora o algoritmo básico do treemap seja fácil de implementar, existem muitas va-riações, quer no particionamento quer na representação visual, cada uma com as suasvantagens e limitações.

2.1.3 Outros sistemas

Apresentamos aqui alguns sistemas interessantes, que combinam as técnicas apresentadasnas secções anteriores, de RIM e Visualização de Informação.

SPG - Simple Playlist Generator

Pampalk e Gasser apresentam-nos o SPG [49], uma implementação em Java de um gera-dor de playlists, que utiliza métricas de similaridade entre músicas baseadas no conteúdodestas, feedback dado pelo utilizador sobre as músicas que estão a ser tocadas e algumasheurísticas.

Esta aplicação utiliza a técnica de similaridade entre músicas descrita como G1Cem [46]. Esta técnica combina similaridade espectral [41] com informação obtida dosfluctuation patterns [47]. Para criar as playlists aplicaram a heurística D descrita em [51].

O cenário mais simples de utilização desta aplicação consiste no utilizador seleccio-nar uma música a tocar. Depois, o SPG automaticamente gera uma playlist com músicassemelhantes. Basicamente, as músicas que estão próximas das favoritas dos utilizadores elonge daquelas que foram banidas são recomendadas. O feedback dado pelos utilizadoresconsiste em classificar o seu gosto pela música que está a tocar, desta forma, as heurís-ticas utilizadas procuram por músicas semelhantes às preferidas do utilizador, e evita asparecidas com as que foram mal classificadas.

33

Figura 2.18: Interface do SPG.

A interface da aplicação é mostrada na figura 2.18.Além das funcionalidades básicas de tocador de áudio, o SPG permite também a de-

finição de estações de rádio, construídas por exemplo com base no estado de espírito dosutilizadores (músicas favoritas/banidas - mood), e permite ainda controlar a frequênciacom que as músicas de um mesmo artista são tocadas na rádio escolhida nesse momento.

O SPG disponibiliza também um mecanismo manual de classificação das músicas.Esta classificação influencia a frequência com que uma música é tocada na rádio.

Sumariamente, o SPG é um sistema que não necessita de informação adicional paracomparar músicas (além das próprias músicas) e que vai aprendendo os gostos dos utili-zadores à medida que estes vão ouvindo músicas e classificando-as (perfil de utilização).No entanto, esta aprendizagem pode impedir certas músicas de serem tocadas e nunca seconseguir cobrir toda a colecção (porque podem existir músicas que um utilizador gostemenos, mas que não desgoste de todo), questão de certa forma resolvida pela navegaçãofuzzy do Strike-A-Tune [54].

CoMIRVA

Desenvolvido sobre a plataforma Java, com o propósito de ser extensível, o CoMIRVA(Collection of Music Information Retrieval and Visualization Applications) [56], é umaplataforma que disponibiliza mecanismos de RIM, Web Retrieval (através de técnicas deWeb-mining) e de visualização da informação extraída.

A principal inovação desta ferramenta consiste no facto de agrupar algoritmos/soluçõese toolkits, tanto de extracção de características das peças musicais, como de visualização,

34

permitindo desta forma construir aplicações especializadas, sem necessidade de recorrera blocos de software diferentes.

Relativamente aos métodos de RIM implementados, a obtenção de informações doáudio passa, não só pela análise do sinal áudio, mas também pela análise dos metada-dos disponibilizados na música ou extraídos da Web (por exemplo, através de técnicas deWeb-mining ou filtros colaborativos). Entre os métodos disponibilizados importa salien-tar o Co-occurrence Analysis [57], o Term Profile Creation, que calcula algumas métricasusadas em recuperação de texto, de forma a colmatar hits não capturados pela simplesaplicação da técnica e finalmente o Co-occurence Analysis Audio-based Features, técnicabaseada no sinal áudio, onde as características que se podem extrair vão desde as pro-priedades de baixo nível, até algumas de alto nível, como descritores de alto nível quemodelam a estrutura rítmica e o timbre de uma música.

A outra faceta deste toolkit é a disponibilização de mecanismos de visualização de in-formação obtida recorrendo aos métodos descritos anteriormente. De facto, o CoMIRVA,implementa várias técnicas que representam o estado da arte na área de visualização deinformação. As técnicas de visualização mais relevantes são: Smoothed Data Histogram,Self-Organizing Map (SOM), Circled Bars, Circled Fans, Continuous Similarity e Ring

Sunburst.Apesar de ser uma ferramenta com um tempo de vida reduzido, este toolkit é já bas-

tante poderoso, quer no contexto de RIM quer de Visualização de Informação. Reunindodiversos algoritmos de extracção e visualização de características do áudio, esta ferra-menta representa o que de mais actual existe. Também é relevante salientar que a uti-lização de técnicas de Web-mining neste contexto é de grande utilidade porque permiteexplorar outras formas de obtenção e de classificação das peças musicais. Dependendoda finalidade do projecto a desenvolver, toda esta envergadura do CoMIRVA, pode repre-sentar uma desvantagem, uma vez que para se utilizar uma pequena parte da plataforma énecessário importar todo o sistema.

Sumariamente, CoMIRVA apresenta bons princípios, buscando a extensibilidade e fle-xibilidade de utilização, permitindo ser um bom ponto de partida para o desenvolvimentode novas aplicações, tal como a aplicação muscape é exemplo (ver figura 2.19).

2.2 Discussão

Depois de analisados os principais elementos, tanto da área de RIM, como da área deVisualização de Informação, estamos em condições de sintetizar e reflectir sobre a infor-mação recolhida.

35

Figura 2.19: Aplicação Muscape.

2.2.1 RIM

Apesar de todo o trabalho desenvolvido na área de recuperação de informação musical,neste capítulo apresentámos apenas uma versão muito sumária da mesma e levantamosquestões para as quais ainda não existe uma solução devidamente fundamentada:

1. Escalar a pesquisa baseada no conteúdo para milhares/milhões de faixas;

2. Integração (eficiente) de ferramentas e plataformas de Recuperação de Informação(com vista à utilização e criação de standards para que todas as ferramentas e pla-taformas possam cooperar de maneira eficiente)

3. Modelação em torno das preferências do utilizador (utilizar as preferências do uti-lizador para adaptar o sistema a este, facto que já se começa a verificar em algunsdos sistemas actuais);

4. Foco no utilizador - grande parte da investigação realizada nos últimos tempos,tem sido realizada ao nível da engenharia, e poucos estudos foram feitos para com-preender e avaliar a forma como as ferramentas de RIM pode ser utilizadas porcomunidades de não investigadores. Tentar compreender o que um utilizador pre-tende quando está a ouvir música; como é que ouve música, como procura e compramúsica, etc, constituem um conjunto de factores que não têm sido muito estudados,mas que talvez sejam de enorme importância e possam reorientar a área na qual osinvestigadores se devem focar;

5. Melhoria das técnicas de detecção de similaridade entre músicas - as existentes ac-tualmente, tal como já descrito em cima, ainda têm muito que evoluir para atingiremresultados satisfatórios.

36

Analisámos neste capítulo que a extracção e utilização isolada de informação semân-tica associada às músicas não permitem a construção de sistemas melhores. Daí que sejanecessário aproveitar todo o potencial inerente ao conteúdo das faixas musicais. Apre-sentámos estratégias para extracção de características de baixo nível (acústicas), caracte-rísticas de alto nível (p. ex: harmonia, melodia, etc.) e de similaridade. Estas estratégiassão orientadas a fins específicos e convém portanto inferir sobre qual ou quais a utilizarna nossa solução.

Aparece como evidente que a combinação entre metadados e similaridade musical,transparente para o utilizador, sem necessidade de conhecer conceitos externos, é a melhoralternativa para o desenvolvimento da nossa solução. Desta forma, o utilizador não éobrigado a conhecer conceitos de baixo nível, como por exemplo, largura de banda ouintensidade, para poder explorar a sua colecção pessoal.

2.2.2 Visualização de Informação

Neste capítulo analisámos várias soluções para visualização de colecções musicais e dainformação subjacente a estas. Na tabela 2.2 apresentamos um resumo das principaispropriedades dos sistemas e técnicas de visualização analisados.

Como podemos constatar pela análise da tabela estudámos um conjunto variado deaplicações, utilizando vários tipos de técnicas de visualização, desde grafos a SOM’s, eoutras soluções menos padrão como as desenvolvidas no MusicBox ou MusicRainbow.No entanto, todos os trabalhos analisados convergem em determinados pontos-chave ten-tando resolver os mesmos problemas: navegação e visualização de colecções pessoais deforma interactiva e mais fácil do que as convencionais; descobrir músicas e permitir aoutilizador deter uma compreensão global sobre a colecção musical; geração de playlists

automaticamente segundo um conjunto de critérios; utilização de métodos de extracçãode características baseados no conteúdo ou similares, etc.

Porém, e apesar de todos os esforços continuam a existir problemas que não são re-solvidos de uma forma categórica pelos sistemas analisados.

Um facto importante é o da dimensão das bibliotecas utilizadas nestes sistemas. Comose pode observar, existe claramente uma lacuna na visualização de colecções musicais dedimensão elevada, da ordem dos milhares de faixas.

Por outro lado, pelo que se encontra sumarizado na tabela e pela análise que foi feitaaos trabalhos nesta secção, podemos verificar que a cooperação entre as técnicas de ex-tracção de características baseadas no conteúdo e as técnicas de metadados é benéfica,uma vez que dessa forma podemos aproveitar o melhor dos dois lados, para ter sistemas

37

mais eficientes, onde as limitações de cada um dos tipos de técnicas são ultrapassadaspela complementaridade entre elas. A utilização do conteúdo musical apresenta tambéma vantagem adicional de permitir ao utilizador realizar tarefas, que utilizando os mecanis-mos actuais, não conseguiria realizar. Um exemplo é a pesquisa de músicas ou artistassimilares.

A compreensão da globalidade das colecções musicais é outro aspecto que tambémnão é totalmente resolvido com os sistemas descritos. Aliás, algumas soluções apresentamclaramente dificuldade em resolver este problema (p. ex: os sistemas que usam redes),embora consigam resolver outros de uma forma muito atractiva para os utilizadores finais(p. ex: a exploração interactiva). O desenvolvimento de uma técnica que consiga resolveresta questão, claramente será positivo.

Em suma, apesar do trabalho desenvolvido para visualizar e navegar por colecçõesmusicais, existe um conjunto de aspectos que continuam a necessitar de melhoramen-tos, entre estes importa destacar: navegação e exploração da colecção, acompanhado dosrespectivos mecanismos de filtragem; flexibilidade na criação automática de playlists,combinando técnicas de extracção de metadados e baseadas no conteúdo musical.

2.3 Contribuição, Objectivos e Requisitos da Solução Pro-posta

Neste capítulo analisámos o trabalho relacionado com a área de visualização de colec-ções musicais (e de Recuperação de Informação Musical), identificando os problemascom que estas soluções se depararam. No seguimento do levantamento destes problemas,faz sentido reflectir sobre a contribuição e os objectivos a que nos propomos com estadissertação.

Com a nossa solução, pretendemos desenvolver uma abordagem para navegação inte-ractiva de colecções musicais que permita uma compreensão natural e total por parte doutilizador da biblioteca.

Na tabela 2.2 sumarizamos as principais contribuições e objectivos a que nos propo-mos, bem como os respectivos racionais. Pensamos que a concretização de uma aplica-ção que atinja os objectivos enumerados irá proporcionar uma solução para os problemasidentificados nesta secção, e assumir-se como a contribuição que desejamos oferecer comeste trabalho.

Nos próximos parágrafos, finalizamos esta secção com a enumeração dos requisitosque derivam dos objectivos que apresentamos na tabela 2.2. Estes requisitos servem para

38

Sist

emas

/Téc

nica

sTi

pode

Sim

ila-

rida

deT

écni

cas

devi

-su

aliz

ação

Car

acte

ríst

icas

extr

aída

sD

imen

são

dabi

-bl

iote

caPo

ntos

fort

esPo

ntos

frac

osM

odo

dein

te-

racç

ãoSt

rike

-A-T

une

Met

adad

osO

rgan

izaç

ãoba

-se

ada

nase

gmen

-ta

ção

dodi

sco

Gén

ero,

artis

tae

nom

eda

mús

ica

(tex

tual

)

não

defin

ida

(mas

pres

supõ

e-se

que

seja

arbi

trár

ia)

Inte

ract

ivid

ade;

poss

ibili

dade

dede

scob

rir

mús

icas

não

perm

itena

ve-

gaçã

odi

rect

ata

mbo

rfí

sico

+ba

quet

a

Glo

beof

Mus

icC

onte

údo

dam

ú-si

ca(c

arac

terí

sti-

cas

deba

ixo

ní-

vel)

Geo

SOM

(SO

Mes

féri

co)

SSD

(Sta

tisti-

cal

Spec

trum

Des

crip

tors

)

arbi

trár

iain

terf

ace;

open

sour

ce;

vári

as“c

amad

as”

dein

form

ação

falh

asde

nave

ga-

ção;

orga

niza

ção

dom

apa

rato

+te

clad

oco

nven

cion

ais

Play

SOM

Con

teúd

oda

mú-

sica

(car

acte

ríst

i-ca

sde

baix

oní

-ve

l)

SOM

Rhy

thm

Patte

rns

não

defin

ida

mod

osde

sele

c-çã

oag

rupa

men

toda

sm

úsic

asra

to+

tecl

ado

para

sele

ccio

nar

mús

icas

,ou

rato

para

mod

ode

linha

Isla

nds

ofM

usic

Con

teúd

oda

mú-

sica

(car

acte

ríst

i-ca

sde

alto

níve

l)

SOM

+SD

HR

hyth

mPa

ttern

snã

ode

finid

a(m

aste

stad

aco

mce

rca

de40

0m

úsic

as)

inte

rfac

eap

ela-

tiva

efa

mili

arco

mpl

exid

ade

dos

algo

ritm

osut

iliza

dos

rato

+te

clad

opa

rase

lecç

ãode

mús

icas

Isla

nds

ofM

usic

3DC

onte

údo

dam

ú-si

ca(c

arac

terí

sti-

cas

deba

ixo

ní-

vel)

+m

etad

ados

(web

retr

ieva

l)

SOM

+SD

Hpa

rape

rfil3

DR

hyth

mPa

ttern

ste

stad

aco

mbi

bli-

otec

are

duzi

dana

vega

ção

inov

a-do

rave

rsão

3Dde

Is-

land

sof

Mus

icG

ame

Pad

Mus

icB

oxC

onte

údo

dam

ú-si

ca(c

arac

terí

sti-

cas

deba

ixo

níve

l+

sum

ariz

ação

doáu

dio)

+m

etad

a-do

s(w

ebre

trie

-va

l)

Map

eam

ento

noes

paço

2Dse

gund

oum

conj

unto

decr

itéri

os

Tim

bre,

Pitc

h,et

cre

duzi

da(a

plic

aem

500

mús

icas

máx

imo)

inte

rfac

ee

inte

-ra

cção

inov

ador

a;cr

iaçã

ode

play

-lis

tsau

tom

átic

asim

pelin

doo

utili

-za

dor

ade

scob

rir

mús

icas

com

plex

idad

ena

com

pree

nsão

dain

terf

ace

efu

nci-

onam

ento

daap

li-ca

ção

rato

+te

clad

oco

nven

cion

ais

Liv

ePla

sma

Met

adad

osR

ede

denó

s(g

rafo

)Si

mila

rida

deen

-tr

ear

tista

snã

oin

dica

da,m

asar

bitr

ária

Sim

ilari

dade

dear

tista

sut

iliza

ndo

info

rmaç

ões

extr

aída

sda

Am

azon

Lim

itaçõ

esda

sté

cnic

asde

filtr

osco

labo

rativ

os

rato

+te

clad

oco

nven

cion

ais

Mus

icov

ery

Met

adad

osR

ede

nós

(gra

fo)

Sim

ilari

dade

en-

tre

artis

tas

não

indi

cada

,mas

arbi

trár

iaM

apea

men

todo

moo

dnu

mes

paço

2Dpa

raor

ient

ara

nave

-ga

ção

Ape

nas

utili

zare

-co

men

daçõ

esba

-se

adas

entr

esi

-m

ilari

dade

entr

eite

ms

(met

adad

ose

não

cont

eúdo

)

rato

+te

clad

oco

nven

cion

ais

Mus

icR

ainb

owC

onte

údo

mús

ica

Rai

nbow

Cir

cle

Sim

ilari

dade

en-

tre

artis

tas

não

indi

cada

,mas

arbi

trár

iaU

tiliz

ação

deau

dio

sum

-m

ariz

atio

n;m

ecan

ism

osde

web

retr

ie-

val;

inte

rfac

ein

ovad

ora

com

plex

idad

ena

com

pree

nsão

daco

lecç

ãom

usi-

cal;

nece

ssid

ade

dedi

spos

itivo

dein

tera

cção

adic

iona

l

Gri

ffin

Pow

er-

mat

ekn

ob

Tabe

la2.

1:A

nális

eco

mpa

rativ

aen

tre

ossi

stem

ase

técn

icas

devi

sual

izaç

ãode

scri

tos.

39

Objectivo RacionalVisualização interactiva Desenvolver ou aplicar técnicas de visualização

que permitam visualizar a colecção musical sobvárias perspectivas, de modo a ter uma compreen-são total sobre a colecção musical

Filtragem dinâmica Conjugar filtros baseados em metadados e similari-dade musical, que permitam filtrar dinamicamentee em tempo real a colecção de acordo com os cri-térios seleccionados

Criação de Playlists Controlo fino sobre a criação de playlists disponi-bilizando várias alternativas para as construir: ma-nual, automática (utilizando filtragem e similari-dade)

Preview de músicas “conhecer” músicas, ouvindo excertos representa-tivos das músicas (p. ex: o refrão)

Tabela 2.2: Objectivos para a solução proposta.

especificar o comportamento da solução final e descrever a interacção possível com amesma.

Em relação à navegação interactiva, a visualização e exploração deve ser garantida viamovimentos com o rato e teclado. Esta navegação permitirá a visualização de milhares defaixas musicais, conseguindo simultaneamente que o utilizador tenha uma visão global dasua biblioteca.

A filtragem dinâmica deve permitir ao utilizador seleccionar um conjunto de critériosde filtragem, combinando-os de forma a restringir a visualização da colecção, encontrandomúsicas que satisfaçam os critérios seleccionados. Este mecanismo permite não só aoutilizador restringir a visualização actual da biblioteca, como também funciona comomecanismo de navegação na biblioteca. Em qualquer momento, o utilizador conseguesaber o número de faixas que está a filtrar, bem como o número de músicas que conseguefiltrar seleccionando um dado filtro.

A criação de playlists deverá permitir dois modos: manual, em que o utilizador podeseleccionar músicas individuais ou de artistas/álbuns; e automática, onde o utilizador se-leccionando um conjunto de filtros poderá depois criar uma playlist automaticamente commúsicas que satisfaçam os critérios.

O preview de músicas permite que o utilizador consiga rapidamente reconhecer, ou in-clusive conhecer, uma música, sem ter de a ouvir ou saltitar até ao refrão. Este mecanismofunciona como uma forma de “visualização” de uma música, álbum ou artista.

40

2.4 Síntese

Neste capítulo realizámos uma análise ao trabalho relacionado das áreas de RIM e deVisualização de Informação, com ênfase nas soluções e técnicas de visualização de co-lecções musicais em formato digital. Esta análise serve de base e ponto de partida para odesenvolvimento da nossa abordagem.

Reflectindo sobre os resultados e observações efectuadas identificamos um conjuntode objectivos, que se atingidos, constituem uma solução para os problemas identificados.Esta solução irá suportar as seguintes funcionalidades: visualização interactiva, filtragemdinâmica e flexibilidade na criação de playlists (manual e automaticamente).

No capítulo seguinte apresentamos os principais resultados do estudo realizado como intuito de compreender quais as necessidades, gostos, hábitos e comportamentos dosutilizadores quando ouvem música e exploram as suas colecções. Este estudo é o primeiropasso no desenvolvimento da nossa solução para que esta se adapte aos requisitos dosutilizadores.

41

Capítulo 3

Estudo com Utilizadores

No capítulo anterior constatámos que embora muito trabalho esteja a ser realizado nasduas áreas de investigação apresentadas, Recuperação de Informação Musical e Visuali-zação de Informação, grande parte da investigação produzida não tem tido como orien-tação principal o utilizador final. Neste âmbito, destacam-se os estudos realizados porCunningham [11] e Lee [31] para compreender as necessidades dos utilizadores, base-ados no trabalho produzido por Downie [15], que definiu um conjunto de categorias denecessidades, fornecendo uma plataforma base para toda a investigação subsequente.

Guiados por esta motivação, e antes de avançarmos com o desenvolvimento da ar-quitectura da nossa solução, realizámos um estudo para determinar os hábitos, gostos,comportamentos e necessidades dos utilizadores quando ouvem música.

O estudo realizado foi composto por duas partes: um questionário online1, e um con-junto de entrevistas presenciais, que decorreram durante o período de 21 a 31 de Janeirode 2009.

Neste capítulo descrevemos os principais resultados do estudo realizado, evidenci-ando que tanto os resultados obtidos a partir dos questionários online, como os resultadosobtidos das entrevistas presenciais se reforçam e complementam. Os resultados indicama necessidade de um sistema automatizado que permita navegar e explorar colecções mu-sicais de uma forma mais eficiente do que a que é oferecida pelas aplicações actuais.

No final, indicamos um conjunto de implicações e considerações a ter em conta nodesenho da nossa solução, que são uma consequência directa deste estudo.

1O questionário pode ser consultado na íntegra no apêndice III

42

3.1 Descrição do estudo

O estudo realizado foi composto por um survey online e um conjunto de sessões presen-ciais. Para estas duas componentes, criámos um questionário estruturado em três partes,cada uma com objectivos diferentes.

A primeira parte foi desenhada para caracterizar os utilizadores, ou seja, compreen-der quem eram os utilizadores (p. ex: características demográficas, gostos, se ouvemmúsica e onde, etc). A segunda parte foi concebida com o objectivo de compreender oshábitos e comportamentos dos utilizadores quando ouvem música e exploram as suas co-lecções. Tentámos descobrir como é que os utilizadores pesquisam música, exploram assuas colecções e constroem playlists. Por fim, na última parte, tentámos não só descobrirnecessidades dos utilizadores quando ouvem música e exploram as suas bibliotecas, mastambém identificar algumas funcionalidades que os utilizadores desejariam, e quais oscritérios para pesquisar/navegar e construir playlists, numa nova aplicação para visualizare explorar colecções musicais.

Tal como já referido, o questionário foi disponibilizado online e contactámos um con-junto de pessoas para responder. A informação necessária foi enviada por correio electró-nico para mailing lists.

Adicionalmente realizámos um conjunto de sessões presenciais, utilizando o mesmoquestionário. Nestas sessões presenciais, para além do simples preenchimento do questi-onário, pedimos aos utilizadores para realizarem um conjunto de tarefas típicas nas suasaplicações áudio de eleição, pensando alto enquanto o faziam. No final realizámos umaentrevista informal para obter comentários e sugestões para a solução.

3.2 Resultados

Recebemos 127 respostas ao questionário online, de um conjunto diversificado de utiliza-dores. Quanto às sessões presenciais, foram realizadas com 10 utilizadores, seleccionadospara serem representativos do grupo de potenciais utilizadores. Os utilizadores escolhi-dos eram de ambos os sexos (6 homens e 4 mulheres) com idades compreendidas entre os20 e 40 anos; tinham colecções de dimensões grandes (mais de 1.000 músicas) e ouviamregularmente música no computador.

Nas próximas subsecções apresentamos os principais resultados dos questionários,comparando e complementando-os com os resultados das sessões presenciais.

43

Figura 3.1: Principais géneros musicais que compõem as colecções dos participantes.

3.2.1 Hábitos e comportamentos dos utilizadores

O conjunto de 127 participantes, que responderam ao questionário online tinha idadescompreendidas entre os 18 e 50 anos. A grande maioria era do sexo masculino (65%); ea maior parte (81%) encontrava-se no intervalo de idades entre os 20 e 29 anos. Quase atotalidade dos inquiridos ouvem música nos computadores pessoais (94%), e elegeram olocal “casa” como o preferido para efectuar essa tarefa (84%).

Em média, 83% dos participantes possuíam uma biblioteca de música digital, sendoque as dimensões variavam entre as 1.000 e 10.000 faixas (40%). Alguns inquiridos,no entanto, afirmaram possuir colecções com mais de 10.000 músicas (17%), facto querevela que a maioria dos utilizadores tem bibliotecas com mais de 1.000 faixas.

Porém, os dados revelam que as colecções não são muito diversificadas. De facto,71% dos utilizadores tem músicas do género Rock, 61% Pop, enquanto que em 3o lugaraparece a música electrónica com apenas 34% (figura 3.1). Com base nestes valores, acre-ditamos que o género não constitui um bom critério para estruturar as colecções pessoaisde música.

Em seguida, tentámos identificar qual o mecanismo que os utilizadores utilizam habi-tualmente para pesquisar as músicas que gostam de ouvir. Os resultados indicam que nãoexiste diferença entre procurar directamente utilizando o sistema de ficheiros (45%) e oprograma que os inquiridos usam para ouvir música (47%). A partir deste facto, pode-mos inferir que as aplicações actuais para organizar as colecções musicais não possuemum mecanismo relevante que se distinga da tradicional estrutura do sistema de ficheiros,existindo aqui uma necessidade a ser resolvida.

O próximo passo foi tentar compreender como é que os utilizadores exploram as suas

44

bibliotecas. Identificámos uma ordem clara sobre a forma como os utilizadores navegampelas suas colecções. O critério Artista foi eleito como o primeiro para iniciar a nave-gação por 64% dos inquiridos, 41% seleccionaram o critério Álbum como o segundo,41% seleccionaram Género como o 3o critério, e 53% o Compositor como o 4o critério.Estes dados reforçam a nossa observação anterior sobre a utilização do género para nave-gar colecções com pouca diversidade. Alguns participantes também referiram que nuncausaram o critério Compositor (usado apenas para música clássica).

Mais de 61% dos participantes usa playlists, sendo que a maioria é criada de formamanual, seleccionando individualmente as faixas (60%). 10% das playlists são criadasusando filtros e diversos mecanismos automáticos (p. ex: smart playlists), enquanto que11% são geradas aleatoriamente.

Outro facto interessante é o de que 57% dos participantes afirma não classificar assuas músicas, não só porque demora tempo, mas também porque têm medo que possaminduzir o programa a não tocar as músicas menos bem classificadas, ou que não sejamincluídas numa possível playlist construída automaticamente. Este facto é interessante echama à atenção sobre os fundamentos de algumas teorias que usam o feedback fornecidopelos utilizadores para adaptar o sistema.

3.2.2 Necessidades e requisitos dos utilizadores

Na última parte do questionário tentámos identificar algumas necessidades e funcionali-dades desejáveis pelos utilizadores para uma nova aplicação de visualização e navegaçãonas colecções musicais.

Os utilizadores ordenaram as funcionalidades sugeridas pela seguinte ordem decres-cente de preferência: pesquisa eficiente de música; navegação interactiva; e criação auto-mática de playlists utilizando um conjunto de critérios.

Em relação à pesquisa de música, (numa lista de escolha múltipla) a maioria dosutilizadores (54%) gostaria de procurar utilizando tags, 48% utilizando o critério mood e46% por similaridade musical (figura 3.2).

Em relação à criação automática de playlists (figura 3.3), mais de 51% dos partici-pantes gostaria de utilizar o género como o principal critério. Este facto deve-se à poucadiversidade das bibliotecas, permitindo desta forma cobrir a maior parte das faixas. Adi-cionalmente, também gostariam de criar playlists através de filtragem por tags (37%) eseleccionando o mood das músicas que pretenderiam ouvir (37%).

Os resultados obtidos a partir do survey online, foram corroborados e reforçados pelasentrevistas presenciais, onde pedimos aos utilizadores para efectuarem algumas tarefas

45

Figura 3.2: Preferências dos utilizadores na pesquisa de músicas.

Figura 3.3: Preferências dos utilizadores na criação de playlists.

nos seus programas áudio de eleição (p. ex: pesquisar na colecção por uma música eanotar o método utilizado) e para responderem ao mesmo questionário, complementadocom uma entrevista informal.

3.3 Implicações de desenho

Após uma reflexão dos resultados descritos, apresentamos um conjunto de princípios dedesenho para as principais categorias que guiaram a concepção da nossa solução: explo-ração interactiva da colecção, criação automática de playlists e pesquisa de músicas.

• Exploração – A navegação na biblioteca musical deverá seguir a ordenação: Ar-tista, Álbum e Género;

• Playlists – Os utilizadores gostam de deter o controlo sobre a criação de playlists

46

de forma a garantir que algumas músicas apareçam na lista. Para providenciar isto,devemos fornecer um mecanismo de filtragem que ajude os utilizadores a selecci-onarem as músicas pretendidas. Esta filtragem pode ser baseada em tags (p. ex:título da música, artista, ano de edição, etc) ou conteúdo musical (p. ex: similari-dade musical);

• Pesquisa – Para satisfazer as necessidades e requisitos dos utilizadores deveremosdisponibilizar pelo menos três tipos de pesquisa:

– usando tags (incluídas nos ficheiros MP3, ou adicionadas manualmente);

– seleccionando o mood (p. ex: música calma, energética, etc.);

– por similaridade musical.

3.4 Síntese

Neste capítulo descrevemos o estudo realizado para determinar os hábitos, necessidadese comportamentos dos utilizadores quando ouvem música e interagem com as suas colec-ções.

Evidenciámos os principais resultados sobre exploração das colecções, criação auto-mática de playlists e pesquisa de música. Os dados processados indicam a necessidadede construir sistemas de navegação e exploração das colecções musicais adaptados e emconformidade com a realidade e as necessidades dos utilizadores. Com base nos resulta-dos definimos três princípios de desenho (para exploração, pesquisa e criação de playlists)que irão fundamentar e guiar a concepção da nossa solução.

No capítulo seguinte apresentamos a solução que propomos para satisfazer os requi-sitos identificados, evidenciando a arquitectura desenhada e o impacto dos resultados ob-tidos no estudo realizado. Abordaremos também em detalhe os componentes da nossasolução, descrevendo a arquitectura interna e enumerando as nossas contribuições.

47

Capítulo 4

A solução

No capítulo anterior evidenciámos os principais resultados do estudo conduzido para de-terminar os hábitos, comportamentos, gostos e necessidades dos utilizadores quando ou-vem música no computador. Estes resultados, e em particular, as implicações de desenhoestabelecidas no final do capítulo, serviram de base para o desenvolvimento da nossasolução.

Neste capítulo apresentamos a arquitectura da nossa solução.Começamos por apresentamos uma vista geral da arquitectura desenhada para o sis-

tema proposto, abordando em concreto os três componentes principais que o compõem: ocomponente de visualização, o componente de recuperação e o componente de extracção.De seguida apresentamos as soluções criadas para os vários componentes, evidenciando asua própria arquitectura e o modelo de comunicação entre os elementos da mesma. Apro-veitamos também para descrever o modelo de dados que adoptámos para os componentes.

4.1 Panorama da solução

A solução que propomos assume o formato de aplicação desktop convencional, que cum-pre os objectivos e requisitos estabelecidos no capítulo 2. Os requisitos identificadospodem ser divididos em três tipos: visualização, recuperação e extracção. Esta separaçãoacabou por ditar as decisões arquitecturais que tomámos.

A figura 4.1 representa uma perspectiva geral da solução proposta.Como se pode observar, decidimos estruturar o sistema em três componentes princi-

pais: componente de visualização, que providencia as diferentes vistas sobre o modelo dedados e os elementos de controlo da aplicação (playlist, tocador áudio, etc); o componentede extracção de informação, responsável tanto pela extracção de informação semântica

48

Figura 4.1: Perspectiva geral da arquitectura.

(tags) como pela extracção de características do conteúdo áudio; e o componente de recu-peração que permite recuperar a informação extraída pelo componente de extracção. Naarquitectura definida, todos os componentes respeitam um modelo orientado a objectos.

Nas subsecções seguintes apresentamos uma descrição mais detalhada sobre cada umdos componentes, evidenciando sempre a ligação e interacção entre eles.

4.1.1 Componentes de Extracção e Recuperação

Tal como evidenciado na análise feita ao trabalho relacionado com a presente dissertação,a combinação de metadados e RIM baseada no conteúdo é benéfica para a construçãode sistemas de visualização de informação musical, e como tal a nossa solução tambémincorpora estas duas vertentes. A extracção de informação é feita na nossa solução a doisníveis: metadados e informação do conteúdo áudio.

Nas secções seguintes introduzimos os componentes de extracção e recuperação deinformação.

Extracção

O componente de extracção de metadados é responsável por extrair todas as informações(textuais) associadas às faixas musicais, como por exemplo, título e duração da faixa,nome do álbum e artista, etc. Estas informações, apesar dos potenciais problemas deinconsistências entre elas, permitem desenvolver um mecanismo de pesquisa textual con-vencional, a visualização de informação sobre as músicas, e ajudar na estruturação dasvistas sobre as colecções musicais (Artista, Álbum, Género) de acordo com as preferên-cias dos utilizadores. Estas informações depois de extraídas são guardadas numa base dedados relacional.

49

Quanto à extracção baseada no conteúdo, e porque o foco da nossa solução é o utili-zador final de sistemas áudio, as informações extraídas do sinal áudio não são caracterís-ticas independentes (à excepção dos casos pontuais do mood e ritmo/beat), mas ao invés,características que permitem detectar a similaridade entre músicas. Este componente éresponsável por determinar para cada faixa um descritor que representa a informação aele associada (informação de similaridade).

Para a determinação da similaridade entre faixas foi utilizada uma versão adaptada dotoolkit CoMIRVA [56], recorrendo à extracção dos fluctuation patterns [47], que permi-tem determinar a similaridade ao nível da melodia e ritmo.

Ambos os tipos de informação são extraídos uma única vez, sendo depois guardadosde forma persistente, para acelerar todas as interacções entre a nossa solução e o utilizador.O componente de extracção apenas é utilizado quando são adicionadas ou removidasfaixas à colecção musical.

Recuperação

O outro componente da parte de RIM é responsável pela recuperação de informação as-sociada às músicas. Este componente permite obter a informação semântica associada àsmúsicas bem como as características extraídas do conteúdo musical.

A recuperação de informação semântica (tags - metadados) tem como principal funci-onalidade guiar a visualização principal, de acordo com as implicações de desenho apre-sentadas no capítulo anterior. Adicionalmente, os elementos das tags são utilizados parafornecer informações adicionais ao utilizador sobre as músicas, álbuns e artistas que estáa ver. Para se obter a informação de cada música (álbum ou artista) existe um objectowrapper que indexa a estrutura que guarda a informação (base de dados), encapsulando aforma como os dados são realmente guardados.

A recuperação de informação do conteúdo musical é mais complexa do que a recu-peração de informação semântica (à excepção das características mood e beat que sãoguardadas na mesma estrutura que as tags para simplificar o desenvolvimento dos filtros).No caso da informação de similaridade, os descritores de dimensão 1200 processadosno componente de extracção são guardados na estrutura de indexação multidimensionalNBTree [20].

Esta estrutura recebe como dados de entrada os descritores calculados na extracçãobaseada no conteúdo, e permite recuperar um conjunto de músicas “parecidas”, cujos

0Considerámos a redução de dimensionalidade dos descritores, por exemplo, com recurso a PCA [30],mas a necessidade de recalcular os descritores de todas as músicas cada vez que uma nova música fosseadicionada, levou-nos a não seguir por este caminho.

50

Figura 4.2: Exemplo de pesquisa de músicas semelhantes na nossa solução.

descritores são semelhantes (figura 4.2). Este é o único elemento que interage directa-mente com o componente de visualização. Como já referido os outros elementos apenassão utilizados quando novas faixas são adicionadas ou removidas da colecção.

Ambos os componentes de extracção e recuperação estão encapsulados em módulosdistintos de forma a potenciar a extensibilidade da nossa solução. Consideramos esteaspecto importante para a nossa solução, uma vez que desta forma é fácil incorporarnovas técnicas de extracção de características e de determinação de similaridade, de umaforma independente do resto da aplicação, de forma a melhorar a solução apresentada.

Os componentes descritos servem de base ao componente de visualização, exploraçãoe navegação da colecção musical. Apresentamos em seguida uma descrição do compo-nente de visualização de informação.

4.1.2 Componente de Visualização

Este componente é o responsável pela gestão da interface e interacção do sistema como utilizador. Existem 3 elementos essenciais neste componente: as duas “vistas” sobrea colecção e o componente de filtragem. Fazem parte deste componente os restanteselementos visíveis na interface: o tocador áudio, o gestor da playlist e o explorador dosistema de ficheiros. Analisamos primeiro as duas “vistas” principais (gestor das vistas)e posteriormente o mecanismo de filtragem e os restantes elementos.

Na “vista” Treemap (figura 4.4) os artistas são representados como rectângulos numtreemap, cujas propriedades (p. ex: dimensões do rectângulo e bordo, fundo) são contro-ladas pelo utilizador. Nesta vista os elementos adjacentes na representação do treemap

estão ordenados por similaridade musical, integrando assim, os dados extraídos no com-ponente de extracção. Por navegação (browsing) com recurso a técnicas de zooming efiltragem (descrita mais abaixo) o utilizador pode explorar a colecção musical.

Na “vista” simples (figura 4.3), a colecção musical é apresentada segundo a forma

51

Figura 4.3: Vista de lista Figura 4.4: Vista de Treemap

tradicional dos sistemas actuais, isto é, numa lista. Esta vista não apresenta aspectosde similaridade, a não ser que tal seja especificado pelo utilizador (p. ex: pesquisarmúsicas semelhantes a outra). Apesar dos problemas já conhecidos deste tipo de técnica,a motivação da existência desta vista é avaliar e comparar a sua utilização em oposição àvisualização principal, na realização do conjunto de tarefas, especificados no capítulo 6de avaliação experimental.

Estas “vistas” apresentam a mesma interface e estão agrupadas num módulo (gestordas vistas), que permite tornar flexível a solução desenvolvida. Desta forma, é possíveldesenvolver e adicionar novas “vistas” à solução, desde que respeitem a interface definidapara interacção com o modelo de informação do MuVis.

Paralelamente às “vistas” descritas, existe um 3o elemento responsável pela filtragem,que interage com as técnicas descritas (ver figura 4.5 à esquerda).

Para além da navegação por browsing/exploração oferecidas pelas técnicas de visu-alização, o módulo de filtragem, permite não só pesquisar por músicas, como tambémnavegar pela colecção, através de sucessivas restrições aplicadas à visualização actual dabiblioteca.

Este componente utiliza tanto as informações de metadados como as extraídas doconteúdo áudio para condicionar a percepção actual sobre a colecção. Os filtros queforam escolhidos para integrar a aplicação são os seguintes: duração, ano, género, mood,beat e similaridade musical. Adicionalmente, o utilizador pode pesquisar utilizando apesquisa textual. Para cada um dos diferentes tipos de filtro, podemos seleccionar váriosvalores, por exemplo, músicas do género Pop ou Rock.

A escolha dos filtros foi orientada pelas implicações do estudo conduzido no capí-tulo 3, mas também condicionada pelos toolkits disponíveis para extrair as informaçõespretendidas.

Os restantes elementos que compõem este componente são o tocador áudio, o gestorda playlist e o explorador do sistema de ficheiros (figura 4.5).

52

Figura 4.5: Interface do MuVis.

O tocador áudio (ver figura 4.5 em baixo) é responsável por tocar as músicas preten-didas pelo utilizador e mostrar informações sobre estas. Existem três modos de tocar asmúsicas na nossa solução: tocar só as músicas que estão na playlist criada; tocar só asmúsicas filtradas na “vista” principal seleccionada; e tocar todas as músicas (filtradas eplaylist).

O gestor da playlist (ver figura 4.5 do lado direito) permite efectuar as operaçõesnormais numa playlist, à excepção da adição de músicas: remover músicas, guardar ecarregar playlists já criadas, ordenar a sequência das músicas a tocar, etc. A adição demúsicas à playlist só pode ser feita a partir do explorador do sistema de ficheiros e das“vistas” lista e treemap.

O explorador do sistema de ficheiros (ver figura 4.5 à esquerda) representa uma vistaconvencional do sistema de ficheiros e a sua motivação é no sentido de incorporar e ouvirmúsicas que não estão na biblioteca musical, e que se podem, ou não, adicionar à colecçãocarregada no MuVis (p. ex: estão num dispositivo externo).

Os componentes que formam este componente são independentes entre si. No entanto,as “vistas” lista e treemap afirmam-se como os elementos principais, uma vez que osrestantes agem e recolhem informação sobre este.

53

4.2 Arquitectura revisitada

Na secção anterior descrevemos genericamente a arquitectura da nossa solução. Comovimos,existem três componentes chave: os componentes de extracção e de recuperação deinformação e o componente de visualização. A articulação destes três elementos garanteo cumprimento dos objectivos identificados no capítulo 2. Relembrando, a nossa soluçãodeve garantir os seguintes objectivos:

• visualização interactiva; filtragem dinâmica; facilidade na criação de playlists epreview de músicas, álbuns e artistas.

Os três componentes que formam a nossa solução assumem uma arquitectura modular,em que cada elemento se assume como um bloco individual. Cada módulo é independentedos outros, na medida em que inclui em si próprio todos os mecanismos necessários aoseu funcionamento. Este tipo de solução traz benefícios que consideramos importantes,quer para os utilizadores, quer para os programadores responsáveis pelo trabalho correnteou futuro.

Para o utilizador, uma arquitectura orientada a módulos é responsável por alguns ga-nhos em usabilidade e naturalidade. Neste tipo de arquitectura é-nos possível desenharuma interface orientada a tarefas bem organizadas espacialmente. Cada módulo afirma-secomo um conjunto espacial de ferramentas, que agrupam operações com os mesmos tiposde objectivos. A arquitectura proposta permite-nos desenhar facilmente interfaces comestas características.

Para o programador, a arquitectura modular tem vantagens claras. O facto de exis-tirem módulos facilmente separáveis e configuráveis permite que se possam construirfacilmente diferentes interfaces e até aplicações. Para tal, basta ao programador variarnos componentes instanciados, na sua configuração ou na organização da interface.

No contexto desta dissertação defendemos uma aplicação desktop que utiliza todosos componentes (e módulos) que criámos nesta arquitectura. A conjugação de todos es-tes elementos permitirá uma exploração mais interactiva e uma maior compreensão dascolecções musicais. No entanto, a arquitectura que propomos permite que o programa-dor possa, no futuro, efectuar alterações à nossa contribuição. Para tal, basta estender oscomponentes existentes adicionando novos módulos, ou mesmo criando aplicações quesuportem apenas um subconjunto dos módulos existentes.

54

Figura 4.6: Diagrama do padrão arquitectural MVC.

4.2.1 Arquitectura Model - View - Controller

Para suportar o modelo de comunicação entre os diferentes componentes e dos módulosexistentes em cada um, optámos por integrar o padrão arquitectural Model - View - Con-

troller (MVC) na arquitectura proposta. Esta arquitectura tem como objectivo separar alógica e os dados do domínio, da interface utilizador. Este padrão arquitectural separaa implementação de uma aplicação em três camadas: dados e regras de domínio (Mo-

del), interface de utilizador (View) e controlo de comunicação entre as duas anteriores(Controller). A camada de dados é responsável por representar a informação e as regrasespecíficas ao domínio da aplicação. A camada de interface de utilizador representa vi-sualmente a camada de dados de domínio e oferece ao utilizador a interacção com estaúltima. A camada de controlo é responsável por interpretar e processar a interacção doutilizador na aplicação de regras mantidas pela camada de dados e, em último caso, aactualizações desta última. A figura 4.6 ilustra a arquitectura MVC 1.

O padrão MVC revelou-se uma boa solução para cumprirmos os seguintes objecti-vos: a independência entre componentes, o modelo de comunicação entre os mesmos ea actualização simultânea de dados internos e sua representação. Nas próximas secçõesiremos descrever a estrutura dos vários componentes da nossa solução, evidenciando adistribuição dos vários módulos pelas camadas do padrão.

1http://java.sun.com/developer/technicalArticles/J2EE/despat/, consultado em 21/10/2009.

55

Figura 4.7: Arquitectura do componente de Extracção de informação.

4.3 Componente de Extracção de informação

Na base da arquitectura descrita, encontra-se o componente de extracção de informação.Este componente, como já foi anteriormente referido é o responsável pela extracção detodas as características essenciais ao funcionamento da aplicação, quer metadados querinformações relativas ao conteúdo musical. A importância deste elemento na arquitecturaadvém do facto de toda a informação necessária ao funcionamento da solução ser inicial-mente processada aqui. Na figura 4.7 podemos ver os módulos base deste componente.

Existem três módulos base neste componente: Feature Extraction Services, que incluibasicamente o Loader da biblioteca e os mecanismos de acesso ao sistema de ficheiros; omódulo de extracção de metadados; e finalmente o módulo de extracção das característi-cas baseadas no conteúdo. Estes dois últimos funcionam como processadores das músicasque são carregadas na aplicação.

Tal como já referido, toda a aplicação foi desenvolvida de acordo com o padrão MVC,sendo que todos os elementos descritos nesta secção fazem parte do modelo da aplicação(Model). Neste componente, o funcionamento básico consiste em carregar a colecçãomusical na aplicação, aplicando um conjunto de processadores às faixas para extrair asinformações necessárias. Este componente é implementado com recurso ao padrão dedesenho Observer. Este padrão é fácil de compreender e de grande utilidade, porquepermite tornar o mecanismo de processamento da biblioteca extensível.

Neste padrão existem dois objectos principais: o elemento observable (que pode serobservado) e o elemento observer (que pode observar). Este padrão funciona num modode registo (lançamento de eventos), em que os observers indicam ao observable que pre-tendem receber notificações de alterações no seu conteúdo. Quando ocorrem modifica-ções no elemento observable, este envia uma indicação (evento) para todos os objectos

56

Figura 4.8: Fluxo do carregamento da colecção musical na solução.

que previamente se tinham registado, para se actualizarem. Na nossa solução, ambosos módulos de extracção de informação (denominados de processadores) são observers,enquanto o Loader é o elemento observable. Desta forma, é possível adicionar e remo-ver novos processadores, bastando para isso implementar a interface comum a todos osprocessadores e registar no observable pretendido.

Descrevemos em seguida o comportamento na nossa solução, aquando do carrega-mento de novas faixas na aplicação, mostrando a aplicação do padrão indicado.

Sumariamente, os módulos de extracção, aqui denominados de observers registam-seno carregador (Loader, denominado de observable) para receberem notificações que in-dicam que novas faixas foram adicionadas à biblioteca (ver figura 4.8 - (1)). O utilizadorindica que pretende carregar novas faixas, especificando a localização destas (2), e essainformação é passada ao controlador de carregamento (3). O controlador processa o pe-dido e recolhe informações sobre as músicas (4). Depois de reunir as informações acercadas músicas (p. ex: localização) envia a informação ao loader (5); os observers são notifi-cados da existência de novas músicas para carregar e iniciam o seu processamento (6, 7),guardando directamente a informação extraída (8) para acelerar o processo. Quando nãoexistirem mais músicas a processar, os processadores informam o Loader que terminaramo seu trabalho e, este por sua vez notifica a interface (9), permitindo ao utilizador saberque as músicas adicionadas já foram processadas e estão totalmente disponíveis na apli-cação (10). Na figura 4.8 vemos os passos do carregamento da biblioteca, evidenciando oponto de extensibilidade da solução.

Os processadores a incluir estão especificados directamente na aplicação, mas é possí-

57

vel adicionar externamente mais através dos elementos de configuração da solução. Destemodo tornamos a aplicação modular e extensível, permitindo adicionar ou remover novosprocessadores para futuros melhoramentos na nossa solução.

4.3.1 Características extraídas

Tal como já referido anteriormente, este componente é responsável pela extracção de me-tadados (tags) e características que reflictam o conteúdo musical. Nas próximas secçõesindicamos quais as características que são extraídas nos dois módulos, apresentando assuas motivações e limitações actuais.

Metadados - Tags

As tags a extrair das músicas, estão directamente ligadas com os filtros disponíveis naaplicação, e consequência dos resultados obtidos no estudo apresentado no capítulo 3. Asprincipais tags extraídas são: duração da música, título da faixa, nome do artista, nomedo álbum, género da música e ano da música.

Embora inicialmente, pretendêssemos que as características mood e beat fossem ex-traídas a partir do conteúdo musical, revelou-se impossível utilizar qualquer mecanismoautomático para o efeito. Como a implementação deste tipo de algoritmos foge ao con-texto da nossa dissertação, decidimos extrair estas informações a partir das tags das músi-cas. Actualmente, os standards de tags (p. ex: ID3 do MP3), possuem informação acercado mood e beat. Porém, a maioria das músicas não possui este campo preenchido: nestescasos, optou-se por um mecanismo aleatório para atribuir um mood e beat às músicas.Fica, no entanto, o registo de que a qualquer momento é possível substituir ou melhorarestes algoritmos, extendendo o componente de extracção de informação.

Content-based

Tal como já referido, a extracção de características isoladas e controladas na solução porparte do utilizador, não é o nosso objectivo, uma vez que a maioria das característicasextraídas do áudio, com excepção de algumas das características de alto nível, não sãobem compreendidas pelos utilizadores finais. Tendo este facto como fundamento, de-cidimos optar pela extracção de características que permitam efectuar comparações desimilaridade entre faixas, a um nível mais alto.

Após a análise de algumas soluções com objectivos semelhantes aos nossos, decidi-mos optar pela extracção dos fluctuation patterns [47]. Esta característica permite detectar

58

similaridade musical ao nível do ritmo e da melodia. Desta forma o utilizador pode efec-tuar pesquisas com base em similaridade, sendo este mecanismo transparente para ele.

Esta opção foi também condicionada pela plataforma de desenvolvimento escolhidapara criar o protótipo que concretiza a nossa solução. Descrevemos esse facto no capítuloseguinte, quando tratarmos de aspectos de concretização da solução aqui apresentada.

Audio Snippet

Thumbnails de imagem e vídeo são frequentemente utilizados como forma de representa-ção visual para permitir uma navegação eficiente de grandes colecções de imagens e clips

de vídeo.De forma semelhante ao que acontece com as imagens e com o vídeo, um snippet

de áudio define-se como sendo a parte mais representativa ou o excerto mais saliente deuma peça musical (geralmente o refrão), que pode ser usado para navegar em colecçõesde grandes dimensões. Esta característica permite atingir o último objectivo indicado nocapítulo 2, relacionado com o preview de músicas, e assim, complementar a visualização/ exploração da colecção musical, permitindo ao utilizador “visualizar” músicas individu-almente.

Existem diversos algoritmos para extracção do snippet de uma música. Importa des-tacar o trabalho de Lu e Zhang [40], que introduz o conceito de segmento mais saliente.O segmento mais saliente é o excerto mais representativo de um clip musical, que ge-ralmente se localiza na parte principal da melodia, e por isso, pode ser usado como umindicador da parte repetitiva desta, constituindo assim o snippet. Testes com utilizado-res mostraram que o algoritmo apresentado funciona bem com a colecção musical utili-zada pelos autores, sendo melhor que outras abordagens, nomeadamente, as apresentadasem [38, 10]. No entanto, um problema detectado foi a existência de alguns snippets ape-nas com excertos instrumentais, uma vez que os utilizadores reportaram a sua preferênciapor snippets com voz.

Porém, o mecanismo apresentado por Lu e Zhang [40] é complexo e pesado compu-tacionalmente. Assim, para que o processamento da colecção musical seja rápido, resol-vemos não utilizar a solução apresentada pelos autores, mas ao invés, implementar umalgoritmo heurístico para determinar o snippet.

O algoritmo consiste em tentar encontrar o refrão, ou uma parte deste, de forma pro-babilística. Para artistas e álbuns, o snippet é definido pela composição dos snippets dasfaixas que pertencem ao artista e álbuns, respectivamente. Apresentamos em seguida umadescrição do algoritmo.

Dependendo da duração da faixa, o algoritmo determina a posição temporal onde

59

potencialmente se inicia o refrão. Esta posição inicial é determinada de acordo com umaobservação empírica que mostra que a maioria das músicas apresenta a seguinte estrutura:

1. Introdução (instrumental)

2. Estrofe

3. Refrão

4. Estrofe

5. Refrão

6. Instrumental

7. Refrão .̇.

Dessa forma, de acordo com a duração da faixa, tenta-se particionar a faixa encon-trando o refrão que se inicia em (3), e que geralmente se encontra a 1/3 | 1/4 da duraçãoda música. A partir dessa posição é extraído o snippet. O snippet resultante da aplicaçãodo algoritmo tem a duração de 12 segundos. Este valor está de acordo com o existentenas soluções actuais que permitem ouvir uma introdução da música: esta introdução variaentre os 10-30 segundos.

O algoritmo foi pré-validado com uma biblioteca de 10.000 músicas de diversos gé-neros musicais, por 5 utilizadores que escolheram 10 músicas aleatoriamente e que repor-taram que 80% dos snippets continham o refrão ou uma parte deste, constituindo assimum bom resultado para um algoritmo de base empírica.

4.4 Componente de Recuperação de Informação

O componente de Recuperação de Informação está intimamente ligado com o componentede extracção descrito na secção anterior. Esta inseparabilidade advém do facto de o com-ponente que aqui vamos descrever ter como base as informações obtidas no componentede recuperação.

Assim, podemos definir o papel deste componente como o de permitir recuperar asinformações e características extraídas no componente de extracção. Esta recuperação,tal como no componente de extracção é feita a dois níveis: metadados e com base noconteúdo das músicas.

Neste componente existem três módulos essenciais (ver figura 4.9): o Retrieval Ma-

nager Services, que engloba os mecanismos genéricos de recuperação de informação e

60

Figura 4.9: Arquitectura do componente de recuperação de informação.

disponibiliza uma interface comum e transparente para efectuar a recuperação; e doismódulos que implementam a recuperação concreta de metadados e as características ba-seadas no conteúdo. Todos os módulos que compõem este componente existem na ca-mada Model do padrão MVC, uma vez que permitem o acesso aos dados e implementama lógica de domínio nesse acesso. Na figura 4.9 podemos ver os módulos apresentados eas suas interacções.

O módulo Retrieval Manager Services disponibiliza uma interface padrão que permiteaceder e recuperar as informações associadas às músicas, resultantes do processamentono componente de extracção. Sendo assim, é possível recuperar dois tipos de informação:tags e características baseadas no conteúdo. Começamos por descrever a recuperação dascaracterísticas baseadas no conteúdo e depois os metadados.

Como referido na secção anterior, optámos pela extracção de características do con-teúdo musical que permitem inferir directamente sobre similaridade musical. Dessa forma,o desenvolvimento do módulo que permite recuperar essa informação foi condicionadopela própria informação. Este componente permite realizar operações que se enquadramem duas categorias: inserção de informação de similaridade musical e obtenção de umconjunto de elementos semelhantes a uma dada pesquisa. As operações da primeira ca-tegoria têm como finalidade registar a informação extraída no componente de extracção.As operações da segunda categoria são as de maior relevância e permitem efectivamenteo desenvolvimento do mecanismo de filtragem por similaridade.

61

Figura 4.10: Fluxo de comunicação na pesquisa de músicas semelhantes.

Este módulo permite que na nossa solução seja possível efectuar pesquisas por simi-laridade musical. Na figura 4.10 mostramos o fluxo de uma interacção para encontrarmúsicas semelhantes a uma escolhida pelo utilizador.

Internamente, este módulo é implementado através do recurso a uma estrutura deindexação multidimensional, a NBTree [12]. Esta estrutura permite realizar pesquisas(KNN query [13, 61]) de similaridade dado um ponto de interrogação. No nosso caso, ospontos correspondem aos fluctuation patterns extraídos no componente de extracção deinformação.

Na NBTree, a determinação de similaridade é feita com recurso ao cálculo da distânciaeuclidiana entre os pontos que representam os elementos. Esta estrutura devolve comoresultado os elementos que estão mais próximos da interrogação pretendida.

Esta estrutura foi escolhida em detrimento de outras opções estudadas (p. ex: clus-

tering), por apresentar as seguintes vantagens: as comparações serem feitas a uma di-mensão, independentemente da dimensão dos elementos que a compõem, e a pela rapidezde resposta às interrogações KNN. Assim, e porque toda a informação necessária, estácalculada à partida, todas as pesquisas por similaridade são praticamente instantâneas.

No módulo descrito, como é possível observar na figura 4.9, não existe apenas umaNBTree, mas sim três, o que permite a recuperação de músicas, álbuns e artistas similares,respectivamente. A gestão das NBTrees é realizada pelo elemento NBTree Manager. Estemódulo é responsável pela manutenção de consistência das NBTrees. Tal como já refe-rido na secção 4.1, o resultado directo da extracção de similaridade resulta num descritor

62

único para músicas. Estendemos este mecanismo para álbuns e artistas, determinando amédia dos descritores das músicas/álbuns que compõem os álbuns e artistas, respectiva-mente. Os descritores das faixas são guardados directamente na NBTree correspondente,no entanto, quando faixas novas são adicionadas é necessário recalcular os descritoresque representam os álbuns e artistas e actualizar essa informação. O algoritmo para pro-cessamento desta informação é o seguinte:

1. Os descritores das faixas são adicionados directamente à NBTree correspondente.

2. Após o primeiro passo é necessário recalcular os descritores dos álbuns e artistasdas faixas inseridas:

(a) Determinar quais os álbuns e artistas que é necessário recalcular (ou calcularsenão existirem)

(b) Para os elementos identificados actualizar os descritores calculando as médiasrespectivas

(c) Se os álbuns e artistas existirem nas NBTrees, actualizam-se os respectivosvalores, caso contrário adicionam-se

Note-se que este algoritmo é executado para conjuntos de músicas adicionadas, e nãopara cada música que é adicionada, sendo assim eficiente, uma vez que depois de todasos descritores serem calculados, não é necessário correr o algoritmo novamente, a nãoser que sejam adicionadas novas faixas. Todas as recuperações de informação dependemapenas da eficiência da estrutura utilizada e não do processamento.

Os metadados das faixas, obtidos a partir do componente anterior, podem ser recupe-rados a partir do último módulo deste componente. Basicamente, este módulo encapsulaa forma como os dados estão guardados e o acesso directo a estes. Este disponibiliza umainterface standard para comunicação com os restantes módulos da solução. Desta formaisolamos este módulo dos restantes, providenciando uma forma limpa de permitir umamanutenção futura deste componente sem necessidade de comprometer os restantes.

Uma vez extraídas as tags no componente de extracção e guardadas na base de dados,todos os pedidos de recuperação desta informação passam por este módulo. Este móduloobtém directamente as tags a partir da base de dados encapsulando-as numa entidadepadrão (AudioMetadata). Este mecanismo permite que o acesso a esta informação sejarelativamente mais rápido do que o constante acesso ao sistema de ficheiros para obtençãodos metadados.

Como foi descrito, os módulos deste componente permitem a recuperação de informa-ção extraída no componente de extracção. A arquitectura deste componente foi desenhada

63

Figura 4.11: Arquitectura geral do componente de visualização de informação.

de forma a permitir um acesso rápido e eficiente aos dados, e ainda assim de uma formaextensível, onde uma manutenção futura seja relativamente fácil.

Na última secção descrevemos os elementos de base ao componente de visualizaçãode informação, evidenciando a sua importância e fluxos de comunicação. Posto isto, esta-mos na posse da informação necessária para compreender o componente de visualização.

4.5 Componente de Visualização de Informação

O último e mais importante componente da arquitectura descrita é o componente de visu-alização de informação. Os principais elementos que compõem este componente são: ogestor das vistas (com as vistas treemap e lista), o gestor de playlists, o tocador áudio, oexplorador do sistema de ficheiros, e as ferramentas de filtragem. A figura 4.11 apresentaa arquitectura geral do componente de visualização de informação, ilustrando a distribui-ção das camadas do padrão MVC pelos diferentes módulos e a comunicação que ocorreentre estes. Descrevemos em seguida o comportamento genérico de cada um dos módulosmencionados.

O gestor de vistas é o módulo responsável pela exploração (browsing) da colecção

64

musical, através da interacção com o utilizador. É neste elemento que residem as vistasdisponibilizadas pela solução para visualizar a colecção musical. Para cada vista existeum controlador associado, responsável por converter as acções do utilizador em pedidosde informação ao modelo ou potenciais modificações. Como o modelo de dados internoé comum às vistas, estas estão sempre sincronizadas, independentemente da filtragemaplicada em cada vista (em caso de alternância pelo utilizador). A camada View é a res-ponsável por captar a interacção e acções do utilizador, enquanto a camada Model guardaa representação interna dos dados sobre a vista. A representação interna é traduzida visu-almente para a camada View.

O gestor de playlist é o elemento responsável pela manipulação da playlist criadaquer manual quer automaticamente. Neste elemento, a playlist não é mais do que umalista de músicas ordenada para ser tocada. Este módulo possui a sua própria interface(View), processador de eventos (Controller) e representação interna da playlist (Model).Neste módulo existem duas vistas: uma simples, que é representada numa lista (semdetalhes), e uma outra mais complexa, semelhante à vista principal lista, que permite umamanipulação mais fina. Qualquer uma delas é suportada pelo mesmo modelo de dados(Model), que representa internamente a playlist. Este elemento recebe pedidos de trêsformas: directamente através da sua interface utilizador, através de eventos gerados nacomunicação com as vistas principais (gestor de vistas), e da interacção com o móduloexplorador do sistema de ficheiros, como é possível ver na figura 4.11.

O tocador de áudio é o elemento que permite tocar as músicas da biblioteca musical.Este elemento possui a sua própria interface (View), o seu modelo de dados (Model), e trêscontroladores (controllers) que concretizam os vários modos de tocar as músicas: faixasfiltradas, playlist criada ou ambas. A interface deste módulo (View) capta a interacçãocom o tocador, podendo o utilizador efectuar um conjunto de operações diferentes: tocara música, parar a música, tocar a próxima música, tocar a música anterior, etc. Estasoperações levam a que eventos de acordo com as operações seleccionadas sejam enviados,e os elementos registados recebam as notificações.

As ferramentas de filtragem permitem filtrar e explorar a colecção musical. Os filtrosexistentes, descritos mais adiante na secção 4.5.4, permitem interactivamente restringira informação da colecção musical visualizada nas vistas principais (View). Estas fer-ramentas interagem directamente com o modelo subjacente às vistas, condicionando ainformação visualizada na interface da vista. Cada um dos filtros disponíveis possui umainterface (View), um modelo (Model) e controlador (Controller). Desta forma, cada filtroé independente dos demais, podendo ser aplicado em qualquer altura e sobre qualquervisualização da colecção. No entanto, todo o potencial deste módulo apenas é revelado

65

quando se combinam os vários filtros, como iremos descrever na secção 4.5.4 sobre fil-tragem dinâmica.

Finalmente, o explorador do sistema de ficheiros é o módulo responsável por permitirque o utilizador explore os seus ficheiros. Este módulo permite que o utilizador possaouvir músicas que não façam parte da sua colecção musical ou então adicioná-las à co-lecção. Este módulo possui uma interface própria (View), onde o sistema de ficheiros évisualizado na sua forma tradicional, em árvore de directorias, e interage essencialmentecom o módulo de gestão de playlist, para ouvir faixas que não fazem parte da colecçãomusical, e com o módulo de processamento de faixas, do componente de extracção de ca-racterísticas, para adicionar faixas à colecção musical, mas não possui modelo de dadospróprio (Model), uma vez que as operações deste módulo são resultado da interacção comoutros módulos.

Nas secções seguintes, vamos dar seguimento à descrição do componente de visua-lização de informação, ao detalhar os módulos que o compõem. Para cada um vamosesclarecer o seu papel, ao evidenciar a sua estrutura interna e o seu comportamento. Comestas secções procuramos descrever com maior clareza as soluções propostas e esclareceros desafios de Engenharia resolvidos.

4.5.1 Gestor das Vistas

O Gestor das Vistas é o módulo responsável por permitir que o utilizador explore inte-ractivamente a sua colecção pessoal, através das técnicas de visualização disponíveis nasolução. Este módulo assume-se como o objecto principal da arquitectura porque todos osrestantes componentes e módulos interagem com ele (principalmente com os elementosda camada Model). O principal objectivo deste módulo é permitir que o utilizador possaexplorar e navegar na sua colecção pessoal. A figura 4.12 representa a estrutura internadeste módulo.

Na camada View deste módulo criámos três objectos que representam visualmente ainterface do módulo, o Manager UI que representa a parte comum da interface, e as vistasde Lista e Treemap. Tal como já referido anteriormente, existem duas vistas (técnicasde visualização) para explorar a colecção musical. Uma simples, onde a biblioteca éapresentada segundo os mecanismos convencionais, numa lista de músicas (List View), eoutra onde a informação musical é projectada num Treemap, que representa os artistasexistentes na colecção musical (Treemap View).

Na vista simples (ver figura 4.3), as músicas são apresentadas de forma tabular, ondeestão discriminadas várias propriedades das músicas (p. ex: nome da música, nome do

66

Figura 4.12: Estrutura interna do módulo Gestor de Vistas.

artista, duração, etc), permitindo filtragens e ordenações. Na vista de treemap (ver figura4.4), os artistas existentes na colecção musical são mapeados directamente para o treemap,ordenado de acordo com a similaridade musical entre artistas e dimensão controlada pordiversos critérios (número de faixas, número de álbuns do artista). Esta vista permiteainda a exploração do artista (através de zooming), visualizando os álbuns e músicas doartista seleccionado e de acordo com os filtros seleccionados. Estas vistas são geridas porum objecto, que em qualquer momento conhece todas as vistas disponíveis e que atravésda interacção com o utilizador é responsável por seleccionar e desenhar a vista escolhidapor este. As vistas têm um conjunto de funcionalidades comuns, disponíveis a partir dainterface utilizador, como por exemplo: pesquisa por similaridade, preview de músicas(álbuns e artistas), e construção da playlist.

Para cada vista existente, existe um controlador associado (Controller). Inicialmente,existia um controlador para as duas vistas porque as operações suportadas na interfaceeram as mesmas, no entanto, como a maneira de formular os pedidos do controlador aoModel eram distintos, devido à natureza das vistas, decidimos associar a cada vista umcontrolador especifico, ganhando assim flexibilidade para que se possam adicionar novasvistas no futuro, com controladores diferentes. O controlador concretiza as regras paracada vista, de forma a implementar as operações referidas no parágrafo anterior. As ope-rações são efectuadas por interacção com os elementos da camada Model deste módulo,

67

Figura 4.13: Vista simples da playlist.

excepto os pedidos relacionados com a playlist, que são redireccionados directamentepara o módulo gestor da playlist.

A camada de dados, neste módulo, é o elemento mais crucial na sua arquitectura esuporta toda a visualização. Como já referido anteriormente, os dados necessários àsvistas (extraídos no componente de extracção de informação 4.3), existem numa basede dados acessível através de um Handler/Wrapper transversal a todos os componentese módulos da solução. Sendo assim, e de forma a optimizar as pesquisas na colecçãoe concretização das operações, em memória residem apenas as restrições e condiçõesaplicadas sobre os dados. Optimizamos assim também o fluxo de comunicação, uma vezque apenas são carregados os dados necessários para serem representados visualmente.Os elementos responsáveis por estas funcionalidades (View Manager Wrapper e Internal

Model Wrapper) interagem com o mecanismo de filtragem para criar as regras e assimindicar às vistas que se devem actualizar.

O maior desafio deste módulo (e da solução) prende-se com a vista de treemap devisualização da colecção musical. Este elemento modela uma nova forma de particio-namento (layout) do treemap, aproveitando informação semântica de similaridade acercados nós (artistas) para desenhar o treemap. Adicionalmente, a modelação das regras emtorno dos dados extraídos sobre a colecção corresponde a um aspecto importante, umavez que torna a solução mais eficiente, e conceptualmente mais elegante e flexível.

4.5.2 Gestor da playlist

O gestor da playlist é o módulo responsável pela concretização das operações ditas nor-mais numa playlist, nomeadamente: remover músicas, guardar e carregar playlists já cri-adas, ordenar a sequência das músicas a tocar, etc. A adição de músicas à playlist só

68

Figura 4.14: Vista de gestão da playlist.

pode ser feita a partir do explorador do sistema de ficheiros e das “vistas” principais, umavez que no contexto da solução não faria sentido disponibilizar esta operação de qualqueroutra forma.

Este módulo apresenta duas vistas sobre a playlist de músicas: uma vista simples,que corresponde a uma lista ordenada de músicas (ver figura 4.13), e uma vista maiscomplexa que permite uma visualização mais descritiva e um conjunto de manipulaçõesnão disponíveis na vista simples (ver figura 4.14).

Na vista simples cada música é representada na forma: “duração+título da faixa+nomedo artista” (semelhante ao que acontece nas aplicações actuais) e as operações disponi-bilizadas englobam as operações genéricas de manipulação da playlist: remover faixas,guardar e carregar playlists. A operação de carregar uma playlist criada previamentesobrepõe-se a playlist que possa existir.

Na vista mais complexa, as músicas são visualizadas numa tabela semelhante à vi-sualização disponibilizada na “vista” principal de lista. Nesta vista, as operações dispo-nibilizadas permitem uma gestão mais fina da playlist. As operações disponibilizadasenglobam: remover faixas; juntar as músicas de uma playlist já existente à playlist actual(append de playlist); re-ordenar a sequência de músicas a tocar, através de vários critérios(duração, nome da faixa, nome do artista, género, etc); ordenação aleatória da playlist.

A criação automática de playlists também é responsabilidade deste módulo. Estemecanismo permite gerar uma playlist automaticamente de acordo com os filtros pre-viamente seleccionados (filtragem dinâmica). Este módulo permite criar playlists queincluam todas as músicas filtradas ou apenas um número restrito. A ordenação da playlist

criada é aleatória.Na figura 4.15 mostramos a estrutura interna deste módulo.Na camada View deste módulo criámos um objecto responsável por representar vi-

sualmente a playlist subjacente. Denominamos este objecto como interface da playlist.

69

Figura 4.15: Estrutura interna do módulo Gestor de Playlist.

Este objecto é capaz de detectar acções do utilizador e convertê-las em pedidos de mo-dificação no modelo de dados interno da playlist e na sua representação. Acoplados aeste objecto existem ainda dois renderers que permitem visualizar a playlist segundo asformas apresentadas nos parágrafos anteriores, lista simples e tabela.

A detecção de acções do utilizador é assegurada por um conjunto de objectos, deno-minados de User Event Handlers, que observam a interface da gestor de playlist e captama interacção do utilizador. Este conjunto de objectos é responsável por criar os eventos deplaylist que correspondem às operações definidas na secção anterior.

Os eventos de playlist que são criados pela camada View são despachados para o únicocontrolador existente neste caso. Este controlador mantém um conjunto de objectos (oucomandos) que subscrevem eventos de playlist.

O maior desafio neste componente consistiu na sincronização entre o modelo de da-dos interno da playlist e nas visualizações independentes deste modelo, ou seja, entre ascamadas Model e View. Adicionalmente, considerámos útil este mecanismo de eventos(ou acontecimentos), uma vez que assim permite que mais controladores interessados nasmodificações recebam notificações quando estas ocorrem. Desta forma, obtemos ganhossignificativos na flexibilidade da solução.

70

Figura 4.16: Interface do tocador de áudio.

4.5.3 Tocador áudio

O tocador áudio é responsável por tocar as músicas da colecção musical pretendidas peloutilizador (ver figura 4.16). Existem três modos de tocar as músicas na nossa solução:tocar só as músicas que estão na playlist criada; tocar apenas as músicas filtradas; e tocartodas as músicas (filtradas e playlist).

Na figura 4.17 mostramos a arquitectura interna deste elemento.Tal como já referido anteriormente, este módulo segue o padrão MVC. Na camada de

View criámos um objecto capaz de representar visualmente o tocador de áudio. Este ob-jecto é responsável pela interacção com o utilizador, permitindo que este efectue um con-junto de operações sobre o módulo, nomeadamente: tocar música (play), pausar música(pause), tocar próxima faixa (next track), tocar faixa anterior (previous track), e gestão dosom. Este componente permite também visualizar informação acerca da música que estáactualmente a ser tocada (painel de informação).

Para cada um dos modos de tocar as músicas referidos anteriormente, as operaçõesindicadas no parágrafo anterior são suportadas. Para isto, existem três controladores quecorrespondem aos diferentes modos. Estes controladores partilham uma interface co-mum, permitindo assim que seja possível adicionar novos modos de funcionamento dotocador. O utilizador, através da interface deste módulo, manipula o controlador activo,e, dessa forma, qual o modo em que pretende tocar as músicas. O controlador activo re-cebe os eventos criados na interface (User Event Handlers) e processa-os, executando oscomandos associados a estes.

Na camada Model deste módulo, criámos um objecto que efectivamente acede aosficheiros do disco e os reproduz. Este é o tocador áudio interno do MuVis (elemento docore da arquitectura). Este objecto apenas tem como função tocar uma faixa. No fluxo decontrolo deste elemento, existe um conjunto de eventos que indicam as operações efectu-adas sobre ele, nomeadamente: música a tocar, música parada (pausa e stop), mudança nosom. Estes eventos são utilizados para efectuar a sincronização entre o modelo de dadose a interface utilizador do controlador.

Os maiores desafios e motivações da arquitectura deste módulo não foram as condici-

71

Figura 4.17: Arquitectura interna do Tocador de Áudio.

Figura 4.18: Exemplo de um filtro no MuVis: duração.

onantes tecnológicas ou a complexidade da solução, mas sim a possibilidade de oferecerao utilizador diferentes formas de tocar as músicas da sua colecção musical, aumentandoo controlo sobre a forma de ouvir as músicas da sua biblioteca.

4.5.4 Ferramentas de filtragem

Este módulo é responsável por permitir ao utilizador filtrar interactivamente a sua colec-ção pessoal e explorá-la, condicionando progressivamente a vista sobre a colecção. Esteelemento disponibiliza 7 filtros base (ver figura 4.18 com o filtro duração da música), no-meadamente: texto (tags: nome da faixa, nome do artista e nome do álbum), similaridademusical (ao nível da música, álbum e artista), duração, ano, género, batida e mood dasmúsicas. A escolha destes filtros é consequência directa das conclusões e implicaçõesapresentadas no estudo com utilizadores apresentado no Capítulo 3.

Escolhidos os filtros a disponibilizar na solução, e para validar que a extracção dos

72

Task User 1 User 2 User 3 User 4 User 5 AverageNumber of ProcessedSongs

6722 2084 1210 2523 12354

Song Length<1 minute 33 17 0 9 101 321-2 minutes 115 33 20 40 266 952-3 minutes 558 126 186 426 1124 5043-4 minutes 2426 558 499 1060 5026 19144-5 minutes 2079 628 347 716 3823 15195-6 minutes 1073 489 118 204 1387 654>6 minutes 438 233 40 68 527 261Song GenreSongs with field 5043 1591 990 1875 9713 3842Identified genres 267 86 32 71 274 146Valid genres 45 60 28 53 40 127Song ArtistSongs with field 5250 1742 1031 2160 10383 4113Unknow artist 2 1 179 249 1565 399Identified artists 1326 276 347 491 2518 992Valid artists 1121 257 331 447 2446 926Song yearSongs with field 4114 1473 832 1769 8129 3263Identified years 59 37 18 23 45 36Valid years 39 35 16 19 32 29

Tabela 4.1: Resultados da inspecção das colecções de cinco utilizadores.

metadados associados aos vários filtros (excepto ao filtro de similaridade) seria útil paracumprirmos os nossos objectivos, realizámos uma pequena análise nas colecções musicaisde cinco utilizadores, de forma a recolher informações que tivessem impacto sobre aorganização da visualização. As bibliotecas foram processadas automaticamente, atravésde um script desenvolvido para o efeito.

A tabela 4.1 resume as propriedades extraídas. Apresentamos uma breve discussãodos resultados e o impacto na especificação dos filtros respectivos.

Quanto ao filtro de duração musical e de acordo com os resultados obtidos na tabela4.1, os principais intervalos observados para especificar as categorias deste filtro são:<2minutos, 3-4minutos, 4-5minutos e > 5minutos.

Quanto ao filtro do ano, a análise das colecções mostrou que aproximadamente 60%das músicas contêm essa informação. Uma inspecção mais detalhada mostrou que prati-camente todas as músicas que têm o campo ano preenchido, este é válido. Com base nestainformação, resolvemos estruturar as categorias deste filtro de acordo com os sistemas ac-tuais (p. ex: o Windows Media Player) que individualizam os 10 anos mais próximos, eos restantes são organizados por décadas.

Quanto aos filtros género e mood, a sua categorização e esquema de cores a usar na

73

interface (para o género) foi feita de acordo com a aplicação Musicovery 2. Esta consi-dera 16 géneros (na análise identificámos uma média de 40 géneros, mas muitos desteseram sub-géneros, considerando-se portanto esta redução adequada) e quatro categoriasde mood (calm, energetic, dark e strong).

Optou-se pela concretização do filtro género a partir das tags não só porque a análiserevelou que mais de 80% das músicas têm esta tag mas também porque foi consideradaválida. A validação deste campo foi realizada através de um algoritmo desenvolvido noreferido script, que descartou tags em branco e desconhecidas, e comparou as restantescom o conjunto de valores válidos para o campo. Fica em aberto a possibilidade de seadicionar novas técnicas para a extracção do género, por exemplo, utilizando técnicasbaseadas no conteúdo musical, adicionando esse comportamento através do mecanismode extensão descrito neste capítulo.

Para o último filtro seleccionado, a batida (beat), pretendemos que o utilizador possacontrolar a escolha do ritmo. As categorias seleccionadas para particionar este filtro são asdefinidas no panorama musical (ver tabela 4.2), indicadas em batidas por minuto (bpm).O utilizador controla assim se deseja músicas mais aceleradas (very fast e fast) ou comum ritmo mais lento (slow ou very slow).

Os resultados revelam que apesar de todos os problemas evidenciados no capítulo 2,existe uma boa taxa de sucesso na extracção de elementos válidos das tags dos ficheirosáudio. Este facto é uma conclusão essencial para o desenvolvimento do trabalho, uma vezque a técnica de visualização principal assenta inicialmente neste tipo de informação.

No parágrafo seguinte descrevemos aprofundadamente o mecanismo de filtragem di-nâmica desenvolvido e a sua arquitectura modular e extensível.

Filtragem dinâmica

A filtragem dinâmica é a solução desenvolvida por nós para filtrar as colecções analisadaspelo MuVis. A sua função genérica, tal como referido no início desta secção é permitirrestringir a vista sobre a colecção, ou seja, reduzir o número de faixas que o utilizadorvê num dado momento, para ver apenas as faixas que cumprem os requisitos (filtros)especificados.

Denominámos este tipo de filtragem, de filtragem dinâmica, porque o utilizador con-trola em qualquer momento os filtros aplicados (a ordem é indiferente para a nossa solu-ção), podendo adicionar filtros e remover outros, vendo as alterações nas vistas de formapraticamente instantânea; controla o número de faixas filtradas e o número de faixas que

2http://www.musicovery.com/, consultado em 07/09/2009.

74

Italian Term English Definition Corresponding Metro-nome Marking

MuVis Category

Larghissimo SlowExtremely Slow 40LentissimoAdagissimo

Largo SlowVery slow 40AdagioLento

Larghetto SlowFairly slow 40

Adagietto

Andante ModerateModerately slow 60

AndantinoModerato Moderately 60 ModerateAllegretto Fairly fast 60 ModerateAllegro Fast, Quick 120 Fast

Vivace FastQuite fast 120VivoPresto

Allegrissimo FastVery fast 208VivacissimoPrestissimo

Tabela 4.2: Categorias utilizadas para o filtro Beat.

vai conseguir filtrar seleccionando um filtro. Para cada tipo de filtro é possível seleccionarmúltiplos valores. Desta forma o utilizador pode interactivamente explorar a sua colecçãomusical, aplicando um conjunto de filtros, mas sempre controlando o estado da bibliotecae com total conhecimento das suas acções.

Este módulo foi desenhado combinando o padrão arquitectural já referido, o MVC,e o padrão de desenho Decorator3. Este padrão tem a particularidade de permitir adici-onar comportamento a um objecto em tempo de execução da aplicação, sem recorrer amecanismos de extensão de objectos, mas sim a mecanismos de composição. Na figura4.19 vemos uma simplificação da execução do padrão aplicado à nossa solução (apenasalguns elementos da arquitectura total da solução). A escolha deste padrão para desenhara estrutura interna deste módulo foi fortemente influenciada pelos critérios de flexibili-dade e extensibilidade reforçados ao longo desta dissertação e pelo que foi descrito nosparágrafos anteriores. Estes objectivos são conseguidos através deste padrão medianteo mecanismo de composição, que permite na nossa solução adicionar e remover filtrosdinamicamente.

Este módulo interage directamente com o componente de recuperação de informação

3http://onjava.com/pub/a/onjava/2003/02/05/decorator.html, consultado em 07/09/2009.

75

Figura 4.19: Aplicação do padrão Decorator no módulo de Filtragem Dinâmica.

(para obter informação quer de similaridade musical, quer metadados), uma vez que estainformação é utilizada para a descrição dos filtros. A importância deste módulo na nossasolução é vital, uma vez que permite não só filtrar as colecções musicais, como simulta-neamente explorar e navegar por elas. Realçamos então aqui, a forte ligação entre esteelemento e o Gestor das Vistas (vistas lista e treemap) já descrito nesta secção.

A representação interna do elemento de filtragem consiste num conjunto de regras erestrições que condicionam os dados a ser mostrados na vista seleccionada pelo utilizador.Este conjunto de regras são aplicadas directamente sobre os dados em bruto (queries SQL)permitindo pesquisas/filtragens rápidas, e não necessitando de um conjunto de objectosde suporte em memória para suportar a navegação e filtragem.

Na figura 4.20 representamos a estrutura interna e os principais elementos deste mó-dulo, distribuídos pelas várias camadas do padrão MVC.

Cada filtro nesta arquitectura funciona como um elemento individual da arquitectura.Assim, cada filtro tem uma interface própria utilizando o mesmo paradigma da visualiza-ção principal em Treemap ordenado (camada View), um controlador associado (camadaController) e um elemento de criação de regras de filtragem (camada Model). Os filtrosde texto e de similaridade possuem interfaces diferentes, mas a restante lógica mantém-se.

Na camada Model existe um objecto, denominado de FilterManager responsável pelacombinação das regras de filtragem geradas pelos vários filtros, e que indica às vistasprincipais que se devem actualizar, para respeitar os critérios seleccionados pelo utiliza-dor.

O maior desafio no desenvolvimento desta solução consistiu na extensibilidade deaplicação dos filtros de forma a permitir ao utilizador controlar sempre o sistema e asmúsicas da colecção que está a ver.

76

Figura 4.20: Arquitectura interna das ferramentas de filtragem.

4.5.5 Explorador do sistema de ficheiros

O explorador do sistema de ficheiros é o último módulo que compõe o componente devisualização de informação (ver figura 4.21). Este módulo tem a responsabilidade depermitir ao utilizador explorar os seus ficheiros e a sua colecção do ponto de vista dahierarquia do sistema de ficheiros do sistema operativo (SO), ou seja, representa umavista convencional, em árvore, da hierarquia de directorias do SO. A motivação princi-pal do desenvolvimento deste elemento, foi no sentido de o utilizador poder directamenteincorporar e/ou ouvir músicas que não estão na sua colecção musical (p. ex: músicasadquiridas recentemente, músicas de um dispositivo externo, etc). Assim, o utilizadorpode ouvir músicas que estão fora da sua colecção, e se pretender pode adicioná-las. Nocaso de o utilizador adicionar novas músicas à biblioteca do MuVis, estas passam portodo o pipeline de extracção de características (ver componente de extracção de informa-ção, capítulo 4.3), estando depois disponíveis na aplicação e visíveis nas vistas sobre acolecção.

Na figura 4.22 representamos a estrutura interna e os principais elementos deste mó-dulo, distribuídos pelas várias camadas da arquitectura MVC.

O explorador do sistema de ficheiros, possui uma interface utilizador própria (View),

77

Figura 4.21: Explorador do sistema de ficheiros.

onde o sistema de ficheiros do SO e da colecção é visualizado na sua forma tradicional,em árvore de directorias. A interface permite navegar no sistema de ficheiros de forma apermitir ao utilizador encontrar as músicas que pretende e disponibiliza um conjunto deoperações: adicionar a música à colecção, iniciando o pipeline de extracção de caracte-rísticas; preview da música, usando o sistema de snippets apresentado na secção anterior(extracção de snippet); e ouvir a(s) música(s) pretendida(s) no tocador áudio do MuVis(as músicas são adicionadas à playlist e só depois podem ser tocadas).

Associado à interface, na camada Controller existe um objecto, que concretiza asfuncionalidades oferecidas pela interface. Este elemento recebe os eventos gerados pelainterface e encapsula os pedidos de forma a serem processados no modelo da solução.Porque este módulo não necessita de elementos que constituam a camada Model do pa-drão MVC, o controlador interage directamente com os módulos necessários dos outroscomponentes, nomeadamente: com o módulo de gestão de playlist, para ouvir as faixasque não fazem parte da colecção; e com o módulo de processamento de faixas do com-ponente de extracção de características, para adicionar músicas à colecção ou efectuarpreviews das mesmas.

Os maiores desafios e motivações da arquitectura deste módulo não foram as con-dicionantes tecnológicas ou a complexidade da solução, mas sim, possibilitar a “pré-visualização” e integração de novas faixas na solução que o utilizador possui, porqueuma colecção musical não é estanque.

78

Figura 4.22: Estrutura interna do módulo do Explorador do sistema de ficheiros.

4.6 Interface da Aplicação - Protótipo não funcional

Um dos passos no desenvolvimento da nossa solução, consistiu no desenho da interfacedo protótipo. Neste sentido, e para prevenir potenciais problemas de usabilidade numafase mais avançada da aplicação, elaborámos um conjunto de desenhos que representamos principais elementos da interface do sistema (protótipo de baixa fidelidade).

Após o desenvolvimento da arquitectura base da nossa solução, e com base nos prin-cípios de desenho retirados do estudo com utilizadores apresentado no capítulo 3, desen-volvemos um conjunto de esboços da nossa aplicação protótipo. Os princípios de desenhoretirados do estudo relativamente à navegação da colecção e pesquisa de músicas tiveramum impacto directo na interface desenvolvida.

Em relação à navegação, esta foi simplificada apenas para dois níveis: vista de artista(ver figuras 4.23 e 4.24 para a versão inicial e final, respectivamente) e vista de álbum(ver figuras 4.25 e 4.26 para a versão inicial e final, respectivamente), enquanto o critériogénero foi passado para um filtro. Esta simplificação permite uma interacção rápida coma aplicação, guiada pelas preferências dos utilizadores.

Quanto à pesquisa de músicas e criação de playlists, foram também influenciadaspelos resultados do estudo. A criação de playlists e pesquisa foram simplificadas ecombinam-se. Para criar playlists, o utilizador apenas necessita de filtrar / pesquisar pelasmúsicas que pretende e depois apenas tem que seleccionar a opção de criar playlist (ver

79

Figura 4.23: Versão inicial da interface utilizador.

figuras 4.27 e 4.28 para a versão inicial e final, respectivamente). Tanto a filtragem comoa criação de playlists respeitam as orientações e preferências dos utilizadores.

Estes protótipos de baixa fidelidade foram testados com dois utilizadores sofrendoconsecutivas refinações até atingir um ponto de estabilidade. Assim, foi possível estru-turar a interface de forma a definir o fluxo de informação e ecrãs da aplicação protótipo,para ser usável pelo utilizador e corresponder às suas expectativas.

4.7 Síntese

Neste capítulo descrevemos os elementos que compõem a arquitectura da nossa solução:componentes de extracção, recuperação e visualização de informação. Descrevemos aarquitectura interna de cada componente evidenciando a comunicação entre os compo-nentes e seus módulos para funcionamento da nossa solução.

Apresentámos ainda as principais motivações no desenvolvimento dos vários compo-nentes e módulos, e os principais desafios que enfrentámos.

No próximo capítulo iremos descrever alguns aspectos relacionados com a concretiza-ção da solução, e implementação de um protótipo funcional com a arquitectura subjacentedescrita nos dois últimos capítulos.

80

Figura 4.24: Versão final da interface utilizador.

Figura 4.25: Versão inicial da interface da inspecção de artista (zoom do treemap).

Figura 4.26: Versão final da interface da inspecção de artista (zoom do treemap).

81

Figura 4.27: Versão inicial da interface de criação de playlists.

Figura 4.28: Versão inicial da interface de criação de playlists.

82

Capítulo 5

Concretização da solução

No capítulo anterior descrevemos aprofundadamente a arquitectura da nossa solução,mostrando o funcionamento de cada um dos elementos que a compõe, e as interacçõese fluxos de dados entre estes para o funcionamento global da nossa solução.

Neste capítulo descrevemos alguns aspectos técnicos e condicionantes do protótipodesenvolvido para testar a nossa solução.

Começamos por justificar a escolha da plataforma de desenvolvimento do protótipo eapresentamos as principais justificações e decisões na construção da aplicação, como porexemplo, o modelo de dados desenvolvido.

5.1 Plataforma de desenvolvimento

Depois de definida a arquitectura para a nossa solução, vimo-nos confrontados com a deci-são sobre a plataforma de desenvolvimento indicada para o protótipo da aplicação MuVise respectivos componentes. Decidimos tomar como principais critérios os seguintes: aportabilidade da plataforma de desenvolvimento, a existência de toolkits para extracçãode características baseadas no conteúdo áudio, e o suporte da plataforma para a criaçãoda técnica de visualização principal (Treemap).

Para avaliar o desempenho das plataformas candidatas, criámos protótipos simples,para extracção de características e visualização de treemaps. Estes protótipos foram con-cretizados nas seguintes plataformas de desenvolvimento de aplicações: Java, Adobe Air

e Java + Processing.Os testes realizados nestes protótipos simples, consistiam em determinar a facilidade

de criação e manipulação de treemaps em tempo real e de extracção de características. Aaplicação em Adobe Air, apesar de ser a que visualmente apresentou uma interacção maisfácil, acabou por ser descartada porque a integração com mecanismos de recuperação

83

baseados no conteúdo revelou-se difícil e relativamente lenta, uma vez que não existequalquer biblioteca implementada para esse fim, sendo necessário, por exemplo, recorrer abibliotecas adaptadas de Java, e a um modelo de comunicação não orientado a aplicaçõesdesktop.

A escolha de Java acabou por ser a mais fiável e adequada, uma vez que a framework

Processing ainda se encontra num estado de maturidade inicial e algo restritivo, apresen-tando inúmeras limitações quanto ao desenho da aplicação e reutilização de elementosnecessários à criação de qualquer aplicação, o que condicionaria o desenvolvimento rá-pido do protótipo.

A plataforma escolhida (Java) apresentou uma boa portabilidade (nesta altura a apli-cação MuVis é suportada nos sistemas operativos Linux, Windows e MacOSX), um con-junto diversificado de toolkits para extracção de características das faixas musicais, e aexistência de várias bibliotecas para criação de treemaps com relativa facilidade e exten-sibilidade.

5.2 Arquitectura da Vista de Treemap

A arquitectura do Treemap foi implementada sobre a biblioteca SfTreemap1 desenvolvidapor Bouthier. Dentre as três alternativas consideradas (SfTreemap, JTreemap2 e Prefuse3),o factor que influenciou a escolha desta biblioteca em detrimento das outras foi o facto desuportar a manipulação da representação em árvore interactivamente. Toda a informaçãonecessária à construção e manutenção do treemap encontra-se em memória, permitindoassim uma manipulação mais flexível dos dados. Assim, a implementação do mecanismode filtragem dinâmica pode ser realizada de uma forma mais natural.

Esta biblioteca foi desenhada de forma a ser extensível em vários pontos, nomeada-mente: nós do treemap, tamanho do rectângulo associado a cada nó da árvore, forma dedesenho de cada rectângulo (filling, tooltip, etc) e finalmente, o algoritmo de particiona-mento (layout) de todo o treemap (ver secção 5.2.1). Na nossa solução utilizamos todosos pontos de extensão oferecidos pela ferramenta de suporte. Seguimos com uma descri-ção mais pormenorizada da vista de treemap estabelecendo a ligação com os pontos deextensão aqui identificados.

Na vista de Treemap cada artista existente na colecção musical carregada na aplica-ção protótipo é mapeado directamente no Treemap, ou seja, cada rectângulo visível na

1http://treemap.sf.net/, consultado em 01/09/2009.2http://jtreemap.sourceforge.net/, consultado em 01/09/2009.3http://prefuse.org/, consultado em 01/09/2009.

84

interface corresponde a um artista da colecção (os artistas representam os nós da árvoresubjacente ao treemap). O algoritmo de particionamento implementado, baseado no algo-ritmo descrito na secção de trabalho relacionado, treemap ordenado com posição espacial,permite tirar partido de informações do conteúdo musical para desenhar o treemap. Es-colhido o artista a ser representado no canto superior do lado esquerdo do treemap (nópivô), todos os outros nós (artistas) são dispostos de acordo com a similaridade destespara o artista pivô. Esta similaridade é determinada directamente a partir das caracterís-ticas extraídas no componente de extracção de informação. Assim, o utilizador consegueter uma maior compreensão da sua colecção pessoal, e da similaridade entre os artistas(álbuns e músicas) que a compõem.

A dimensão de cada nó da árvore é controlada pelo utilizador, e existem três modosdisponíveis: igual para todos os artistas, número total de faixas e número de álbuns doartista. Quanto à forma de desenhar cada rectângulo do treemap, existem também trêsformas definidas: cores (de acordo com o género típico do artista, recorrendo ao esquemade cores utilizado no sistema Musicovery); capas dos álbuns, se disponíveis; e combina-ção das duas formas referidas. Cada rectângulo permite ainda que o utilizador saiba emqualquer momento o número de faixas e álbuns de cada artista que estão filtradas. Deforma similar, o nó que engloba todos os artistas, permite saber o número de faixas eálbuns de todos os artistas que estão filtradas.

No seguimento da implementação do nosso protótipo funcional, adaptámos ainda abiblioteca de treemaps utilizada, para permitir a selecção e interacção com os vários nós(rectângulos) visíveis. Este mecanismo é partilhado pelo treemap da vista principal epelos treemaps dos vários filtros disponíveis, e permite-nos seleccionar artistas e filtrar acolecção respectivamente.

5.2.1 Algoritmo do Treemap

Aproveitando a extensibilidade oferecida pela biblioteca de suporte ao desenvolvimentodo treemap, descrevemos em seguida o algoritmo de particionamento implementado. Oalgoritmo desenvolvido é baseado no conceito apresentado por Wood e Dykes em [70],de ordenação por similaridade.

No nosso algoritmo, ao invés dos nós do treemap serem organizados pela dimensãodos nós, são distribuídos pela similaridade a um nó pivô. Assim, escolhido um artista paraser o pivô, organizamos a colecção em torno da similaridade a este artista. Decidimosescolher o artista com mais músicas na colecção para pivô, não só por ser um ponto emcomum com os algoritmos de particionamento existentes, mas também por permitir que

85

o layout final da colecção tenha um bom rácio (no tamanho dos rectângulos), facilitandoa selecção dos artistas pelos utilizadores.

Em detalhe, o algoritmo que descrevemos apresenta o funcionamento básico descritono algoritmo Squarified Treemap [5]. A principal diferença consiste na ordenação dosnós a serem desenhados no treemap. Escolhido o artista pivô, o algoritmo procede auma ordenação descendente de similaridade. Após esta ordenação, procede-se ao partici-onamento do rectângulo. Aqui seguimos novamente o algoritmo de squarified treemap,estando a diferença na forma de calcular o tamanho de cada nó. A dimensão de cada nóé calculada com base numa proporção entre a similaridade ao artista pivô e o número defaixas (ou álbuns, se esse modo estiver activo). Nesta proporção, a similaridade é utilizadapara quando ao efectuar uma pesquisa, a ordenação por similaridade permaneça coerente,enquanto, o número de faixas / álbuns que respeitam os critérios de filtragem permitamefectivamente indicar a dimensão dos vários nós do treemap. Esta proporção permitetornar os nós desenhados mais quadrados e assim facilitar a selecção pelo utilizador.

Assim, de uma forma simples, podemos ter um treemap ordenado por similaridademusical, que permite aos utilizadores explorarem as suas colecções, tendo um ponto deorientação na sua navegação.

5.3 Ferramentas de Filtragem

Tal como a vista de treemap, as ferramentas de filtragem, como já referido no capítuloanterior, constituem um dos mecanismos mais complexos desenvolvidos na solução destadissertação.

Este mecanismo, denominado de filtragem dinâmica permite-nos filtrar as músicas dacolecção musical, utilizando um conjunto de filtros pré-concebidos. Referimos no ca-pítulo anterior que estes filtros embora sejam independentes entre si, constituindo blocosindividuais, podem ser combinados para filtrar a colecção musical. Cada filtro implementauma regra (directamente sobre os dados da solução, através de query SQL) que define oseu comportamento, e o gestor de filtros combina as regras existentes em cada momentopara filtrar a colecção. Este módulo tira partido do padrão de desenho Decorator paraconcretizar o mecanismo descrito.

Na figura 5.1 mostramos a arquitectura do elemento de filtragem desenvolvido emUML, com a implementação do padrão Decorator. Através da análise da figura, é possívelcompreender melhor o que descrevemos no capítulo anterior sobre este módulo e o padrãoutilizado.

Cada filtro da solução implementa a interface FilterDecorator que descende da inter-

86

Figura 5.1: Arquitectura do componente de filtragem.

face Filter genérica. O único filtro concreto é o elemento NoFilter cujo comportamentodefinido é não filtrar nada. Este elemento é importante na solução, uma vez que participana composição dos restantes filtros. Os restantes filtros, permitem decorar-se entre si, eassim combinar a filtragem da colecção.

Adicionalmente, é este módulo que permite actualizar as vistas da solução, para sabe-rem que músicas devem mostrar ao utilizador. Para esta funcionalidade, as funções dospadrões getCount* e getFiltered* permitem para cada artista saber o número de músicase álbuns (e quais) que devem ser representados.

5.4 Modelo de dados

Em relação ao modelo de dados, uma vez que não existe qualquer standard para parti-lhar informações sobre colecções musicais, decidimos desenvolver o esquema base dofuncionamento do MuVis de raiz.

Desenhámos o modelo de dados com recurso à técnica criada por Chen [9], denomi-nada de Entity-Relationship (E/R) diagram (diagrama de Entidade-Relação), que aindaque não seja uma técnica recente, continua a ser vastamente utilizada para descrever mo-delos de dados, esquemas de bases de dados, etc.

Nesta técnica, as entidades são definidas como objectos capazes de terem uma existên-cia independente e que podem ser univocamente identificados. Geralmente, as entidades

87

correspondem às abstracções do domínio em causa, por exemplo, elementos físicos ouconceitos do domínio. As relações capturam a forma como duas ou mais entidades serelacionam entre si. Podemos pensar nas relações como “verbos”, ligando dois ou mais“nomes” (entidades).

Na figura 5.2 mostramos o modelo de dados definido de acordo com a técnica E/R.Como se pode constatar existem quatro entidades, que correspondem aos conceitos bási-cos manipulados na solução (artista, álbum, faixa e snippet), e 5 relações que estabelecemas ligações entre os conceitos. Na figura estão também evidenciados os principais atribu-tos associados a cada uma das entidades e relações.

Na construção da aplicação, e como já referido utilizou-se uma base de dados paraguardar toda a informação contida no modelo de dados. Optou-se pela utilização de umabase de dados relacional SQL, não só porque existe um mapeamento praticamente directoentre os elementos que compõem o diagrama E/R e as tabelas na base de dados, mastambém porque as bases de dados relacionais permitem um acesso simples e rápido aosdados, mesmo quando grandes volumes de dados estão envolvidos.

Realizámos uma pequena investigação para escolher qual o motor de base de da-dos mais adequado para os propósitos da nossa solução. Os sistemas analisados foram:MySQL4, PostgreSQL5 e HSQLDB6. Os critérios que influenciaram a escolha foram: ra-pidez no acesso a volumes grandes de informação, e a influência na portabilidade da nossasolução.

Relativamente ao primeiro critério, uma investigação pelos benchmarkings existentes,revelou que todas as soluções estão muito próximas. Sendo assim, o factor que ditou anossa escolha foi a portabilidade da aplicação.

Apesar de todos os motores de base de dados serem multi-plataforma (Linux, Ma-cOSX, Windows, Unix), à excepção do HSQLDB, estas soluções têm que ser instaladasno computador como uma aplicação à parte do nosso protótipo. Dessa forma, o motorescolhido foi o HSQLDB. O HSQLDB pode ser integrado na nossa solução, como maisuma biblioteca adicional, perfeitamente funcional, que aceita pedidos SQL standard talcomo os seus concorrentes. Apresenta a vantagem de estar escrito em Java, não havendo anecessidade de aplicações secundárias ao funcionamento do nosso protótipo. Garantimosassim uma portabilidade a 100% e a não dependência da instalação de componentes third

party.Para finalizar, importa só referir o formato escolhido para guardar e recuperar play-

4http://www.mysql.com/, consultado em 01/09/2009.5http://www.postgresql.org/, consultado em 01/09/2009.6http://hsqldb.org/, consultado em 01/09/2009.

88

Figura 5.2: Modelo de dados do MuVis (diagrama ER).

lists. O formato escolhido foi o M3U. Criado inicialmente pela equipa do Winamp, esteformato é simples e fácil de manipular (a playlist é composta apenas por uma lista dasmúsicas que a compõem), e é utilizado pela grande maioria das aplicações usadas pelosutilizadores actualmente (nomeadamente, Windows Media Player, iTunes, Winamp, Fo-obar2000, Amarok, etc). Garantimos assim que o utilizador é capaz de ouvir as playlists

criadas na aplicação protótipo MuVis, noutras aplicações se o desejar.

5.5 Mecanismos de extracção e recuperação de informa-ção

Os componentes de extracção e recuperação de informação descritos no capítulo 4 foramimplementados com base na adaptação de um conjunto de bibliotecas. Apresentamos emseguida essas modificações.

89

5.5.1 Extracção de informação

Relativamente à extracção de informação a partir das músicas, e tal como já foi referidonos capítulos anteriores, dividimos este processo em duas fases: tags e informação doconteúdo musical.

O processo de extracção de tags foi baseado na biblioteca JAudioTagger7. Este mó-dulo permite aceder às informações textuais embebidas nas músicas de uma forma simplesque foi facilmente integrada na nossa solução. No entanto, para manter a extensibilidadeda nossa aplicação, encapsulámos todos os acessos aos elementos desta biblioteca numconjunto de entidades padronizadas. Assim, podemos mudar a forma de aceder às tags

das músicas, mantendo todo o resto da nossa aplicação intocável.Tal como já referido anteriormente, o mecanismo de extracção de características base-

adas no conteúdo musical foi implementado com recurso à biblioteca CoMIRVA [56]. Emconcreto, desta biblioteca utilizámos o algoritmo de extracção dos fluctuation patterns,um conjunto de características que permitem inferir similaridade entre músicas. Tal comopara a extracção de tags este componente foi encapsulado para permitir extensibilidade.

No entanto, como o mecanismo do CoMIRVA apenas funciona para faixas musicais,resolvemos estender o mecanismo a artistas e álbuns. Assim, tanto os descritores dosálbuns e dos artistas são determinados a partir da média dos elementos que compõem osálbuns e artistas, respectivamente. Os descritores dos álbuns são calculados a partir damédia dos descritores das músicas que fazem parte do álbum, e os descritores dos artistassão determinados a partir da média dos descritores dos álbuns do artista em questão. Destaforma, conseguimos efectuar pesquisas por similaridade, não só por faixas, mas tambémpara artistas e álbuns.

5.5.2 Recuperação de informação

Tal como a extracção de características, também a recuperação foi desenhada para supor-tar o acesso a tags e informação baseada no conteúdo musical.

Em relação à recuperação das tags extraídas, apenas de referir que é realizada peloacesso directo à base de dados que contem a informação.

A recuperação de informação baseada no conteúdo musical, nomeadamente, informa-ção de similaridade é realizada por pesquisas na estrutura multidimensional NBTree [20].Na nossa aplicação adaptámos uma implementação desta estrutura em Java que usa abiblioteca Jdbm8, para guardar de forma persistente as informações de similaridade. Na

7http://www.jthink.net/jaudiotagger/, consultado em 18/09/2009.8http://jdbm.sourceforge.net/, consultado em 07/09/2009.

90

nossa solução existem três NBTrees que permitem efectuar pesquisas de similaridade porartistas, álbuns e músicas. Tal como nos outros mecanismos referidos, encapsulamos oacesso a estas estruturas de forma a não comprometer a extensibilidade da nossa solução.

5.6 Síntese

Neste capítulo descrevemos os aspectos mais técnicos do protótipo desenvolvido que con-cretiza a arquitectura apresentada nos capítulos anteriores.

Apresentamos os principais aspectos que foram condicionados pela arquitectura defi-nida, começando pela própria escolha da plataforma de desenvolvimento, a complexidadee paralelismo no carregamento inicial da biblioteca, o mecanismo de filtragem dinâmicae a visualização e exploração interactiva da colecção musical.

No capítulo seguinte iremos abordar a avaliação realizada ao nosso trabalho e os prin-cipais resultados experimentais obtidos.

91

Capítulo 6

Avaliação Experimental

No capítulo anterior descrevemos alguns aspectos relativos ao protótipo desenvolvido queconcretiza a arquitectura apresentada nos capítulos precedentes.

Neste capítulo abordamos a avaliação realizada ao nosso trabalho e os resultados ex-perimentais obtidos. Começamos por enquadrar os objectivos desta avaliação e enunciaro que pretendemos testar e a forma como o fazemos. De seguida descrevemos em deta-lhe os testes individuais que planeámos e executámos. Terminamos o capítulo com umaanálise e discussão dos resultados obtidos nesta avaliação.

O guião das tarefas utilizado durante a avaliação individual encontra-se no Apêndice I.Os questionários de satisfação apresentados aos utilizadores durante os testes encontram-se no Apêndice II.

6.1 Objectivos

A solução que propomos tem como objectivo principal possibilitar aos utilizadores nave-gar na sua colecção musical, utilizando um mecanismo de filtragem dinâmico, que lhespermita explorar e compreender a sua organização, de uma forma eficaz e rápida. Paratal, desenvolvemos uma solução, que conjuga mecanismos de recuperação de informaçãomusical e visualização de informação para atingir os objectivos apresentados. Partindoda arquitectura apresentada no capítulo 4, implementámos um protótipo que concretiza aarquitectura descrita (alguns aspectos evidenciados no capítulo 5).

A avaliação que descrevemos neste capítulo procura medir o cumprimento dos ob-jectivos descritos no parágrafo anterior (e o final do capítulo 2), através de um conjuntode testes com utilizadores. Nestes testes procurámos medir a eficácia e eficiência dosmecanismos desenvolvidos na nossa solução. Queriamos também validar a eficácia dosmecanismos de filtragem dinâmica e audio snippets, para explorar a colecção musical e

92

“pré-visualizar” músicas, respectivamente. Finalmente, desejávamos registar observaçõessobre a usabilidade da nossa aplicação.

Para podermos comprovar melhor a validade da nossa solução, decidimos incluir nestaavaliação experimental um teste comparativo com outra aplicação, distinta da nossa.Deste modo medimos o mesmo tipo de resultados para ambas as aplicações, podendoassim compará-los e observar eventuais ganhos adquiridos com a nossa solução. Assimsendo seleccionamos a aplicação utilizada pela maioria dos utilizadores para ouvir músicano computador, de acordo com o estudo descrito no Capítulo 3. A aplicação escolhida foio Windows Media Player, integrado no sistema operativo Microsoft Windows.

Durante a avaliação experimental, ambas as aplicações foram utilizadas para executaro mesmo conjunto de tarefas. Deste modo, as tarefas desenhadas tiveram que ser adapta-das para testar os pontos que nós pretendíamos, mas que ao mesmo tempo pudessem serefectuadas nas duas aplicações, para que os resultados fossem passíveis de serem medi-dos. Realçamos no entanto novamente que a criação das tarefas foi difícil e conflituosa,uma vez que a aplicação seleccionada não se encontra suficientemente próxima da nossasolução, em termos de realização das tarefas e cumprimento dos objectivos definidos.

Porém, a não utilização de informação do conteúdo musical, audio snippets e outrosaspectos contemplados na nossa solução, constituem por si só uma mais-valia a considerarnesta avaliação, porque podemos assim testar a real utilidade e satisfação dos utilizado-res. Estes foram confrontados com duas aplicações, com objectivos semelhantes, massoluções distintas. Deste modo, pudemos atestar se o utilizador sente a real necessidadee satisfação com os mecanismos que propomos.

Para verificar os objectivos descritos no início desta secção, medimos diversos as-pectos, como por exemplo, o tempo de execução das tarefas, o número de passos paraefectuar as tarefas, etc. Uma vez que, nesta avaliação, usamos o mesmo guião de tarefas,os critérios tempo de execução de uma tarefa e número de passos para execução da tarefaforam contabilizados para ambas as aplicações. O critério “vista utilizada” também foiconsiderado na avaliação da nossa solução, para validar o cumprimento dos objectivos devisualização. Por outro lado, recorremos a questionários e entrevistas no final da avaliaçãoexperimental para medir a dificuldade e a satisfação do utilizador na execução das tarefasem ambos os casos. Através deste método, procuramos obter uma avaliação subjectivapor parte do utilizador (aceitando-se sugestões de funcionalidades a adicionar na aplica-ção), assim como uma medida da riqueza visual sobre a navegação na biblioteca musical(p. ex: como foi que o utilizador compreendeu a organização da colecção musical).

Como a nossa solução apresenta componentes e mecanismos distintos do Windows

Media Player, utilizámos questionários e entrevistas para medir a importância e as difi-

93

Figura 6.1: Interface do MuVis.

culdades/vantagens trazidas pela presença destes novos componentes. Utilizamos aindaoutras medidas para testar a resposta dos utilizadores face a estes novos componentes,como por exemplo, as vistas utilizadas para executar as tarefas e o recurso ao mecanismode preview de músicas. Estas medidas demonstram a forma como o utilizador recorre aoscomponentes propostos pela nossa solução.

A figura 6.1 ilustra a aplicação MuVis, com um conjunto de filtros seleccionados,enquanto a 6.2 apresenta o Windows Media Player.

A tabela 6.1 enumera as medidas de usabilidade que definimos, confrontadas com orespectivo objectivo e o valor esperado para cada uma. Os valores esperados fornecemuma base de comparação em relação à informação recolhida durante a avaliação expe-rimental. Chegámos a estes valores através da realização de um teste-piloto com umutilizador familiarizado com as aplicações, para tirar o melhor proveito possível de todosos componentes, na execução das tarefas definidas para a avaliação experimental.

Note-se que com o critério relativo às vistas utilizadas pretendemos medir a eficáciana utilização das vistas pelos utilizadores. Assim, podemos inferir sobre a utilidade dasvistas, na realização de cada uma diferentes tarefas, ao percebermos quais as adequadas acada tipo de operação.

Relativamente à usabilidade da solução e alguns critérios não passíveis de uma medi-ção qualitativa, registámos ainda um conjunto de informações acerca de:

94

Medida Objectivo Valores de referênciaTempo de concretização das tarefas Eficácia geral da solução (visualiza-

ção, filtragem, recuperação)2 minutos

Tarefa 1 - 10-15 segundosTarefa 2 - 20-25 segundosTarefa 3 - 30-35 segundosTarefa 4 - 40-45 segundosNúmero de passos para execuçãodas tarefas (cliques necessários)

Eficácia geral da solução (visualiza-ção, filtragem, recuperação)

20

Tarefa 1 - 3Tarefa 2 - 8Tarefa 3 - 4Tarefa 4 - 5Número de ocorrências no recursoa audio snippets

Preview de Músicas 1-2

Tarefa 1 - 1Tarefa 2 - 0Tarefa 3 - 0Tarefa 4 - 1Recurso a filtragem por similari-dade (ocorrências)

Recuperação de Informação 1-2

Tarefa 1 - 1Tarefa 2 - 0Tarefa 3 - 0Tarefa 4 - 1Número de ocorrência de operaçõesde filtragem

Filtragem dinâmica 6-7

Tarefa 1 - 1Tarefa 2 - 4Tarefa 3 - 1Tarefa 4 - 1-2Vista(s) utilizada(s) Visualização da colecção: vistas

utilizadas para realizar as tarefas-

Tarefa 1 - ListaTarefa 2 - Lista + TreemapTarefa 3 - TreemapTarefa 4 - Treemap + Lista

Tabela 6.1: Medidas consideradas na avaliação conduzida.

95

Figura 6.2: Interface do Windows Media Player.

• facilidade na execução das tarefas

• utilização dos diferentes componentes das aplicações (em particular do MuVis)

• compreensão da colecção musical

• interacção e usabilidade da técnica de visualização principal (treemap)

• filtragem potenciada pela conjugação de diversos critérios

6.1.1 Descrição e Execução da avaliação experimental

Cada avaliação consistiu num teste individual, em que o utilizador foi acompanhado porum observador, responsável pela condução do teste. Os participantes tiveram acesso aum computador, com a nossa aplicação (MuVis) e o Windows Media Player previamentepreparadas com uma colecção musical de cerca de 5.000 músicas, de diferentes génerosmusicais (p. ex: rock, pop, reggae, r&b, metal, jazz, etc). O computador utilizado ti-nha as seguintes características: centrino duo (dual core), 2GB de RAM, 250GB HD, ATIMobility Radeon HD 2400, Windows Vista Business Edition e Java 6 update 13. Esta ava-liação experimental foi realizada num ambiente controlado e cómodo para os utilizadores(sugerido pelos resultados obtidos no capítulo 3).

Seleccionámos 10 participantes que representam o perfil do utilizador alvo para onosso sistema (de acordo com o estudo apresentado no capítulo 3). Este tipo de utiliza-dores ouve habitualmente música no seu computador pessoal, e possuem bibliotecas dedimensões elevadas. A nível tecnológico, procurámos pessoas que tinham conhecimentosna óptica do utilizador de informática, em concreto, de utilização de programas para ouvirmúsica.

96

Figura 6.3: Participante a realizar as tarefas no MuVis.

A avaliação experimental consistiu em quatro fases, com a duração aproximada de35/40 minutos. Em primeiro lugar, o observador começou por explicar o contexto e osobjectivos do nosso trabalho. Foi descrito ao utilizador o teste que iria realizar, enun-ciando os passos e resultados esperados. Nesta altura, foram mostrados três objectosinformativos: as tarefas a realizar e dois vídeos de demonstração, um para cada aplicação(10 minutos no total). Em primeiro lugar, foram mostrados os vídeos de demonstraçãodas duas aplicações, e só depois foram realizadas as tarefas.

Os dois passos seguintes na avaliação experimental consistiram na realização das ta-refas apresentadas, em ambas as aplicações. Cada passo foi precedido por um período detreino e adaptação ao programa em questão. Os participantes foram divididos em dois gru-pos. Um grupo usou primeiro o MuVis e depois o Windows Media Player (MuVis/WMP),enquanto o outro usou as aplicações pela ordem inversa (WMP/MuVis). Tomámos estaopção para obter resultados mais fiáveis e ainda estudar se existem diferenças nos resul-tados observados. Nestas fases, o observador registou ainda questões relacionadas comas acções do utilizador, que lhe seriam colocadas posteriormente (20 minutos em média).Note-se que após o período de treino não foram esclarecidas quaisquer dúvidas relativa-mente à utilização das aplicações.

O último passo dos testes com utilizadores consistiu num questionário e numa entre-vista informal. Os participantes preencheram um inquérito (incluído no Apêndice II) queprocurou capturar informação sobre o seu perfil e a experiência realizada. Após a realiza-ção do inquérito, foi ainda conduzida uma curta entrevista aberta, em regime de diálogo.As figuras 6.3 e 6.4 ilustram dois utilizadores a realizar as tarefas pedidas.

97

Figura 6.4: Participante a preencher o questionário de satisfação.

6.2 Análise de Resultados

Nesta secção vamos discutir os resultados da avaliação experimental realizada. Começa-mos por caracterizar os utilizadores que participaram nos testes efectuados, discutindo deseguida os resultados observados.

6.2.1 Utilizadores

Nesta avaliação experimental, contámos com a participação de 10 utilizadores, seis dosexo masculino e quatro do sexo feminino, com idades compreendidas entre os 19 eos 40 anos. Todos os participantes frequentaram (ou frequentam) o Ensino Superior,distribuindo-se por diferentes áreas profissionais: cinco pessoas de Engenharia (Informá-tica e Civil), três de Ciências Sociais e as duas restantes de Ciências da Saúde.

Todos os utilizadores que participaram nesta avaliação utilizam o computador todosos dias, quer para as suas actividades quotidianas, quer para ouvir música. Oito dosparticipantes já utilizaram (ou utilizam) o Windows Media Player para explorar as suascolecções e ouvir música, confirmando-se esta aplicação como uma boa candidata paraa avaliação realizada. Nenhum dos utilizadores tinha contactado com a nossa aplicação,antes destes testes.

6.2.2 Tarefas

A avaliação experimental realizada foi focada na realização de um conjunto de tarefaspelos utilizadores, para que fosse possível o recurso ao máximo de mecanismos que in-cluímos na nossa solução, embora limitados pela utilização do sistema comparativo, queapresenta menos funcionalidades que o nosso.

98

Tarefa Descrição ObjectivoTarefa 1 Encontre a música

Wonderful Tonight doartista Eric Clapton eoiça-a

Pesquisar uma música específica

Tarefa 2 Crie uma playlist com12 músicas da décadade 90, do género Pop ecom uma duração entre3-5 minutos

Aplicar um conjunto de filtros à colec-ção e criar uma playlist

Tarefa 3 Diga o nome do artistacom mais músicas e doartista com mais álbuns

Determinar os artistas com mais músi-cas e com mais álbuns

Tarefa 4 Encontre álbuns seme-lhantes ao primeiro ál-bum do artista commais álbuns

Efectuar filtragens com recurso a simi-laridade entre álbuns

Tabela 6.2: Tarefas da avaliação experimental.

O guião desenvolvido para esta avaliação conta com quatro tarefas de diferentes grausde dificuldade (de forma progressiva). Apresentamos na tabela 6.2 as tarefas definidas eos seus objectivos.

As tarefas indicadas permitem de um modo geral, a utilização dos principais meca-nismos descritos nesta dissertação. A primeira tarefa tem o objectivo de introduzir outilizador ao sistema, mostrando-lhe o mecanismo tradicional de pesquisa textual (tags).Com a tarefa seguinte pretendemos mostrar a utilidade da combinação de filtros de formavisual e rápida, possibilitando a criação automática de playlists. Nas duas últimas tarefas,cobrimos os mecanismos de visualização da colecção (com recurso ao Treemap) e o me-canismo de filtragem por similaridade, de forma a se poder atestar sobre a real utilidadedos mecanismos aplicados.

6.2.3 Tempo de Execução das Tarefas

Durante a avaliação experimental recolhemos o tempo que o utilizador gastou a executarcada uma das tarefas listadas na tabela 6.2 e no Apêndice I. As figuras 6.5 e 6.6 repre-sentam os gráficos da média dos tempos que cada utilizador gastou para cada tarefa e nototal, respectivamente.

Ao observarmos o gráfico da figura 6.5 verificamos que existe uma diferença muito

99

Figura 6.5: Resultados para tempo de execução das tarefas.

considerável no tempo de execução das várias tarefas propostas nos dois sistemas. Se notempo de execução da primeira tarefa as diferenças entre aplicações não são significativas(a tarefa era simples e consistia em encontrar uma música específica). Em relação àsrestantes tarefas, isto já não acontece. De facto, na segunda tarefa, a diferença entreaplicações (nos dois grupos) é de aproximadamente três minutos. Os principais motivosque condicionam estes resultados são vários, mas evidenciam as principais vantagens danossa solução face à outra aplicação.

Estes resultados corroboram o que também foi atestado pelos próprios utilizadoresnos questionários de satisfação (ver na secção respectiva), onde a combinação de filtros ecompreensão da biblioteca não foram fáceis de realizar nem de compreender no WindowsMedia Player, ao contrário do MuVis.

Estes resultados atestam também que a ordem na avaliação dos sistemas não influen-cia o desempenho dos utilizadores na concretização das tarefas. A única excepção cor-responde à pesquisa por similaridade (tarefa 4), onde se nota uma clara diferença entre ogrupo WMP/MuVis e MuVis/WMP. Neste caso, os utilizadores que não tinham utilizadoainda a pesquisa por similaridade do MuVis (apenas viram essa funcionalidade no vídeode demonstração) não se viram condicionados e influenciados na sua pesquisa por simi-laridade; no entanto, a observação da execução destas tarefas mostrou que os utilizadoressentem dificuldade em definir o conceito de similaridade (o que similaridade significapara os utilizadores, p. ex: género, melodia, ritmo, etc.).

100

Figura 6.6: Tempo total na execução das tarefas.

No gráfico da figura 6.6 podemos observar o tempo total de execução das tarefas pe-didas. Aqui confirmamos efectivamente que a realização das tarefas com o MuVis é maisrápida do que no WMP em cerca de 80%. Em média, no MuVis os utilizadores conse-guiram completar as quatro tarefas pedidas em dois minutos, ao contrário do WMP, ondenecessitaram em média de oito minutos. Podemos também observar que os utilizadoresdo grupo WMP/MuVis demoraram mais tempo na execução das tarefas nas duas apli-cações: no WMP porque não estavam conscientes da similaridade e tiveram dificuldadeem compreender a organização da colecção; no MuVis pela frustração (observada pelodesânimo) evidente do tempo demorado para executar as tarefas no outro sistema.

6.2.4 Utilização de componentes

Paralelamente ao tempo de execução das tarefas, registámos um outro conjunto de medi-das, relativas à utilização dos diferentes componentes da nossa aplicação. Esta observa-ção foi condicionada pelos componentes “equivalentes” na aplicação comparativa, sempreque possível.

Em relação ao número de passos necessários para a execução das tarefas, este resul-tado confirma claramente a eficiência da nossa aplicação face ao outro sistema. Enquantona nossa aplicação o número médio de passos necessários à concretização das quatrotarefas foi de 24, no WMP este valor foi o dobro. Estes valores validam as nossas pre-missas de eficiência. Os resultados obtidos através dos questionários também corroboram

101

que o MuVis foi muito mais pronto e rápido a responder aos pedidos, e que o facto detanto a colecção musical como os filtros terem uma percepção espacial e visual, ajuda naexploração, tornando-a mais fácil.

Quanto às vistas utilizadas para executar as tarefas, os resultados foram animadores econfirmam que a visualização em Treemap é adequada e eficaz para visualizar colecçõesmusicais (facto corroborado pela observação realizada nos testes).

Nos dois grupos, a vista de Lista apenas foi utilizada na primeira tarefa, enquanto que avista de Treemap foi a mais utilizada nas restantes tarefas. Este facto confirma a utilidadedesta vista para visualizar e compreender a organização da colecção na sua totalidadee de forma genérica. Pelo contrário, no Windows Media Player, os utilizadores paraconseguirem executar as tarefas precisaram de utilizar pelo menos três vistas diferentes(Faixa, Artista e Álbum), que embora se complementem, dificultam a visualização, umavez que não é possível conjugar em simultâneo a informação das diferentes vistas.

Neste sentido, a vista de Treemap conjugando informação destas diferentes fontes,permite uma exploração interactiva e com um maior controlo por parte do utilizador, comoos resultados evidenciam. A utilização da similaridade para a estruturação do Treemap

contribuiu para este resultado, como os questionários corroboraram.Relativamente à medida sobre o número de operações de filtragem necessárias para

concluir as tarefas, os resultados indicados na figura 6.7 comprovam as premissas deeficácia pretendidas. Para realizar as mesmas tarefas, o número de operações de filtragensnecessárias no WMP é três vezes maior do que as necessárias no MuVis. No MuVis,os valores apresentados estão de acordo com os valores de referência apresentados nasecção anterior. A justificação destes valores, tem como base o potencial da combinaçãode critérios de filtragem disponibilizada pelo MuVis.

Ao contrário do WMP, no MuVis, usando apenas uma vista, é possível combinar vá-rios filtros (com um click para cada filtro) e imediatamente ver os resultados, ao contráriodo WMP, onde a combinação de filtros é ardilosa, difícil de compreender e com algumasrestrições. Este facto é novamente justificado também pelo tempo de execução das tarefasapresentado na secção anterior. Pela observação dos utilizadores na realização das tarefasno WMP, ficou patente a dificuldade em combinar filtros para efectuar simples pesqui-sas, ao contrário do MuVis, onde as operações são feitas de forma simples, “intuitiva”(referida pelos utilizadores nos questionários) e com total controlo.

A funcionalidade de preview foi usada por todos os utilizadores intensivamente, su-perando as expectativas. Os utilizadores utilizaram este mecanismo quando desejavamouvir uma música que não conheciam, ou como ajuda na exploração. Estes ficaram sur-preendidos com a eficácia deste mecanismo, onde na grande maioria das músicas o refrão

102

Figura 6.7: Número de operações de filtragem executadas nas aplicações.

ou uma parte deste é tocado.

6.2.5 Satisfação com o MuVis

Como já referido, a satisfação com o MuVis foi medida através de questionários e entre-vistas. Com recurso a estes métodos, conseguimos averiguar sobre a facilidade, rapidez esimplicidade de execução das tarefas no nosso protótipo, em oposição à outra aplicaçãoutilizada.

Todos os utilizadores inquiridos afirmaram que a execução das tarefas no MuVis foimuito mais fácil do que no sistema comparativo. Motivados pelo facto referido, todosafirmaram também que voltariam a utilizar a nossa aplicação (ao contrário do WMP, ondeapenas 7 dos 10 afirmaram voltar a utilizar a aplicação). Entre as principais razões apon-tadas, importa destacar: as operações serem rápidas de realizar, possuir uma interface“intuitiva” e com filtragens por similaridade; e a compreensão dos vários mecanismos sermuito fácil (ao contrário do WMP).

A pesquisa por similaridade foi apontada como uma vantagem e factor distintivo entreas duas aplicações. Na verdade, este facto ainda é mais realçado pelo facto de os utiliza-dores terem sentido dificuldade em definir o conceito de similaridade para eles, nos doisgrupos de teste.

Os utilizadores de ambos os grupos, embora com maior incidência no grupo Mu-Vis/WMP, mostraram-se particularmente frustrados com o WMP pela difícil combinação

103

Pergunta Muito difícil Difícil Fácil Muito FácilA realização das tarefas foi... - - - -MuVis 0% 0% 40% 60%WMP 0% 100% 0% 0%Criar playlists foi... - - - -MuVis 0% 0% 60% 40%WMP 0% 30% 50% 20%A exploração interactiva da co-lecção musical foi...

- - - -

MuVis 0% 10% 20% 70%WMP 0% 70% 30% 0%Perceber o mecanismo de filtra-gem foi...

- - - -

MuVis 0% 10% 40% 50%WMP 0% 50% 50%A localização das músicas foi... - - - -MuVis 0% 0% 20% 80%WMP 0% 50% 30% 20%

Tabela 6.3: Respostas dos utilizadores ao questionário de satisfação (1).

de filtros (também pelo facto de não permitir pesquisas por similaridade).Quanto ao resumo efectuado pelos utilizadores sobre a colecção musical utilizada du-

rante os testes, as respostas foram muito diversificadas, no entanto, podemos apurar queos utilizadores ficaram com uma ideia global da colecção: quais os principais géneros(Pop, Rock e R&B, etc); que os quadrados/rectângulos ajudaram a ter uma percepçãovisual da colecção; conseguiram identificar os artistas com mais músicas e álbuns, etc;a representação visual dos filtros também ajudaram a compreender a biblioteca (faixasorganizadas por duração, género, etc). Os participantes referiram que no WMP não con-seguiram compreender este tipo de informação, e realçaram que tendo esta informaçãoem mente ajuda na pesquisa por músicas.

A criação de playlists (automática e manual) foi também descrita como muito fácil deutilizar no MuVis, principalmente pelo facto de praticamente em todos os locais da aplica-ção existirem opções de construir uma playlist. Outro aspecto referido pelos utilizadoresé que a sequência filtragem+criação de playlist é adequada a uma utilização simples eprática, em oposição aos complexos mecanismos de geração de playlists automáticas doWMP.

Embora a experiência de utilização do MuVis tenha sido boa na generalidade, os prin-cipais problemas identificados pelos participantes foram os seguintes: a representaçãovisual dos filtros pode constituir um problema, porque os rectângulos podem ser muitopequenos para serem seleccionados (uma solução é a utilização de zoom nos treemaps);os utilizadores todos gostariam de poder “carregar” duas vezes numa música e tocá-la,

104

Pergunta Discordo To-talmente

Discordo Concordo ConcordoTotalmente

A filtragem interactiva é fácil deutilizar...

- - - -

MuVis 0% 0% 40% 60%WMP 30% 70% 0% 0%É fácil compreender a composi-ção da colecção musical

- - - -

MuVis 0% 10% 40% 50%WMP 0% 100% 0% 0%O filtro de similaridade apre-senta boas sugestões

- - - -

MuVis 0% 10% 40% 60%As diferentes formas de criarplaylists são uma mais-valia

- - - -

MuVis 0% 30% 10% 60%A combinação entre vista e fil-tragem é fácil de perceber

- - - -

MuVis 0% 0% 20% 80%

Tabela 6.4: Respostas dos utilizadores ao questionário de satisfação (2).

como acontece nos outros sistemas (este facto foi apontado como um melhoramento, econfirmado pela observação durante o período de testes); finalmente, alguns participantestambém referiram que o aspecto gráfico (look&feel) poderia ser muito melhorado, emborareconhecendo que para um protótipo deste nível, a nossa aplicação estava muito boa.

Em suma, os utilizadores na generalidade gostaram do MuVis. Ficaram surpreendidoscom a simplicidade, rapidez e eficácia da aplicação face a um produto como o WindowsMedia Player. Destacaram como inovadores os mecanismos de filtragem (principalmenteo filtro de similaridade), visualização da colecção (treemaps) e previews de músicas faceao sistema comparativo.

6.2.6 Funcionalidades do MuVis não avaliadas

Como foi referido nas secções anteriores, devido ao facto da nossa solução possuir umconjunto de funcionalidades diferentes do WMP, algumas das funcionalidades do MuVisnão puderam ser comparadas. Entre as principais funcionalidades do MuVis que nãopuderam ser devidamente testadas, importa salientar o mecanismo de audio snippet e apesquisa por similaridade de artistas, álbuns e faixas musicais. No entanto, tal comoos resultados dos questionários de satisfação revelaram, o valor destes componentes foireconhecido pelos utilizadores.

105

6.3 Síntese

Neste capítulo descrevemos a avaliação realizada ao nosso trabalho e os principais resul-tados obtidos.

Começamos por descrever os objectivos desta avaliação, identificando um conjunto demedidas que utilizámos nos testes com utilizadores, e depois apresentámos as razões quenos levaram a escolher o Windows Media Player como aplicação comparativa a utilizarna avaliação do nosso protótipo.

Depois da descrição dos passos realizados na avaliação experimental com os utiliza-dores, discutimos os resultados obtidos. Constatámos que obtivemos óptimos resultadosdo ponto de vista do tempo gasto na execução das várias tarefas. Verificámos também queos diferentes componentes foram utilizados e valorizados como esperado.

Finalmente, e apesar de algumas críticas apontadas na utilização do nosso protótipo,pudemos atestar a satisfação dos utilizadores na realização das tarefas apresentadas nanossa aplicação.

106

Capítulo 7

Conclusões e trabalho futuro

Neste capítulo apresentamos e discutimos as conclusões finais e contribuições do nossotrabalho, reflectindo alguns problemas que se levantaram e que podem vir a ser abordadosno futuro.

7.1 Sumário da Dissertação

Nesta dissertação propusemos uma nova solução para exploração interactiva de colecçõesmusicais.

No capítulo 2 começámos por estudar o trabalho relacionado com a nossa tese, englo-bando na nossa análise técnicas de recuperação de informação musical (RIM) e técnicasde visualização de informação. Com este estudo comprovámos as limitações dos siste-mas e soluções actuais, nomeadamente, na exploração de colecções musicais de grandesdimensões, na filtragem eficiente dessas colecções e na criação eficaz de playlists. Noentanto, com esta análise, compreendemos que a combinação de técnicas de RIM base-ada no conteúdo e de visualização de informação constitui a melhor forma de se poderconstruir um sistema adaptado às necessidades dos utilizadores. No final deste capítulo,fomos ainda capazes de definir o conjunto de requisitos para uma solução dos problemasidentificados.

No capítulo 3 apresentamos os resultados de um estudo realizado para compreenderas necessidades, hábitos e gostos dos utilizadores quando ouvem música. Este estudo foirealizado através de um questionário online e de um conjunto de sessões presenciais, queserviu de guia ao desenho da nossa solução. Os principais resultados obtidos deste estudosão relacionados com a exploração das colecções, criação de playlists e a pesquisa demúsicas. Sumariamente, identificámos que a exploração deverá seguir a ordem Artista,Álbum e Género; que os utilizadores gostam de controlar a criação de playlists, e devemos

107

disponibilizar a criação através de tags e conteúdo musical; e que na pesquisa de música,os utilizadores gostariam de pesquisar através de tags, mood e similaridade musical.

Nos capítulos 4 a 5 apresentámos a arquitectura da nossa solução. Começámos porapresentar no capítulo 4 a nossa solução sob uma perspectiva geral. Esta passa por umanova abordagem à navegação/exploração de bibliotecas musicais, suportada por uma ar-quitectura de uma aplicação desktop que combina recuperação de informação musical,tanto de metadados como de conteúdo musical, com técnicas de visualização de informa-ção. Neste capítulo, identificámos os três principais componentes da nossa arquitecturae os papéis desempenhados por cada um: o componente de extracção de informação,responsável pela extracção das características das músicas; o componente de recupera-ção de informação que permite o acesso à informação extraída no componente de ex-tracção; e finalmente o componente de visualização de informação, que concretiza asvistas sobre a colecção musical e efectua a interacção com o utilizador. Em seguida, des-crevemos com maior profundidade os vários componentes que fazem parte da solução.Apresentámos a arquitectura interna de cada componente evidenciando a comunicaçãoentre os diferentes módulos e a sua distribuição pelas diferentes camadas da arquitecturaModel-View-Controller (MVC). Começámos por descrever o componente de extracção decaracterísticas, mostrando a extensibilidade deste elemento, através da composição dosmódulos de extracção de tags e de características baseadas no conteúdo. Introduzimosaqui o mecanismo heurístico de extracção de audio snippets desenvolvido. Em seguidaaprofundámos o componente de recuperação, responsável pelo acesso e recuperação dainformação extraída no componente descrito anteriormente. Posteriormente, descrevemoso componente de visualização de informação, com as suas vistas (lista simples e treemap

ordernado por similaridade) e mecanismo de filtragem dinâmica. No final apresentámosa interface desenhada para a nossa solução, com base num conjunto de protótipos nãofuncionais.

No capítulo 5 descrevemos alguns dos tópicos mais relevantes acerca do protótipoimplementado. Entre os principais aspectos referidos nesta secção, encontram-se algunsdos nossos contributos para esta dissertação, nomeadamente, a vista de treemap e o me-canismo de filtragem, e outros não menos importantes, como por exemplo, a justificaçãoda escolha da plataforma de desenvolvimento e o modelo de dados utilizado no protótipo.

No capítulo 6 apresentámos a avaliação experimental conduzida para avaliar a nossasolução. Neste capítulo começámos por descrever os objectivos a alcançar, definimos umconjunto de medidas de desempenho, e a metodologia seguida. Esta avaliação consistiuna realização de um conjunto de tarefas, preenchimento de questionário de satisfação eentrevista informal. Os principais resultados mostraram que o MuVis é uma solução fácil

108

de utilizar, rápida e eficiente, que permite uma exploração interactiva e “intuitiva” da co-lecção. Os questionários revelaram ainda a satisfação geral dos utilizadores na utilizaçãodo sistema e dos componentes que o constituem.

7.2 Conclusões finais e Contribuições

Os resultados obtidos durante a avaliação experimental foram apresentados no capítulo 6e permitem-nos retirar as nossas conclusões. Verificámos que os diversos componentes danossa solução, são devidamente explorados e valorizados pelos utilizadores para explora-rem colecções musicais. A utilização destes elementos permite efectuar uma exploraçãomais rápida e interactiva das colecções musicais. Os resultados dos questionários corro-boram este facto, onde os participantes destacaram como vantajoso ter uma perspectivageral da colecção para saberem com o que contam quando pesquisam e ouvem música.

A nossa contribuição afirma-se como sendo uma nova abordagem à exploração in-teractiva e dinâmica de colecções musicais. Esta abordagem combina mecanismos deextracção e recuperação de informação (de tags e conteúdo áudio), com técnicas de visu-alização para possibilitar esta exploração. Com base nos resultados descritos no parágrafoanterior concluímos que a nossa abordagem contribui efectivamente para um aumento nafacilidade, rapidez e flexibilidade na exploração de bibliotecas musicais. Concluímosainda que, toda a componente visual da nossa solução, e o paradigma dos treemaps or-denados por similaridade, contribui efectivamente para uma maior compreensão sobre ascolecções musicais, e dessa forma, permitir encontrar músicas e efectuar pesquisas, quenão seriam fáceis de realizar com os sistemas actuais.

Outro facto a realçar, prende-se com o mecanismo de filtragem desenvolvido. Os re-sultados obtidos no capítulo 6 mostraram ainda que, uma combinação simples e eficaz deum conjunto de critérios de filtragem (filtragem dinâmica), através de poucas interacções,é eficiente, eficaz e satisfaz plenamente os utilizadores. Para além da rapidez e eficácia,este mecanismo, através da representação visual dos filtros usando o paradigma dos tree-

maps permitiu também que os utilizadores conhecessem a colecção musical: que génerosexistiam, qual a duração mais comum das músicas, etc. Este aspecto é uma contribuiçãoimportante, e que complementa o já referido nos parágrafos anteriores: este mecanismode filtragem permite não só a filtragem como também ajuda na exploração da colecção.

Com base nos resultados já referidos, concluímos ainda o que tínhamos previamenteconstatado no capítulo 2: a combinação entre técnicas de recuperação de informaçãobaseadas no conteúdo e técnicas de visualização de informação é vantajosa.

Destacamos também como contribuição a própria arquitectura da solução. Esta ar-

109

quitectura foi projectada de forma a ser flexível e extensível em vários pontos, através dorecurso a vários padrões de desenho. Esta flexibilidade verifica-se ao nível dos três com-ponentes da solução: extracção de características do áudio; recuperação dessa informa-ção; e técnicas de visualização. Desta forma, potenciamos a que o trabalho futuro, tantode melhoramento das técnicas implementadas, como de concretização de novas soluções,possa ser conduzido com ganhos no desenvolvimento e na rapidez de concretização dessastécnicas.

Não menos importante do que os contributos já referidos nos parágrafos anteriores,encontram-se os resultados obtidos no estudo realizado no capítulo 3. Estes resultadosserviram de base a todo o desenvolvimento da solução apresentada nesta dissertação,desde a arquitectura conceptual até ao protótipo funcional, permitindo que a solução finalestivesse de acordo com os requisitos dos utilizadores. Os princípios de desenho ficamtambém registados como uma base para qualquer trabalho futuro que necessite de funda-mento ou compreensão das necessidades dos utilizadores para ouvir música.

7.3 Trabalho futuro

Com base na avaliação experimental realizada e nos condicionalismos referidos ao longodesta dissertação identificámos alguns aspectos que encorajam o desenvolvimento de tra-balho futuro neste tema. Para a continuação deste trabalho, conseguimos identificar trêscaminhos principais: a usabilidade da aplicação, melhorias nos mecanismos de extracçãoe recuperação de informação, e melhorias no mecanismo de visualização de informação.Apesar da usabilidade da aplicação não ser um dos objectivos principais desta disserta-ção nem uma prioridade, esta afirma-se como um aspecto preponderante a ter em contana passagem da nossa abordagem para um eventual produto comercial, uma vez que osutilizadores finais são o nosso público-alvo.

Acerca da usabilidade, afirmamos que o melhoramento da nossa solução, poderá pas-sar pelo desenvolvimento de novas funcionalidades e melhoramentos na interface da so-lução. A concretização de novas formas automáticas de criação de playlists, o desenvol-vimento de um look&feel mais apelativo aos utilizadores e novos modos de tocar músicasconstituem as principais alterações a registar.

Em relação aos mecanismos de extracção e recuperação de informação, vários aspec-tos garantem a possibilidade de um trabalho futuro.

Nos testes realizados, destacámos o facto de os utilizadores sentirem dificuldade emdefinir o conceito de similaridade. Este facto permitiu que o mecanismo de pesquisa porsimilaridade concretizado na nossa solução fosse reconhecido e valorizado pelos utiliza-

110

dores. No entanto, vários aspectos aqui podem efectivamente ser melhorados, por exem-plo: utilizar (ou desenvolver) novos mecanismos de determinação de similaridade musical(usando por exemplo outras características das músicas, como a melodia ou a harmonia,podendo ser escolhidas pelos utilizadores), providenciando resultados mais precisos naspesquisas efectuadas. Outro aspecto interessante seria a integração com mais mecanismosde extracção de características, de forma a desenvolver novos filtros e potencialmente no-vas vistas sobre as colecções.

Ainda em relação à extracção de características, novos mecanismos de extracção detags poderiam ser adicionados, por exemplo com recurso a técnicas de web-retrieval, deforma a tornar mais correctas as informações semânticas associadas às músicas, álbuns eartistas das bibliotecas.

Quanto aos mecanismos de recuperação de informação, o trabalho futuro pode seguirdois rumos principais: melhoramento da técnica principal utilizada (desenvolvimento deoutras), ou combinação de técnicas para tornar as recuperações mais completas e precisas.

Finalmente, em relação às técnicas de visualização de informação, o caminho a seguirpassa pela melhoria do algoritmo de particionamento do treemap e pela resolução dosproblemas de selecção nos filtros. Possivelmente seria adequada a criação ou conjugaçãode técnicas alternativas aos treemaps (p. ex: através da conjugação de diferentes para-digmas de interacção e tecnologias, como o Collect Table [43]), que permitam resolveros problemas identificados, mas que simultaneamente garantam uma percepção visual eespecial da colecção, uma vez que os utilizadores a referiram como boa e de extrema utili-dade. Estes aspectos teriam de ser novamente validados, para compreender se a resoluçãode um conjunto de problemas não teria novas consequências.

111

Bibliografia

[1] Eric Allamanche and Bernhard Froba. Content-based identification of audio ma-terial using mpeg-7 low level description. In in Proc. of the Int. Symp. of Music

Information Retrieval, pages 197–204, 2001.

[2] Xavier Amatriain. Clam: A framework for audio and music application develop-ment. IEEE Software, 24(1):82–85, 2007.

[3] J.-J Aucouturier and F. Pachet. Music similarity measures: What’s the use? In Proc.

Int. Conf. Music Information Retrieval, 2002.

[4] Benjamin B. Bederson, Ben Shneiderman, and Martin Wattenberg. Ordered andquantum treemaps: Making effective use of 2d space to display hierarchies. ACM

Trans. Graph., 21(4):833–854, 2002.

[5] M. Bruls, K. Huizing, and J. van Wijk. Squarified treemaps. In Proc. of Joint

Eurographics and IEEE TCVG Symp. on Visualization (TCVG 2000), pages 33–42.IEEE Press, 2000.

[6] M. Casey and M. Slaney. The importance of sequences in music similarity. In Proc.

Int. Conf. Acoustics, Speech Signal Processing, 2006.

[7] Michael Casey, Christophe Rhodes, and Malcolm Slaney. Analysis of minimumdistances in high-dimensional musical spaces. IEEE Transactions on Audio, Speech

& Language Processing, 16(5):1015–1028, 2008.

[8] Michael A. Casey, Remco Veltkamp, Masataka Goto, Marc Leman, Christophe Rho-des, and Malcolm Slaney. Content-based music information retrieval: current direc-tions and future challenges. Proceedings of the IEEE, 96(4):668–696, April 2008.

[9] Peter Pin-Shan S. Chen. The entity-relationship model: Toward a unified view ofdata. ACM Transactions on Database Systems, 1(1):9–36, 1976.

112

[10] Matthew Cooper and Jonathan Foote. Automatic music summarization via similarityanalysis. In in Proc. Int. Conf. Music Information Retrieval, 2002, pages 81–85.

[11] Sally J. Cunningham, Nina Reeves, and Matthew Britland. An ethnographic studyof music information seeking: implications for the design of a music digital library.In JCDL ’03: Proceedings of the 3rd ACM/IEEE-CS joint conference on Digital

libraries, pages 5–16, Washington, DC, USA, 2003. IEEE Computer Society.

[12] Manuel João da Fonseca. Sketch-Based Retrieval in Large Sets of Drawings. PhDthesis, Instituto Superior Técnico (IST), 2004.

[13] B. V. Dasarathy. Nearest neighbor (NN) norms : NN pattern classification techni-

ques. IEEE Computer Society Press, 1991.

[14] Simon Dixon. Automatic extraction of tempo and beat from expressive performan-ces. Journal of New Music Research, 30:39–58, 2001.

[15] J. S. Downie. The musifind musical information retrieval project, phase ii: Userassessment contextual inquiry. In Proceedings of the 22nd Annual Conference of

the Canadian Association for Information Science, 1994.

[16] J. S. Downie. The music information retrieval evaluation exchange (mirex). D-Lib

Mag, 12(12), 2006.

[17] J. Stephen Downie, Joe Futrelle, and David K. Tcheng. The international music in-formation retrieval systems evaluation laboratory: Governance, access and security.In ISMIR, 2004.

[18] Jana Eggink and Guy J. Brown. Extracting melody lines from complex audio. InISMIR, 2004.

[19] D.P.W. Ellis and G.E. Poliner. Identifying ‘cover songs’ with chroma features anddynamic programming beat tracking. Acoustics, Speech and Signal Processing,

2007. ICASSP 2007. IEEE International Conference on, 4:IV–1429–IV–1432, April2007.

[20] Manuel J. Fonseca and Joaquim A. Jorge. Indexing high-dimensional data forcontent-based retrieval in large databases. In DASFAA ’03: Proceedings of the

Eighth International Conference on Database Systems for Advanced Applications,page 267, Washington, DC, USA, 2003. IEEE Computer Society.

113

[21] Adrian Freed. Music metadata quality: a multiyear case study using the music ofskip james. In AES 121, San Francisco, CA, 2006.

[22] Masataka Goto. An audio-based real-time beat tracking system for music with orwithout drum-sounds. Journal of New Music Research, 30(2):159–171, 2001.

[23] Masataka Goto. A real-time music-scene-description system: predominant-f0 es-timation for detecting melody and bass lines in real-world audio signals. Speech

Communication, 43(4):311–329, September 2004.

[24] Masataka Goto and Satoru Hayamizu. A real-time music scene description system:detecting melody and bass lines in audio signals. In Speech Communication, pages31–40, 1999.

[25] Stephen W. Hainsworth and Malcolm D. Macleod. Particle filtering applied to mu-sical tempo tracking. EURASIP J. Appl. Signal Process., 2004(1):2385–2395, 2004.

[26] Christopher Harte, Mark Sandler, and Martin Gasser. Detecting harmonic change inmusical audio. In AMCMM ’06: Proceedings of the 1st ACM workshop on Audio

and music computing multimedia, pages 21–26, New York, NY, USA, 2006. ACM.

[27] IFPI. Digital music report. Technical report, IFPI, 2009.

[28] Teuvo Kohonen. Self-organized formation of topologically correct feature maps.pages 509–521, 1988.

[29] K. Lagus and S. Kaski. Keyword selection method for characterizing text documentmaps. In ICANN’99: Proceedings of 9th International Conference on Artificial

NeuralNetworks, London, UK, 2001.

[30] B. K. Lavine. Chemometric techniques for quantitative analysis. by richard kramer.dekker. Microchemical Journal, 63(3):427, November 1999.

[31] J. H. Lee and J. S. Downie. Contextual inquiry of music information needs, uses,and seeking behaviours: preliminary findings. In ISMIR, 2004.

[32] Kyogu Lee and M. Slaney. Acoustic chord transcription and key extraction fromaudio using key-dependent hmms trained on synthesized audio. Audio, Speech, and

Language Processing, IEEE Transactions on, 16(2):291–301, Feb. 2008.

[33] Stefan Leitich and Martin Topf. Globe of music - music library visualization usinggeosom. ISMIR, 2007.

114

[34] T. Lidy and A. Rauber. Evaluation of feature extractors and psycho-acoustic trans-formations for music genre classification. In Proceedings of the 6th InternationalConference on Music Information Retrieval, September 2005.

[35] Thomas Lidy and Andreas Rauber. Genre-oriented organization of music collectionsusing the somejb system: An analysis of rhythm patterns and other features. In Proc.

DELOS Workshop on Multimedia Contents in Digital Libraries, 2003, pages 254–257, 2004.

[36] Anita Shen Lillie. Musicbox: Navigating the space of your music. Master’s thesis,MASSACHUSETTS INSTITUTE OF TECHNOLOGY, 2008.

[37] Greg Linden, Brent Smith, and Jeremy York. Amazon.com recommendations: Item-to-item collaborative filtering. IEEE Internet Computing, 7(1):76–80, 2003.

[38] B. Logan and S. Chu. Music summarization using key phrases. In ICASSP ’00: Pro-

ceedings of the Acoustics, Speech, and Signal Processing, 2000. on IEEE Internati-

onal Conference, pages II749–II752, Washington, DC, USA, 2000. IEEE ComputerSociety.

[39] B. Logan and A. Salomon. A music similarity function based on signal analysis. InMultimedia and Expo, 2001. ICME 2001. IEEE International Conference on, pages745–748, 2001.

[40] Lie Lu and Hong-Jiang Zhang. Automated extraction of music snippets. In MUL-

TIMEDIA ’03: Proceedings of the eleventh ACM international conference on Mul-

timedia, pages 140–147, New York, NY, USA, 2003. ACM.

[41] M. Mandel and D. Ellis. Song-level features and support vector machines for musicclassification. Proc. of the ISMIR Intl. Conf. on Music Information Retrieval, 2005.

[42] Matija Marolt. Gaussian mixture models for extraction of melodic lines from audiorecordings. In Proc. Int. Conf. Music Information Retrieval, pages 80–83, 2004.

[43] André Maximo, Maria Paula Saba, and Luiz Velho. collectable: a natural interfacefor music collections. In SIGGRAPH ’09: SIGGRAPH ’09: Posters, pages 1–1,New York, NY, USA, 2009. ACM.

[44] Robert Neumayer, Michael Dittenbach, and Andreas Rauber. Playsom and poc-ketsomplayer: Alternative interfaces to large music collections. In Queen Mary,

University of London, pages 618–623, 2005.

115

[45] Rui Pedro Paiva, Teresa Mendes, and Amílcar Cardoso. Melody detection inpolyphonic musical signals: Exploiting perceptual rules, note salience, and melo-dic smoothness. Comput. Music J., 30(4):80–98, 2006.

[46] E. Pampalk. Computational Models of Music Similarity and their Application in

Music Information Retrieval. PhD thesis, Vienna University of Technology, 2006.

[47] Elias Pampalk. Islands of music: Analysis, organization, and visualization of musicarchives. Master’s thesis, Vienna University of Technology, 2001.

[48] Elias Pampalk, Arthur Flexer, and Gerhard Widmer. Hierarchical organization anddescription of music collections at the artist level. In In Proceedings of the 9th

European Conference on Research and Advanced Technology for Digital Libraries

(ECDL, pages 37–48, 2005.

[49] Elias Pampalk and Martin Gasser. An implementation of a simple playlist generatorbased on audio similarity measures and user feedback. ISMIR, 2006.

[50] Elias Pampalk and Masataka Goto. Musicrainbow: A new user interface to discoverartists using audio-based similarity and web-based labeling. In ISMIR, pages 367–370, 2006.

[51] Elias Pampalk, Tim Pohle, and Gerhard Widmer. Dynamic playlist generation basedon skipping behaviour. In Proc. of the 6th ISMIR Conference, pages 634–637, 2005.

[52] Elias Pampalk, Andreas Rauber, and Dieter Merkl. Content-based organization andvisualization of music archives. pages 570–579. ACM, 2002.

[53] Elias Pampalk, Andreas Rauber, and Dieter Merkl. Using smoothed data histogramsfor cluster visualization in self-organizing maps. In ICANN ’02: Proceedings of the

International Conference on Artificial Neural Networks, pages 871–876, London,UK, 2002. Springer-Verlag.

[54] Adam R. Tindale, David Sprague, and George Tzanetakis. Strike-a-tune: Fuzzymusic navigation using a drum interface. ISMIR, 2007.

[55] J. A. Russell. A circumplex model of affect. Journal of Personality and Social

Psychology, 39:1161–1178, 1980.

[56] Markus Schedl. The comirva toolkit for visualizing music-related data. Technicalreport, Department of Computational Perception, Johannes Kepler University Linz,June 2006.

116

[57] Markus Schedl, Peter Knees, and Gerhard Widmer. A web-based approach to as-sessing artist similarity using co-occurrences. In Proceedings of 4th International

Workshop on Content-Based Multimedia Indexing (CBMI’05), June 2005.

[58] E. D. Scheirer. Tempo and beat analysis of acoustic musical signals. The Journal of

the Acoustical Society of America, 103(1):588–601, 1998.

[59] J. Serra and E. Gomez. A cover song identification system based on sequences of to-nal descriptors. The 2007 music information retrieval evaluation exchange (MIREX

2007), 2007.

[60] W.A. Sethares and R. Arora. Equilibria of adaptive wavetable oscillators with ap-plications to beat tracking. Acoustics, Speech and Signal Processing, 2007. ICASSP

2007. IEEE International Conference on, 4:IV–1301–IV–1304, April 2007.

[61] Gregory Shakhnarovich, Trevor Darrell, and Piotr Indyk. Nearest-Neighbor

Methods in Learning and Vision: Theory and Practice (Neural Information Pro-

cessing). The MIT Press, 2006.

[62] A. Sheh and D. P. Ellis. Chord segmentation and recognition using em-trained hid-den markov models. In Proc. Int. Conf. Music Information Retrieval, 2003.

[63] B. Shneiderman. Tree visualization with treemaps: a 2-d space-filling approach.Technical report, HCIL-91-03, CS-TR-2645, CAR-TR-548, Jan 1992.

[64] J. Stephen, Downie Kris, West Andreas, and Ehmann Emmanuel Vicent. The 2005music information retrieval evaluation exchange (mirex 2005). In Proc. Int. Conf.

Music Information Retrieval, London, U.K., 2005.

[65] Robert E. Thayer. The Biopsychology of Mood and Arousal. Oxford UniversityPress, USA, September 1990.

[66] George Tzanetakis and Perry Cook. Marsyas: a framework for audio analysis. Or-

ganized Sound, 4(3):169–175, December 1999.

[67] Jarke J. van Wijk and Huub van de Wetering. Cushion treemaps: Visualization ofhierarchical information. In INFOVIS, pages 73–78, 1999.

[68] Fabio Vignoli, Rob van Gulik, and Huub van de Wetering. Mapping music in thepalm of your hand, explore and discover your collection. pages 409–414, Barcelona,Spain, October 2004. Universitat Pompeu Fabra.

117

[69] A. Wang. An industrial strength audio search algorithm. In Online Proceedings of

ISMIR2003, 2003.

[70] Jo Wood and Jason Dykes. Spatially ordered treemaps. IEEE Transactions on Visu-

alization and Computer Graphics, 14(6):1348–1355, 2008.

[71] Yingxin Wu and Masahiro Takatsuka. Spherical self-organizing map using efficientindexed geodesic data structure. Neural Netw., 19(6):900–910, 2006.

118

Apêndices

119

Parte I

Guião dos Testes com Utilizadores

120

Neste teste pretendemos avaliar o sucesso do MuVis, o programa que desenvolvemospara a exploração de colecções musicais. Estamos interessados em observar o seu com-portamento com o nosso programa e registar a sua opinião. Para tal, pedimos a execuçãode um conjunto de tarefas e o preenchimento de um questionário.

A primeira parte deste teste tem como objectivo a observação e o registo da sua inte-racção com o programa em questão. Uma vez que necessitamos de uma base de compara-ção para medir o sucesso do nosso programa, esta fase será repetida para duas aplicações:o MuVis e o Windows Media Player.

A segunda parte tem como objectivo registar a sua opinião. Queremos perceber se onosso programa é fácil de utilizar e se satisfaz os utilizadores na concretização das tarefaspedidas. Queremos também perceber quais os eventuais problemas existentes na nossaaplicação.

As tarefas apresentadas consistem nas actividades normais num programa para ouvirmúsica, como por exemplo, pesquisas e criação de playlists. Encorajamos a liberdadepara realizar as tarefas da forma que achar mais conveniente.

Antes da tarefa terá ao seu dispor um tempo de treino e adaptação aos programas.Quaisquer dúvidas serão esclarecidas nesta fase.

Muito obrigado pela colaboração.

Tarefas a realizar

Realize as tarefas pela ordem indicada.

1. Encontre a música Wonderful Tonight do artista Eric Clapton e oiça-a.

2. Crie uma playlist com 12 músicas da década de 90, do género Pop e com umaduração entre 3-5 minutos.

3. Diga o nome do artista com mais músicas e do artista com mais álbuns.

4. Encontre álbuns semelhantes ao primeiro álbum do artista com mais álbuns.

Muito obrigado pela atenção e tempo que nos deu.FIM

121

Parte II

Questionário de Satisfação

122

Avaliação Experimental - Questionário de Satisfação

Dados pessoais

1. Qual a sua idade?

(a) < 18 anos

(b) 18-30 anos

(c) 30-50 anos

(d) > 50 anos

2. Sexo?

(a) Masculino

(b) Feminino

3. Com que frequência costuma ouvir música no computador?

(a) Frequentemente

(b) Muitas vezes

(c) Poucas vezes

(d) Raramente

4. Qual o programa que costuma utilizar para ouvir música?

(a) Windows Media Player

(b) iTunes

(c) Winamp

(d) Amarok

(e) Outro:

Opinião / Satisfação

1. As perguntas deste grupo são todas relativas ao programa MuVis

(a) A realização das tarefas foi...

i. Muito Fácil

ii. Fácil

123

iii. Difícil

iv. Muito difícil

(b) A localização das músicas pretendidas foi...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(c) Perceber o mecanismo de filtragem foi...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(d) O filtro de similaridade musical apresenta boas sugestões de músicas / álbuns/ artistas.

i. Concordo totalmente

ii. Concordo

iii. Discordo

iv. Discordo totalmente

(e) A filtragem interactiva é fácil de utilizar.

i. Concordo totalmente

ii. Concordo

iii. Discordo

iv. Discordo totalmente

(f) Criar playlists no MuVis é...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(g) As diferentes formas de criar playlists são uma mais-valia.

i. Concordo totalmente

ii. Concordo

124

iii. Discordo

iv. Discordo totalmente

(h) É fácil compreender a composição da colecção musical usando o MuVis.

i. Concordo totalmente

ii. Concordo

iii. Discordo

iv. Discordo totalmente

(i) Faça um resumo desta colecção de músicas (usando palavras suas).

(j) A combinação entre filtragem e “vista” da colecção é fácil de perceber.

i. Concordo totalmente

ii. Concordo

iii. Discordo

iv. Discordo totalmente

(k) A exploração interactiva da colecção musical foi ... de realizar.

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(l) Sentiu dificuldade em realizar alguma tarefa?

i. SimIndique qual (quais) e o(s) motivo(s):

ii. Não

(m) Utilizaria o MuVis novamente?

i. Sim

ii. NãoIndique o(s) motivo(s) independentemente da resposta.

125

2. As perguntas deste grupo são todas relativas ao programa Windows MediaPlayer (WMP)

(a) A realização das tarefas foi...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(b) A localização das músicas pretendidas foi...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(c) Perceber o mecanismo de filtragem foi...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(d) A filtragem interactiva é fácil de utilizar.

i. Concordo totalmente

ii. Concordo

iii. Discordo

iv. Discordo totalmente

(e) Criar playlists no WMP é...

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(f) É fácil compreender a composição da colecção musical usando o WMP

i. Concordo totalmente

ii. Concordo

iii. Discordo

126

iv. Discordo totalmente

(g) A exploração da colecção musica foi ... de realizar.

i. Muito Fácil

ii. Fácil

iii. Difícil

iv. Muito difícil

(h) Sentiu dificuldade em realizar alguma tarefa?

i. SimIndique qual (quais) e o(s) motivo(s):

ii. Não

(i) Utilizaria o WMP novamente?

i. Sim

ii. NãoIndique o(s) motivo(s) independentemente da resposta.

3. As perguntas deste grupo são de comparação entre os dois sistemas

(a) Em qual dos programas foi mais fácil executar as tarefas pedidas?

i. MuVis

ii. Windows Media Player

(b) Se tivesse que escolher entre o MuVis e o WMP para ser o seu tocador deáudio, qual escolheria?

i. MuVis

ii. Windows Media Player

(c) Qual o mecanismo de filtragem que prefere?

i. MuVis

ii. Windows Media Player

(d) Em relação à última pergunta: porquê?

127

(e) Qual o sistema onde é mais fácil criar playlists?

i. MuVis

ii. Windows Media Player

(f) Em relação à última pergunta: porquê?

(g) A pesquisa por similaridade musical do MuVis é uma mais-valia.

i. Concordo totalmente

ii. Concordo

iii. Discordo

iv. Discordo totalmente

(h) Sentiu que o WMP tem algumas funcionalidades que fazem falta no MuVis?

i. SimIndique quais:

ii. Não

(i) Sentiu que o MuVis tem algumas funcionalidades que fariam falta no WMP?

i. SimIndique quais:

ii. Não

(j) Qual a sua opinião geral sobre a visualização e navegação na colecção musicalutilizando o MuVis? E o WMP?

(k) O que gostou no MuVis?

128

(l) O que não gostou no MuVis?

(m) Teve algumas dificuldades adicionais na utilização do MuVis que gostaria deacrescentar?

(n) Tem alguma sugestão que pudesse melhorar o MuVis?

Muito obrigado pela atenção e tempo que nos deu.FIM

129

Parte III

Estudo com Utilizadores - Questionário

130

Estudo do perfil dos Utilizadores

Muito obrigado pela disponibilidade para responder a este questionário.Com este questionário pretende-se compreender o perfil dos utilizadores de

programas para ouvir música no computador, e de que forma os utilizadores usam osprogramas para efectuar operações básicas, tais como, ouvir música, procurar

músicas, construir playlists, etc. Este questionário é anónimo e os dados serãotratados com confidencialidade.

 

Perfil dos Utilizadores - I

Nota: as perguntas marcadas com * são de resposta obrigatória.

1 Qual é o seu sexo?Escolha *apenas* uma das opções seguintes: o Feminino | o Masculino

2 Qual é a sua faixa etária?Escolha *apenas* uma das opções seguintes: o 10-19 o 20-29 o 30-39 o 40-50 o Mais de 50 anos

3 Costuma ouvir música no seu computador?Escolha *apenas* uma das opções seguintes: o Sim o Não

Perfil dos Utilizadores - I

A partir deste ponto todas as perguntas estão relacionadas com ouvir música nocomputador.

4 Em que local costuma ouvir música?Por favor escolha *todas* as que se aplicam: o Casa o TrabalhoOutro: ________

5 Costuma ouvir músicas disponibilizadas em sites de internet?Escolha *apenas* uma das opções seguintes: o Sim o Não

6 Que sites costuma utilizar para ouvir música online? (Responda apenas se respondeuafirmativamente na pergunta anterior)Por favor escolha *todas* as que se aplicam:

1 / 5

o Last.fm o Pandora o iLike o Playlist.comOutro: ________

7 Possui uma colecção de música em formato digital (OGG, MP3, WMA, etc) guardada no seucomputador?Escolha *apenas* uma das opções seguintes: o Sim o Não

8 Qual a dimensão da sua biblioteca? (responda apenas se respondeu afirmativamente à perguntaanterior)Escolha *apenas* uma das opções seguintes: o Menos de 1.000 músicas o Entre 1.000 e 10.000 músicas o Mais de 10.000 músicas

9 Quais os principais estilos ou géneros musicais que compõem a sua biblioteca?Por favor escolha *todas* as que se aplicam: o Pop o Rock o Clássica o Africana o Rap o Reggae o Electrónica o Jazz o R&B o Blues o GospelOutro: ________

Perfil dos Utilizadores - II

1 Que programas utiliza habitualmente para ouvir músicasPor favor escolha *todas* as que se aplicam: o Winamp o Windows Media Player o iTunes o SongBird o Jajuk o aTunes o Amarok o Rythmbox o XmmsOutro: ________

2 De que forma procura pelas músicas que pretende ouvir?Por favor escolha *todas* as que se aplicam: o Usando a ferramenta de procura do programa (escolhido na pergunta anterior) o Procura directa no sistema de directorias

2 / 5

Outro: ________

3 Qual a forma como costuma procurar por músicas? (responda a esta pergunta se na perguntaanterior a 1ª alínea fizer parte da resposta)Por favor escolha *todas* as que se aplicam: o Género/estilo musical o Artista o Nome da faixaOutro: ________

4 De que forma costuma organizar a sua colecção musical, no sistema de directorias? (responda aesta pergunta se a resposta à pergunta 2 contiver a 2ª alínea)Por favor escolha *todas* as que se aplicam: o Pelo par Artista/Álbum o Por Artista com subpastas para os álbuns o Por Ano e usando nos sub-níveis seguintes o esquema da alínea a) o Por Ano e usando nos sub-níveis seguintes o esquema da alínea b)Outro: ________

5 Como navega habitualmente na sua biblioteca musical? (numere por ordem de preferência)Por favor seleccione as caixas pela ordem da sua preferêcia de 1 a 4__ Álbum__ Artista__ Género__ Compositor

6 Costuma fazer playlists de músicas?Escolha *apenas* uma das opções seguintes:Sim, sempreSim, às vezesNãoMake a comment on your choice here:____________________________________________________________________________________________________________________________________________________________________________________

7 De que forma constrói as suas playlists?Por favor escolha *todas* as que se aplicam: o Seleccionando individualmente as músicas o Utilizando os filtros e pesquisas disponibilizados pelos programas o AleatoriamenteOutro: ________

8 Grande parte dos tocadores de áudio permitem que as músicas sejam classificadas, por exemplo,para indicar que o utilizador gosta mais de uma música do que outra. De que forma classifica assuas músicas? (se seleccionar a primeira opção, não seleccione mais nenhuma opção)Por favor escolha *todas* as que se aplicam: o Não classifico o Manualmente

3 / 5

o Automaticamente, através do programaOutro: ________

Perfil dos Utilizadores - III

Considere um novo programa para ouvir as suas músicas. Este programadisponibiliza todas as funcionalidades básicas dos tocadores de música

convencionais (por exemplo: tocar músicas, pesquisar, gerar playlists, etc).Adicionalmente este sistema permite que os utilizadores possam efectuar pesquisaspor semelhança de músicas, artistas ou géneros/estilos musicais. Disponibilizatambém uma interface que permite visualizar e explorar as músicas de uma forma

mais interactiva do que o convencional.Imaginando que o utilizador tem um sistema como o apresentado:

1 Ordene as seguintes funcionalidades do programa de acordo com as suas preferências:Por favor seleccione as caixas pela ordem da sua preferêcia de 1 a 3__ Pesquisa eficaz de músicas__ Navegação personalizada e interactiva__ Construção automática de playlists com base num conjunto de critérios controlados peloutilizador.

2 Que modos de pesquisa gostaria de ter disponíveis nesta aplicação?Por favor escolha *todas* as que se aplicam: o Pesquisa usando tags/palavras-chave (por exemplo: artista, género, nome da faixa, compositor,etc.) o Pesquisa por semelhança das músicas o Pesquisa por semelhança de artista ou género musical o Pesquisa por ritmo ou batida o Pesquisa de músicas instrumentais o Pesquisa de músicas por estado de espírito o Pesquisa de diferentes versões da mesma músicaOutro: ________

3 Considerando que aplica um filtro para limitar a sua pesquisa, ordene por ordem de preferênciaas seguintes opções para visualizar e explorar a biblioteca musical:Por favor seleccione as caixas pela ordem da sua preferêcia de 1 a 4__ Visualizar todas as músicas igualmente__ Visualizar só as seleccionadas pelo filtro__ Visualizar as seleccionadas pelo filtro mais as próximas__ Visualizar as seleccionadas pelo filtro, mantendo o contexto global

4 Como gostaria de gerar playlists automaticamente?Por favor escolha *todas* as que se aplicam: o Faixas semelhantes de acordo com tags/palavras-chave o Faixas do mesmo estilo ou género musical o Faixas do mesmo artista o Faixas com o mesmo ritmo ou batida o Faixas para o mesmo estado de espíritoOutro: ________

5 Sugestões:Escreva aqui a sua resposta:________________________________________

4 / 5

____________________________________________________________________________________________________________________________________________

Submeter o seu Inquérito

Obrigado por ter preenchido este Inquérito

5 / 5