Développement d outils de navigation hypermedia (sons) pour dispositifs mobiles (Android).

Transcription

1 Université de Mons Faculté des Sciences Institut d Informatique Développement d outils de navigation hypermedia (sons) pour dispositifs mobiles (Android). Mémoire réalisé par Daniel DZIAMSKI en vue de l obtention du grade de Master en Sciences Informatiques finalité spécialisée Directeur : M r Stéphane DUPONT Année académique

2 i

3 Remerciements En préambule de ce mémoire, je souhaite adresser mes remerciements les plus sincères aux personnes qui m ont apporté leur aide et qui ont contribué à l élaboration de ce travail. Je tiens tout d abord à remercier Monsieur Stéphane Dupont, mon Directeur de mémoire, pour m avoir permis de réaliser ce travail et pour sa disponibilité tout au long de cette année. Je remercie également Messieurs Xavier Siebert et Christian Frisson, ainsi que mes Rapporteurs, pour les nombreux conseils avisés dont ils m ont fait part et l aide précieuse qu ils m ont apportée. ii

4 Table des matières 1 Introduction 1 2 Etat de l art Technologies mobiles Téléphonie mobile Tablette PC Types de médias Média Multimédia Hypermédia Rich média Solutions existantes Shazam Midomi-SoundHound MediaCycle Les apports du mémoire Fingerprinting Introduction Concepts et définition Définition Caractéristiques Représentation de l audio en images Extraction d empreinte Introduction Extraction d empreintes Recherche et correspondance dans une base de données LookUp table Hachage Locality Sensitive Hashing (LSH) Min-Hash Motivation de nos choix Protocole expérimental Mise en place du protocole Implémentation du prototype Résultats obtenus avec le prototype iii

5 4 Présentation de l application Android Protocole REST REST Avantages et inconvénients de REST Base de données SQLite SQLite pour Android Serveur Apache Apache Base de données du serveur et de MediaCycle MediaCycle-AudioCycle MediaCycle AudioCycle Visualisation Présentation des différents modules de l application Interface d accueil Informations de l application Enregistrer un son Tagging et géolocalisation Lister les sons Envoyer des données Visualiser les clusters Conclusion 71 Annexes 77 A HashTable et HashList 77 B Commandes SoX 80 C Utilisation du prototype de recherche d empreintes 82 C.1 Interface d accueil C.2 Traitement des données C.3 Recherche d empreintes D Différents résultats obtenus grâce au prototype 86 iv

6 Chapitre 1 Introduction Le contenu de ce rapport est ciblé sur le processus d extraction d empreinte et l analyse des algorithmes de recherche de correspondance dans une base de données. Ce document est réalisé en suivant plusieurs objectifs. D une part, il a pour but d expliquer les différentes phases du processus d extraction et d étudier l efficacité des différents algorithmes de recherche. D autre part, il présente le développement d un prototype de recherche d empreinte basé sur ces théories et l implémentation d une application Android fonctionnant à partir de ces éléments. Le laboratoire de Théorie des Circuits et Traitement du Signal (TCTS) a développé un logiciel d analyse de données multimédias appelé MediaCycle. Ces données peuvent par exemple être des sons, des images ou encore des vidéos. Le fonctionnement de MediaCycle et les résultats que l on obtient grâce à son utilisation sont présentés de façon détaillée dans la suite de ce rapport. La volonté du TCTS est de pouvoir profiter des fonctionnalités de ce logiciel au travers de nouveaux terminaux mobiles s exécutant sous Android. L idée est d exploiter au maximum les équipements des smartphones et tablettes interactives. Ceux-ci, étant munis de nombreux senseurs (GPS, audio, vidéo,...) et de possibilités d actions multitactiles, offrent un potentiel important pour le développement d applications pervasives. Grâce à l utilisation de ces outils et des multiples fonctionnalités qu ils offrent, il est possible aujourd hui de lier plus aisément le monde réel au contenu numérique présent sur internet. Le but est de développer un système qui tire parti de ces senseurs et qui permet de rechercher des éléments multimédias dans une base de données par l intermédiaire de MediaCycle. Les objectifs principaux du mémoire sont donc dans un premier temps : se focaliser sur une composante des algorithmes de recherche par similarité et fingerprinting, le hachage perceptuel. Le but est d étudier l impact du hachage sur la vitesse et la qualité de la recherche, ainsi que l impact perturbateur du bruit sur le "hash code" obtenu. Dans un second temps, nous développons une application fonctionnant sous Android. Celle-ci permet d exploiter les fonctionnalités et les résultats de MediaCycle sur les différentes surfaces tactiles, gsm ou tablette. L application a pour utilité de traiter des données audio dans le but de trouver des éléments sonores ayant des caractéristiques similaires. A la fin de son développement, l application est évaluée et testée. Si les résultats obtenus sont convaincants, l application peut éventuellement trouver sa place sur l Android Market 1 et être disponible gratuitement pour les utilisateurs désirant l acquérir. Le souhait est d offrir un logiciel

7 libre, gratuit, mais aussi innovant afin de concurrencer les différentes applications similaires qui sont déjà présentes sur le marché. La suite de ce document est organisée comme suit. Au chapitre 2, nous présentons une description de l état de l art. Nous y abordons notamment les différentes technologies mobiles qui regroupent principalement la téléphonie mobile et les tablettes PC. Nous donnons également un rappel sur les types de médias qui existent dans le monde actuel. Enfin, nous y présentons les solutions qui réalisent un travail similaire à l application que nous développons et les apports de ce mémoire par rapport à ces solutions. Au chapitre 3, nous nous focalisons sur le hachage perceptuel qui est une composante des algorithmes de recherche par similarité et fingerprinting. On y énonce une définition de fingerprinting et les concepts qui lui sont liés. Par la suite, nous expliquons en détails les différentes phases qui constituent le processus d extraction d empreinte. L analyse des algorithmes de recherche de correspondance dans une base de données permet de clôturer ces éléments théoriques. Nous concluons ce chapitre, en exposant le protocole expérimental mis en place. Nous y présentons le prototype que nous avons développé et les résultats que nous avons obtenus à partir de celui-ci. Le chapitre 4 est consacré à l implémentation de l application Android. Nous y présentons dans un premier temps les différents éléments nécessaires au bon fonctionnement de l application. Il s agit tout d abord du protocole REST. Ensuite, nous expliquons le serveur Apache et la base de données que nous utilisons. Enfin, nous exposons de façon avancée le fonctionnement de Media- Cycle. La suite du chapitre est dédiée à la présentation et à l explication de l ensemble des modules qui composent l application Android que nous avons développée. Enfin, nous clôturons ce rapport par une conclusion dans laquelle nous rappelons l essentiel du travail accompli et les résultats obtenus. Nous y présentons également les perspectives futures. 2

8 Chapitre 2 Etat de l art Dans ce chapitre, nous faisons tout d abord le point sur les différentes technologies mobiles qui existent et avec lesquelles nous travaillons afin de réaliser ce mémoire. Nous parlons ensuite des données que nous traitons. Celles-ci peuvent être de différents types (multimédia, hypermédia,...). Au cours de la réalisation de ce mémoire, nous nous appuyons également sur un logiciel existant : MediaCycle. Nous allons expliquer de façon brève et claire en quoi il consiste. Celui-ci est détaillé de manière beaucoup plus précise dans la Section 4.6. Pour terminer, nous parlons des solutions et des applications qui existent déjà sur le marché, ainsi que des apports supplémentaires que ce mémoire peut offrir en comparaison à ces applications. 2.1 Technologies mobiles Selon les articles publiés par le CNUCED 1 [10] et le Forum du Commerce International [23], les technologies mobiles changent le monde plus rapidement et plus profondément que toute autre innovation. Les tendances observées durant l année précédente, montrent une croissance rapide et continue de l utilisation de ces technologies. Aujourd hui, elles sont devenues la principale forme de connectivité et d accès aux TIC 2. A l heure actuelle, nous pouvons les distinguer suivant deux grandes catégories : la téléphonie mobile qui est présente depuis de nombreuses années et les tablettes qui envahissent les marchés Téléphonie mobile La téléphonie mobile, comme son nom l indique, est un moyen de communication par téléphone sans fil. Elle fut inventée dans les années 40 par le docteur Martin Cooper [43], Directeur de la recherche et du développement chez Motorola. Cependant, il faut attendre l année 1983 pour voir le premier téléphone mobile commercialisé par cette même marque. Ce moyen de communication s est largement répandu à la fin des années 90, grâce aux améliorations des composants électroniques et notamment leur miniaturisation. Bien que sa fonction d usage soit la communication vocale, cette évolution permet alors aux téléphones d acquérir des fonctions plus évoluées tels que l appareil photo, le Web, le GPS,... On parle alors de smartphone. Ces appareils font désormais logiquement partie de notre quotidien. 1. Conférence des Nations Unies sur le Commerce et le Développement 2. Technologies d information et de communication 3

9 Grâce aux informations annoncées par le CNUCED [10], nous pouvons résumer l utilisation des téléphones mobiles en quelques chiffres par : Huit fois plus de téléphones mobiles que de lignes fixes. Trois fois plus de téléphones mobiles que d ordinateurs personnels. Près de deux fois plus de téléphones mobiles que de téléviseurs Tablette PC La dénomination de tablette PC [42] sert en général à désigner un ordinateur mobile de la forme d une ardoise. Celui-ci est équipé d un écran tactile et ne possède pas de clavier physique. Ce terme a été rendu populaire grâce à un produit mis sur le marché en 2001 par Microsoft, un stylo-ordinateur. Celui-ci a tiré avantage des évolutions technologiques pour remettre au goût du jour un concept existant depuis de nombreuses années via Apple et Atari. Différent des PDA par la taille et des tablettes graphiques par son côté "PC", il n arrive cependant pas à s imposer, jusqu en 2010 et l arrivée de l ipad. L ipad d Apple a eu pour effet de revigorer le marché de la tablette PC. Dès lors, une guerre entre les différentes grandes marques du monde informatique a été déclenchée afin de conquérir ce nouveau domaine. Parmi celles-ci, nous pouvons citer comme étant le principal concurrent de l ipad, le Samsung Galaxy Tab sous Android. Volume des ventes de tablettes en 2010 : Selon Strategy Analytics [24], le volume des ventes de tablettes pour l année 2010 s élève à 17, 6 millions d unités, dont 14, 8 millions sont à mettre à l actif de l ipad. Cela représente 84% du marché. Avec 2, 1 millions de tablettes vendues au cours du dernier trimestre 2010 (T4), le Galaxy Tab semble offrir une alternative crédible à l ipad. Cependant, toujours d après Strategy Analytics, Apple devrait conserver plus de 70% du marché des tablettes en 2011 grâce au lancement de sa nouvelle perle : l ipad2. On estime les ventes de tablettes à 55 millions en 2011 dont 40 millions pour Apple. Les Figures 2.1 et 2.2 montrent le résultat des ventes en FIGURE 2.1 Nombre, en million d unités, de tablettes vendues au cours du 3 ème et 4 ème trimestres de 2010 (respectivement T3 et T4) ainsi que sur l ensemble de l année écoulée [24]. 4

10 FIGURE 2.2 Pourcentage des ventes au cours du 3 ème et 4 ème trimestres de 2010 (respectivement T3 et T4) ainsi que sur l ensemble de l année écoulée [24] 2.2 Types de médias Dans le Chapitre 1, nous avons affirmé que le logiciel MediaCycle pouvait travailler sur diverses données multimédias. Dans cette section, nous donnons une définition de ce que représente un média dans le monde d aujourd hui. En réalité, il existe des données multimédias, hypermédias et des rich médias. Nous allons définir ces trois types de données et voir les différences qui existent entre eux Média De façon générale en 2.2.1, nous allons définir ce qu est un média. Grâce à cela, il sera plus facile de comprendre les différents éléments mentionnés ci-dessus. Définition Un média [35] correspond à un moyen impersonnel de diffusion d informations. Il est utilisé pour communiquer avec un grand nombre d individus. Cependant, aucune personnalisation du message ou du contenu n est possible, on parle alors parfois de médias de masse. Les médias sont devenus un moyen de communication extrêmement important dans la société contemporaine. Ils sont, par exemple, le fondement du marketing et de la publicité. Actuellement, les sept principaux médias sont le langage, la presse, l affichage, le cinéma, la radio, la télévision et dernièrement Internet mais il en existe beaucoup d autres. Les trois premiers représentent des moyens de diffusion naturels, tandis que les autres sont des moyens de diffusion techniques Multimédia Le terme multimédia [36] a fait son apparition vers la fin des années 1980 avec la popularisation des CD-ROM et des bornes interactives. Il servait alors à désigner les applications qui mélangeaient différents médias simultanément tels que le son, la musique, l image ou la vidéo. Cela était désormais possible grâce à la capacité de stockage des CD-ROM et aux performances grandissantes des ordinateurs. Cependant, il faut attendre la fin des années 90 avec l arrivée des méthodes de compression audio et vidéo, liée à une croissance significative du nombre et de la puissance des ordinateurs, pour obtenir une qualité semblable aux divers autres médias réunis. Aujourd hui, le multimédia est considéré comme la convergence de médias textuels, d images, de vidéos et de sons dans un seul et même élément. D un point de vue informatique, une donnée multimédia fait appel à deux techniques proches, l hypertexte et l hypermédia. L hypertexte consiste à lier un ensemble de fichiers par un réseau de 5

11 relations non séquentiel. Grâce à ce réseau de liens, l utilisateur peut naviguer parmi les différents sujets sans se soucier de l ordre dans lequel ils sont rangés. On parle de navigation non-linéaire, contrairement à un fichier vidéo qui offre un contenu linéaire Hypermédia Un hypermédia [46] est un hypertexte présentant une différence essentielle. Il représente un média dans lequel les données ne sont pas seulement de type texte mais aussi de type image, son, vidéo ou même multimédia. De manière simple, un hypermédia est une combinaison de l hypertexte à des données multimédias, permettant d inclure des liens entre des éléments textuels, visuels et sonores. Comme nous l avons dit dans la Sous-Section 2.2.2, grâce au mécanisme d hypertexte, l entièreté des informations sont liées et offrent une navigation non-linéaire et interactive dans un ensemble de données textuelles, visuelles et sonores. La Figure 2.3 représente un exemple de document hypermédia où l utilisateur peut naviguer de page en page en cliquant sur les différents éléments multimédia. FIGURE 2.3 Exemple de document hypermédia [19] Le document hypermédia le plus simple et le plus connu à l heure actuelle n est autre que le World Wide Web. La quasi totalité des applications disponibles sur Internet optent désormais pour une architecture où l information est présentée en suivant cette approche. 6

12 2.2.4 Rich média La famille du rich média [5] est une appellation générique pour tous les formats permettant une interaction poussée avec l internaute. De ce fait, il est souvent associé à la notion d interfaces riches. Généralement, le rich média définit un format publicitaire Internet remplissant au moins une des conditions suivantes : Proposer aux utilisateurs une interaction au delà du clic habituel. Utiliser une technologie d affichage dynamique hors des espaces classiques prédéfinis. Intégrer du son ou de la vidéo. 2.3 Solutions existantes Comme énoncé dans le Chapitre 1, le but de notre application est d analyser des éléments sonores afin d extraire d une base de données du contenu audio ayant des caractéristiques similaires. Dans cette section, nous présentons les différentes applications existantes sur le marché des technologies mobiles et qui réalisent un travail similaire. Après quelques recherches, deux applications semblent se détacher des autres. La première se nomme Shazam et la seconde porte le nom de Midomi-SoundHound. Ces deux logiciels sont disponibles gratuitement sur l Android Market Shazam Shazam [31] est une application disponible pour les technologies mobiles dont le principe se base sur la reconnaissance musicale. L idée, développée en 2002 par Avery Li-Chun Wang, était uniquement disponible au Royaume-Uni. Aujourd hui, Shazam se décline dans tous les pays et sur tous les appareils mobiles. Il est l outil d identification musicale le plus utilisé et existe en deux versions. La version gratuite donne cinq identifications par mois à un utilisateur, contrairement à la payante qui offre un usage total. Fonctionnement De manière simple, Shazam [7] consiste à utiliser le microphone intégré aux dispositifs mobiles afin de capturer un morceau de musique (environ 30 secondes). Ensuite, des techniques de hachage et de fingerprinting sont appliquées sur le spectrogramme de l échantillon obtenu. Nous expliquons celles-ci de façon approfondie dans le Chapitre 3. Lorsque ces méthodes ont été appliquées, nous comparons les caractéristiques extraites avec celles disponibles dans une base de données. A l origine, la base de données utilisée pour Shazam contenait 1, 8 millions d entrées. Aujourd hui, on en compte plus de 8 millions. Si une correspondance est trouvée dans la base de données, des informations telles que l artiste, le titre de la chanson, le nom de l album,... sont retournées à l utilisateur. 7

13 Résultat La qualité de la recherche dépend de la qualité de l échantillon enregistré. Cependant, Shazam est réputé pour fonctionner de manière efficace même avec des morceaux sonores de qualité moyenne ou avec des bruits de fond. Les réponses obtenues sont correctes et rapidement affichées à l utilisateur Midomi-SoundHound Midomi-SoundHound a été développé il y a peu d années par un groupe de chercheurs californiens. Le principe de base est identique à celui proposé par Shazam. Cependant, Midomi- SoundHound va plus loin et offre non seulement une identification des musiques à partir d échantillons enregistrés mais aussi via des sifflements ou des fredonnements de la part de l utilisateur. Le fonctionnement des deux applications et les résultats obtenus sont similaires. Un bref comparatif est proposé en [4]. La Figure 2.4 montre le fonctionnement de Midomi-SoundHound suivant quatre étapes principales. A noter qu il en va de même pour Shazam. 1. A la première étape, un utilisateur à le choix entre capturer un extrait sonore, indiquer le nom d un artiste ou le titre d une chanson. 2. L extrait capturé est ensuite envoyé sur un serveur afin d être traité. L objectif est d extraire certaines caractéristiques qui seront utilisées pour effectuer la recherche dans la base de données. 3. La troisième étape consiste à faire correspondre les caractéristiques obtenues à celles présentes dans la base de données dans le but de trouver une correspondance. 4. Enfin, si une correspondance est trouvée, des informations telles que le titre, l artiste ou les paroles de la chanson sont retournées à l utilisateur. FIGURE 2.4 Fonctionnement de Midomi-SoundHound suivant 4 étapes [4] 8

14 2.4 MediaCycle MediaCyle est un logiciel d analyse de données multimédias. Celui-ci a été principalement développé par le laboratoire de Théorie des Circuits et Traitement du Signal (TCTS). Les méthodes utilisées pour son fonctionnement sont différentes de celles employées pour Shazam ou Midomi- SoundHound. A savoir, MediaCycle n intègre pas des techniques de hachage et de fingerprinting. Pour faire face à cet inconvénient, nous avons développé un prototype qui permet de réaliser de la recherche d empreinte. Celui-ci est détaillé dans la Section 3.5. D autres différences sont à énoncer, notamment au niveau de son utilisation. Premièrement, contrairement à Shazam et Midomi-SoundHound, MediaCycle n est pas limité à un seul type de média. Il peut être utilisé pour des données sonores ou visuelles sans nécessiter de changement. Evidemment, l analyse se fait suivant des descripteurs différents selon le type de données mais cette globalisation a pour avantage de rendre MediaCycle plus générique. Deuxièmement, nous savons que les deux applications présentées dans la Section 2.3 sont spécialisées dans la recherche de contenu identique. L utilisateur veut retrouver le titre de la chanson qu il entend et rien d autre. L idée de MediaCycle est plutôt axée sur une recherche des contenus "similaires". MediaCycle a déjà trouvé sa place dans de nombreux projets réalisés par Numédiart pour différents clients. Nous pouvons par exemple citer Laughter Cycle [14], Audio Cycle [13] ou encore le projet Dancers [34] dont nous pouvons voir le résultat en [1]. 2.5 Les apports du mémoire Le but est de développer une application Android afin de pouvoir profiter des avantages cités ci-dessus qu intègre Mediacycle par rapport à Shazam ou Midomi. L idée est évidemment d utiliser cette application sur les nouvelles technologies mobiles. Ensuite, l application sera développée de façon à offrir aux utilisateurs un outil de recherche novateur. Nous exposons dans le Chapitre 4 les différentes vues et méthodes de recherche qu il est possible d utiliser. Enfin, nous désirons offrir une application libre et gratuite aux utilisateurs. Comme nous l avons dit précédemment, MediaCycle peut travailler sur plusieurs types de médias. La nouveauté à ce niveau résidera dans le fait que les bases de données contenant ces médias seront constituées grâce à la contribution des utilisateurs. 9

15 Chapitre 3 Fingerprinting Dans ce chapitre, nous développons l ensemble des éléments théoriques liés à la technique du fingerprinting. Tout d abord, nous introduisons le sujet en le situant historiquement et dans différents domaines. Ensuite, nous proposons une définition de ce qu est le fingerprinting et dans la Section 3.3, nous parlons du principe d extraction d empreinte. Nous expliquons les différentes phases qui composent le processus d extraction et les descripteurs sonores que nous utilisons. Les méthodes de recherche d empreinte dans une base de données sont quant à elles expliquées en Section 3.4. La Section 3.5 permet de clôturer ce chapitre en présentant le protocole expérimental que nous avons mis en place. Afin d être le plus complet et le plus clair possible dans ce chapitre, nous nous basons principalement sur deux documents reconnus dans le milieu. Il s agit des articles publiés par J.A. Haitsma [21] et Yan Ke [48]. 3.1 Introduction Lorsque nous parlons d empreinte ou de fingerprint, nous pensons directement aux empreintes digitales. Cela vient inévitablement du fait qu il s agisse du système d empreinte le plus connu à ce jour. Il a été mis en place à partir de 1893 par Sir Francis Galton, qui a été le premier à prouver qu une empreinte digitale est unique et de ce fait qu il n existe pas deux humains ayant des empreintes identiques. Dès lors, même si parfois ces dernières possèdent des similarités, nous pouvons identifier n importe quel être humain via ses empreintes digitales. Récemment, au niveau du monde scientifique, nous notons à nouveau un intérêt croissant dans le domaine du fingerprinting. Ce soudain regain d intérêt n est pas provoqué cette fois par les empreintes digitales, mais par les empreintes de données multimédias, notamment audio. Les chercheurs croient que certains problèmes du domaine audio peuvent être naturellement dérivés en une forme accessible par les techniques informatiques. La principale idée est de transformer des signaux audio à une dimension dans le temps en des représentations visuelles 2D temps-fréquences. De manière simple, il s agit de transformer un son en une ou plusieurs images appelées spectrogrammes. Le principal objectif de la recherche d empreintes sur des données multimédias est de déterminer si deux données sont perceptivement équivalentes. Par perceptivement équivalent, nous entendons que la comparaison entre les deux objets multimédias ne s effectue pas au niveau de 10

16 leur contenu mais grâce aux empreintes associées. Aujourd hui, dans la plupart des systèmes qui utilisent la technologie de fingerprinting, les empreintes ainsi que les meta-data (nom de l artiste, titre de la chanson,...) d un grand nombre de données multimédias sont stockées conjointement dans la base de données. Dans ce type de base de données, les empreintes servent d index et sont utilisées pour effectuer des requêtes. Nous pouvons citer trois avantages à l utilisation de ces empreintes et non du contenu multimédias : 1. Diminution de la mémoire et des espaces de stockage nécessaires. En effet, nous ne gardons que les empreintes et celles-ci sont de plus petite taille que le contenu. 2. Comparaison efficace étant donné que les caractéristiques perceptives non pertinentes ont déjà été retirées des empreintes. 3. Recherche plus efficace et plus rapide de données car celles-ci sont plus petites. Deux grands domaines se partagent principalement cette technologie. Il s agit du contrôle de la diffusion des médias et de la reconnaissance de contenu audio. Le premier consiste à vérifier les données audio émises aussi bien à la télévision ou à la radio. Cela a pour avantage d examiner les droits de diffusion et de collecter des statistiques. Un exemple de site Web qui réalise cela est Yacast 1. Le second domaine trouve son intérêt dans le monde scientifique, pour les traitements sonores, mais aussi grâce à des applications telles que Shazam ou Midomi-SoundHound présentées dans la Section 2.3. Pour conclure cette introduction, nous pouvons dire d après ce que nous avons énoncé cidessus, qu un système de fingerprint est constitué de deux éléments principaux : une méthode d extraction d empreinte et une méthode efficace de recherche d empreinte dans une base de données. 3.2 Concepts et définition Dans cette section, nous définissons en quoi consiste une fonction de fingerprint, les caractéristiques nécessaires au fonctionnement d un système basé sur cette méthode et finalement, nous illustrons les différentes représentations que peut prendre une donnée audio Définition Si nous prenons en considération ce que nous avons décrit dans la section précédente, et que nous gardons à l esprit qu une empreinte audio peut être vue comme le "résumé" d un média sonore, nous pouvons énoncer la définition suivante : Définition Une fonction de fingerprint F devrait faire correspondre une donnée audio X, composée d un grand nombre de bits, à une empreinte de cette donnée, composée d un nombre limité de bits. Nous pourrions naturellement penser que les fonctions de hachage cryptographique sont de bons candidats pour les fonctions de fingerprint. Cependant, en considérant la Définition 3.2.2,

17 l égalité mathématique au sens "strict" exclu cette possibilité car nous sommes intéressé par des similarités perceptives et non de contenu identique. L Exemple illustre le concept de similarités perceptives. Définition Une fonction de hachage cryptographique permet de comparer deux objets, X et Y, de taille conséquente, en comparant les valeurs de hachage H(X) et H(Y). Si H(X) = H(Y) alors X = Y. Exemple Si l on prend une chanson de Michael Jackson - "Smooth Criminal". La version originale sur CD et la version MP3 à 128Kb/s vont être perçues de façon identique par l oreille humaine. Néanmoins, leurs structures internes (spectrogramme) peuvent être différentes. Bien que ces deux versions soient perceptivement similaires, elles sont mathématiquement différentes. Le dernier concept nécessaire pour finaliser notre définition est énoncé dans la Propriété Elle se base sur le fait que deux données audio perceptivement similaires ont des empreintes similaires. Propriété Afin de pouvoir faire une distinction entre deux données audio différentes, il doit y avoir une très forte probabilité que ces données différentes se traduisent par des empreintes différentes. De façon mathématique, nous pouvons dire que pour une fonction de fingerprint F, nous définissons un seuil T tel qu il existe une forte probabilité que X et Y soient similaires si F (X) F (Y ) T et différentes si F (X) F (Y ) > T Dans la propriété ci-dessus, définit une norme. Une norme est une fonction qui assigne une longueur strictement positive à tous les vecteurs dans un espace vectoriel. Cependant, elle peut aussi définir une distance entre deux vecteurs. Dans notre cas, nous pouvons donc considérer que F (X) F (Y ) est la distance entre deux spectres ou deux empreintes binaires. Il existe différents types de normes dont les plus connues sont : la norme euclédienne, la norme de Manhattan ou encore la ρ-norme. Si nous prenons comme exemple les séquences de bits ci-dessous, nous pouvons définir la norme euclédienne et la norme de Manhattan de la manière suivante : séquence séquence séquence séquence Norme euclédienne : la norme euclédienne est définie comme suit : x 2 = n x i 2 (3.1) Nous obtenons donc comme résultats pour les différentes séquences : i=1 séquence 1 0 séquence 2 1 séquence 3 1 séquence =

18 Norme de Manhattan : la norme de Manhattan est définie comme suit : x 1 = Nous obtenons dans ce cas ci pour les différentes séquences : n x i (3.2) i=1 séquence 1 0 séquence 2 1 séquence 3 1 séquence 4 2 A partir de cet exemple, nous pouvons dire que les différentes normes présentées ci-dessus peuvent convenir et être employées dans la propriété Grâce à la Définition et la Propriété 3.2.1, nous avons maintenant une définition claire et précise de ce qu est une fonction de fingerprinting ainsi que la principale propriété sur laquelle elle repose Caractéristiques Suite à notre définition de fingerprint, nous pouvons nous focaliser sur les caractéristiques nécessaires au bon fonctionnement d un système basé sur cette méthode. Robustesse : dans le but d avoir un système efficace, la recherche d empreinte doit être réalisée sur des caractéristiques perceptives invariantes à la dégradation des signaux. Idéalement, des données audio fortement dégradées devraient mener à des empreintes quasiment similaires. Fiabilité : elle correspond au nombre de comparaisons d empreintes qui ont réussi. Ce phénomène se produit lorsqu une identification retourne un résultat qui est celui attendu. Pour caractériser la fiabilité, nous pouvons mettre en avant les concepts de vrai positif et de faux positif. Ceux-ci seront développés dans la Section Taille de l empreinte : pour augmenter la rapidité de la recherche d empreintes, celles-ci sont généralement stockées en mémoire vive (RAM). La taille des empreintes, qu elles soient en bits par seconde ou bits par chanson, détermine fortement les ressources nécessaires pour la mise en place d une base de données d empreintes. Granularité : nous pouvons considérer la granularité comme étant la taille de la donnée, de l extrait à fournir à l application. Ce paramètre dépend du type d application mis en place et des données que celle-ci traite. Vitesse et croissance : ces deux critères sont essentiels lors d un déploiement commercial d un système de recherche d empreinte sonore. La vitesse de recherche dépend de la croissance de la base de données. Nous savons que la taille de celle-ci deviendra relativement importante avec le temps. Si la recherche effectuée par un utilisateur prend trop de temps, celui-ci délaissera le système pour un autre plus performant. 13

19 La mise en place d un tel système peut représenter un "challenge", car il requiert un équilibre entre ces cinq paramètres. Ces éléments ont une forte influence les uns sur les autres. Par exemple un système exigeant une haute fiabilité demande une empreinte de taille plus importante et une granularité plus élevée. L augmentation de la taille de l empreinte a pour effet de diminuer les performances de recherche dans la base de données où elle est stockée Représentation de l audio en images Dans cette sous-section, nous prenons le temps d illustrer les différentes représentations qui existent pour un média audio. Nous expliquons chacune d elles afin d avoir un aperçu et une bonne idée des données sur lesquelles nous travaillons dans la suite. Onde sonore Quand nous parlons de représenter un son, nous pensons directement à une onde sonore comme nous pouvons le voir dans la Figure 3.1. Ce graphique illustre l amplitude en fonction du temps. Cette vision du son est la plus courante car elle est fortement utilisée dans le monde de la musique, notamment des mixeurs et des ingénieurs du son pour ajuster leurs compositions. FIGURE 3.1 Représentation 2D d une onde sonore pour un extrait audio [2] Néanmoins, bien que couramment utilisée, cette représentation sera inutile car elle ne permet pas de réaliser des comparaisons d empreintes. Spectrogramme Comme nous l avons énoncé dans la Section 3.1, la seconde façon de représenter des données audio à une dimension, sous la forme d une image en deux dimensions, est le spectrogramme. Ceci est possible grâce à une technique appelée Transformée de Fourier. La Définition explique de manière plus technique en quoi consiste un spectrogramme. Définition Un spectrogramme [41] est une représentation spectrale des facteurs tempsfréquence (sous forme d une image) qui montre comment la densité spectrale d un signal varie avec le temps. Dans le domaine du traitement des signaux "temps-fréquence", il est l une des représentations les plus couramment utilisées. Aussi connu sous le nom de sonogramme ou encore empreinte vocale, ils sont utilisés pour identifier des sons, de la musique ou pour effectuer du traitement vocal. 14

20 Aujourd hui, il existe deux façons d illustrer un spectrogramme : une image en deux ou en trois dimensions. La Figure 3.2 montre une représentation en deux dimensions qui reste l approche majoritairement utilisée à l heure actuelle. FIGURE 3.2 Spectrogramme d un morceau de musique d une durée de 5 secondes et dont la fréquence est comprise entre 0 et 5000 Hertz [8] Exemple Nous clôturons cette sous-section en réalisant une analogie entre la visualisation d un même son sous la forme d une onde et d un spectrogramme. Cela permet de mieux observer les effets que produisent une modification de la fréquence sur les deux types de représentations. Nous voyons, par exemple, dans la Figure 3.3 que la fin du morceau analysé subit des variations de rythme importantes et cela se remarque très clairement dans son spectrogramme. FIGURE 3.3 Onde sonore et spectrogramme d un même extrait audio La zone encadrée de rouge de la figure ci-dessus, possède un spectrogramme de couleur plus foncée, plus intense. Dans cette zone se produit un changement de rythme musical important et la fréquence devient brusquement élevée. 15

21 En réalité, la notion de fréquence est directement liée à une autre notion que nous appelons longueur d onde. Cette dernière, correspond à la distance qui sépare deux pics ou deux creux successifs de la courbe de l onde sonore. Ces deux notions sont inversement proportionnelles. Ainsi, plus la longueur d onde est courte plus la fréquence est élevée, et inversement. Une longueur d onde courte signifie donc une vibration de l air, dans lequel se propage le son, plus rapide et par conséquent un son plus aigu. Les Figures 3.4 et 3.5 illustrent différents exemples de longueur d onde. FIGURE 3.4 Différentes longueurs d onde pour des sons graves ou aigus [26] FIGURE 3.5 Vibration des molécules d air en fonction de l onde sonore [22] Nous pouvons conclure que la zone mise en évidence dans la Figure 3.3, correspond à un extrait de la chanson où le son devient particulièrement aigu. Afin de réaliser les illustrations 3.2 et 3.3, nous avons utilisé le logiciel Praat développé par Paul Boersma et David Weenink [8]. Il s agit d un logiciel libre et gratuit qui permet d analyser, synthétiser et manipuler des données audio. Il offre en sortie des représentations graphiques de haute qualité de ces sons. 16

22 3.3 Extraction d empreinte Introduction Comme nous l avons dit dans les sections précédentes, l objectif principal des empreintes audio est de permettre une extraction efficace des caractéristiques perceptives. Cette action doit être facile et rapide à réaliser pour ne pas ajouter des contraintes supplémentaires à l ensemble du processus. Si nous nous basons sur ce qui est écrit dans la littérature actuelle, nous pouvons de façon générale séparer l ensemble des caractéristiques perceptives suivant deux grandes catégories : Caractéristiques sémantiques : cela peut être le genre, le rythme ou encore l ambiance. Ces caractéristiques sont facilement identifiables par l oreille humaine et servent à classifier la musique. Caractéristiques non-sémantiques : elles ont une nature plus mathématique et il est difficile pour les humains d arriver à les interpréter directement à partir de la musique. Parmi ces deux catégories, uniquement la seconde nous intéresse. Nous nous basons donc sur les caractéristiques perceptives non-sémantiques d extraits audio pour effectuer notre travail. Le choix d utiliser cette deuxième catégorie a été motivé par les inconvénients que présentent les caractéristiques sémantiques. A savoir : 1. Elles peuvent parfois être ambigües. Par exemple, le genre d une chanson peut dépendre de l opinion de la personne qui l écoute. Il peut aussi varier selon les époques. 2. Elles sont généralement plus compliquées à calculer que les non-sémantiques. 3. Elles ne sont pas universellement applicables. Si nous prenons par exemple une chanson de musique classique, il n est pas approprié de calculer le nombre de battements par minute Extraction d empreintes La majorité des algorithmes d extraction d empreintes suivent la même approche. Dans un premier temps, le signal audio est divisé en plusieurs trames. Ensuite, une représentation spectrale de ces dernières est calculée en appliquant une transformée de Fourier. L étape suivante consiste à créer un banc de filtre afin d obtenir les sous-empreintes ou sub-fingerprints. La phase finale a pour but d obtenir l empreinte binaire. L ensemble de ces étapes est détaillé dans la suite de cette sous-section. Pour ce faire, nous nous basons sur l article écrit pas Jaap Haitsma [21] car nous implémenterons la méthode qu il propose afin d obtenir une empreinte binaire de nos extraits musicaux. 1. Framing Le framing consiste à scinder chaque signal audio en blocs superposés de plus petite taille que l on appelle trames. Habituellement, nous utilisons un taux de recouvrement de 1/2 et des trames d une durée de 30ms. Le taux de recouvrement correspond à la superposition des différentes trames. Lorsque la valeur vaut 1/2, cela signifie qu arrivé à la moitié de la première trame, la seconde débute. La Figure 3.6 illustre ce que nous venons de dire. 17

23 FIGURE 3.6 Représentation du phénomène de recouvrement avec un taux de 1/2 Haitsma propose quant à lui, d utiliser un taux de recouvrement de 31/32 ce qui nous permet d obtenir une sous-empreinte toutes les 11.6ms comme représenté dans la Figure 3.7. En effet, nous voyons que la durée totale des trames superposées est de 371ms. Nous obtenons : 371ms 32 trames 11.6ms Nous avons donc 32 sous-empreintes toutes les 371ms et par conséquent 256 sous-empreintes après 3 secondes (371ms 8 3 secondes) ce qui est l objectif recherché. Un taux de recouvrement élevé garantit que même dans le pire des cas, c est à dire des signaux fortement dégradés, les sous-empreintes du morceau à identifier restent similaires aux sousempreintes d origine. Cela vient du fait qu avec un tel taux de recouvrement, les sous-empreintes successives ont de nombreuses similarités entre elles et qu elles varient très peu au cours du temps. FIGURE 3.7 Superposition des trames 18

24 2. Transformation de Fourier Tout d abord, nous allons définir précisément en quoi consiste la transformée de Fourier en Nous expliquons par la suite pourquoi nous l utilisons. Cette action sert à préparer la phase 3 dans laquelle nous allons créer un banc de filtre. Définition La transformée de Fourier discrète (TFD) [44] est un outil mathématique de traitement du signal numérique. Nous avons tendance à le confondre avec la transformée de Fourier rapide (Fast Fourier Transform) définit en 3.3.2, qui n est pourtant qu un algorithme particulier de calcul de la transformée de Fourier discrète. Sa définition mathématique pour un signal s de N échantillons est la suivante : S(k) = N 1 n=0 s(n) e 2iπk n N pour 0 k < N (3.3) Nous obtenons ainsi une représentation spectrale discrète du signal échantillonné s(n). La TFD permet seulement d évaluer une représentation spectrale discrète (spectre échantillonné) d un signal discret (signal échantillonné) sur une fenêtre de temps finie (échantillonnage borné dans le temps). Définition La transformée de Fourier rapide [45] est un algorithme de calcul de la transformée de Fourier discrète (TFD). Cet algorithme est couramment utilisé en traitement numérique du signal pour transformer des données discrètes du domaine temporel dans le domaine fréquentiel, en particulier dans les analyseurs de spectre. Afin de réussir à comprendre la Formule 3.3, nous allons détailler un peu plus chaque élément qui la compose. S(k) correspond au résultat de la transformée de Fourier discrète. Ce résultat est en réalité un vecteur de nombre. Comme énoncé ci-dessus, il s agit d une représentation spectrale discrète du signal échantillonné. En terme simple, il s agit du spectre obtenu après avoir appliqué la transformée de Fourier. Nous pouvons voir dans la Figure 3.9 à quoi correspond S(k). La valeur k représente le cycle de la transformée. s(n) correspond au signal échantillonné où n [0, N 1]. e 2iπk n N est appelé l exponentielle complexe discrète. Dans celle-ci, k représente le nombre de cycle appliqué et 2π/N la période du signal échantillonné. Cette exponentielle peut être décomposée de façon à être égale à cos(2πk n ) + i sin(2πk n ). De cette équation, nous ne N N retiendrons que la partie réelle, c est à dire cos(2πk n ). N Désormais, nous pouvons visualiser la Formule 3.3 de la manière suivante : S(0) S(1)... S(N 1) = e 2iπ0 0 N e 2iπ0 1 N... (N 1) 2iπ0 e N e 2iπ1 0 N e 2iπ1 1 N... (N 1) 2iπ1 e N... e 2iπ(N 1) 0 N e 2iπ(N 1) 1 (N 1) 2iπ(N 1) N... e N 19 s(0) s(1)... s(n 1) (3.4)

25 Pour les différentes valeurs de k, nous allons multiplier les valeurs du signal échantillonné par celles illustrées dans la Figure 3.8. Plus la valeur de k augmente plus on accentue les hautes fréquences (les périodes sont plus courtes). FIGURE 3.8 Partie réelle de l exponentielle complexe suivant la valeur de k Nous pouvons dire que la transformée de Fourier discrète peut-être vue comme une transformation linéaire appliquée au vecteur s(n) afin de retourner le vecteur S(k). L intérêt d effectuer cette transformation est que les caractéristiques perceptives les plus importantes pour l extraction d empreinte se trouvent au niveau de la fréquence. Dès lors, nous appliquons sur chaque trame produite à l étape précédente une transformée de Fourier rapide, afin d obtenir une représentation spectrale du signal audio (c.f. Figure 3.2). La Figure 3.9 montre un spectrogramme ou les points de forte densité sont en rouge. Ils représentent les points les plus importants du spectrogramme. FIGURE 3.9 Spectrogramme montrant des points de forte densité [37] 20

26 La Figure 3.10 schématise les deux premières étapes du processus. Nous y voyons les différentes phases ainsi que les résultats obtenus à chaque niveau. FIGURE 3.10 Schéma des deux premières phases [29] 3. Division en bandes Grâce aux transformées de Fourier effectuées à l étape précédente, nous pouvons désormais créer un banc de filtres. Le but est d obtenir une représentation compacte d une seule trame appelée sous-empreinte ou sub-fingerprint. Le signal audio initial est décomposé en sous-signaux de manière à ce que chaque bande ne comporte qu une seule fréquence. Ce processus de décomposition porte le nom d analyse. Cependant, une seule de ces sous-empreintes ne suffit pas pour identifier un morceau audio car elle ne contient pas assez de données. Si nous nous basons une nouvelle fois sur l article de Haitsma [21], nous allons travailler dans la suite de ce chapitre avec des blocs d empreintes composés, par exemple, de 256 sous-empreintes. Il existe plusieurs échelles lors de la réalisation d un banc de filtres. Nous pouvons principalement citer l échelle Bark ou encore l échelle Mel. Nous allons expliquer en quoi elles consistent. Echelle de Bark : Le Bark [29] est une unité de psychoacoustique, et non physique, proposé par Eberhard Zwicker en L échelle de Bark consiste à diviser l échelle des fréquences en 24 bandes dites bandes critiques comprises entre 0 et Hz. Ce système permet de modéliser une meilleure approximation de l audition humaine. Les bandes de Bark sont utilisées pour calculer l intensité, la netteté ou la propagation du son. La Figure 3.11 montre la répartition des bandes de Bark de manière graphique. Les valeurs précises correspondantes, peuvent être lues dans le Tableau 3.1. La conversion d une fréquence en Hertz vers des Bark se fait à l aide de la formule suivante, dans laquelle B exprime la fréquence en Bark et f en Hertz. ( ) ( ) f f B = 13 arctan arctan

27 Grâce à l échelle de Bark, il est possible de calculer une certaine énergie pour chaque sousempreinte. Celle-ci aura un rôle important dans la dernière phase du processus d extraction. Cette énergie peut être calculée à l aide de l équation suivante : E de la bande i = k B i (k) S(k) 2 (3.5) Dans cette équation, B i (k) représente la valeur de la bande i. Par exemple, si nous prenons la bande 23, en orange dans la Figure 3.11, les fréquences inférieures à 12000Hz ainsi que celles supérieures à 15500Hz ont une valeur de B 23 (k) égale à 0. Pour les fréquences comprises entre et 15500Hz la valeur de B 23 (k) sera égale à 1. L énergie s obtient donc en multipliant cette valeur par le résultat de la transformée de Fourier. Plus il y aura de sons dans une même bande, plus la fréquence sera élevée et plus l énergie sera importante. FIGURE 3.11 Les bandes de Bark [29] barks f (Hz) f (HZ) barks f (Hz) f (Hz) barks f (Hz) f (Hz) TABLE 3.1 Valeurs des bandes de Bark 22

28 Echelle de Mel : Les Mel-Frequency Cepstral Coefficients (MFCC) [39] sont des coefficients cepstraux (voir Définition 3.3.4) calculés à partir du spectre de puissance d un signal. Cette notion est expliquée dans la Définition Définition Le spectre de puissance [15] donne pour toute valeur de la fréquence la puissance transportée par cette fréquence. Le terme puissance se rapporte à une énergie moyenne transportée par unité de temps. Définition Le cepstre [38] d un signal x(t) est une transformation de ce signal du domaine temporel vers un autre domaine analogue à ce dernier. Pour rappeler le fait que nous effectuons une transformation inverse à partir du domaine fréquentiel, les dénominations des notions sont des anagrammes de celles utilisées en fréquentiel. Ainsi le spectre devient le cepstre, la fréquence une quéfrence, un filtrage un liftrage,... Les bandes de fréquence de ce spectre sont espacées logarithmiquement selon l échelle de Mel comme représenté graphiquement dans la Figure Cette échelle a été proposée en 1937 par Stevens, Volkman et Newman et correspond à une échelle de fréquences basée sur la perception auditive humaine. Elle a été conçue de telle façon que 1000 Hz correspondent à 1000 mels et qu une variation constante dans le domaine des mels soit perçue comme une variation constante de fréquence (en Hz) par les auditeurs. Ce phénomène est illustré dans l Exemple Exemple Si nous considérons une fréquence de base de 1000 Hz, alors la fréquence à l octave supérieure planche à 2000 Hz. Cependant, un son à cette fréquence ne sera pas perçu par un auditeur comme étant deux fois supérieur à la fréquence de base. Par contre, si nous effectuons le changement d octave dans le domaine des mels, 1000 Hz correspondent à 1000 mels. L octave supérieure est donc à 2000 mels, ce qui équivaut à environ 3428 Hz. Un son ayant une telle fréquence sera donc perçu comme étant deux fois plus aigu qu un son à 1000 Hz. Comme dans le cas de l échelle de Bark, il est possible de convertir une fréquence (Hz) en Mel. Dans la formule donnée ci-dessous, M est la fréquence exprimée en Mel, f en Hertz et f c = 1000 Hz. { M = f ( ( )) pour f < 1000Hz f M = f c 1 + log 10 f c pour f > 1000Hz Enfin, l échelle de Mel permet aussi pour chaque trame de calculer une certaine énergie. Celle-ci trouve aussi son utilité dans la dernière phase du processus. L équation nécessaire au calcul de cette énergie est identique à celle employée pour les bandes de Bark. Cependant, dans le cas des bandes de Mel, la valeur de la bande peut être comprise entre 0 et 2. Par exemple, si nous prenons la bande 23 et une fréquence de 20000Hz, la valeur de la bande sera égale à

29 FIGURE 3.12 Les bandes de Mel [29] 4. Empreinte binaire La dernière étape du processus, consiste à extraire une sous-empreinte à partir de chaque trame. Dans notre cas, nous choisissons d extraire des sous-empreintes de 32 bits. Pour ce faire, les 33 bandes obtenues à l étape antérieure sont sélectionnées. Celles-ci ont une fréquence comprise entre 300 et 2000 Hz car il s agit des fréquences les plus pertinentes du système auditif humain. Elles sont également espacées logarithmiquement suivant l échelle de Bark ou l échelle de Mel. Dans la phase précédente, nous avons exprimé le fait qu appliquer Bark ou Mel produisait une certaine énergie. C est maintenant que celle-ci va intervenir. En effet, dans de nombreux traitements, il a été expérimentalement prouvé que le signe des différences d énergie est une propriété très robuste. Dans notre cas, si nous notons l énergie de la bande m de la trame n par E(n, m) et le bit m de la sous-empreinte n par F (n, m), les bits qui composent notre sous-empreinte sont définis de la façon suivante : F (n, m) = { 1 si (E(n, m) E(n, m + 1)) (E(n 1, m) E(n 1, m + 1)) > 0 0 si (E(n, m) E(n, m + 1)) (E(n 1, m) E(n 1, m + 1)) 0 (3.6) Afin d illustrer ce qui est proposé dans l équation 3.6, nous pouvons observer la Figure Dans celle-ci, nous voyons que la croissance d énergie de la trame n 1 à la trame n dans la bande m est plus importante que celle de la bande suivante (m + 1). La valeur de F (n, m) sera donc égale à 1. De plus, il est désormais facile de comprendre pourquoi 33 bandes sont nécessaire afin de calculer 32 bits. En effet, nous nous basons sur les énergies de la bande suivante (m + 1) afin de calculer les bits de la bande courante (m). 24

30 FIGURE 3.13 Représentation visuelle du calcul de F(n,m) selon les différentes énergies La Figure 3.14, correspond au résultat final du processus établi. Il s agit d une séquence de 256 sous-empreintes de 32 bits chacune. Elle représente deux extraits d une même chanson, l un provenant du CD original (a) et l autre étant une version MP3 (b). Dans ces images, un bit "1" correspond à un pixel blanc et "0" à un noir. Idéalement, ces deux séquences d empreintes auraient dû être les mêmes. Cependant, suite à la compression et la perte de qualité, nous pouvons voir les différences en noir dans l image (c). FIGURE 3.14 Représentation d un son sous forme binaire [21] 25

31 Les quatre étapes du mécanisme d extraction d empreinte sont illustrées par la Figure FIGURE 3.15 Schéma de l extraction d empreinte [21] 3.4 Recherche et correspondance dans une base de données Une fois l empreinte extraite, il n est pas trivial de rechercher et de trouver une correspondance dans une base de données d empreintes. Tout d abord, il faut se souvenir que nous recherchons un contenu similaire et pas forcément identique. L opération de recherche doit donc être réalisée en acceptant une certaine marge d erreur. Ensuite, pour pouvoir effectuer une recherche rapide et efficace, la taille de la base de données doit être prise en compte. Afin d illustrer l importance de nos propos, nous allons évaluer le nombre de sous-empreintes disponibles pour une base de données de chansons ayant une taille moyenne de 5 minutes (300 secondes). Si nous nous souvenons que 256 sous-empreintes sont produites pour un extrait de 3 secondes, nous obtenons : Nombre de sous-empreintes = = 256 millions Avec une telle quantité de données en notre possession, il est vital d avoir une méthode de recherche efficace. Dans le cas contraire, les temps de recherche rendraient le système inutilisable. Il est par exemple inconcevable d envisager l accès à chaque élément afin de déterminer si celui-ci correspond à la recherche. Si l on sait qu une sous-empreinte est enregistrée sous la forme d un double, à savoir 8 octets, il s agit alors d accéder à environ 2Go d informations. Par la suite, nous 26

32 présentons les différentes structures et méthodes de recherche qui existent. Nous commençons par expliquer la moins compliquée et la moins performante pour finir avec la plus performante LookUp table La première structure qui permet d effectuer la recherche de sous-empreintes est une table de lookup. Il s agit d un simple tableau dans lequel nous stockons les 2 32 combinaisons obtenues à partir des séquences de 32 bits. Chaque entrée dans cette table pointe vers une liste qui contient la position de la sous-empreinte dans le morceau original. Ce mécanisme est illustré dans la Figure FIGURE 3.16 Fonctionnement de la lookup table [21] Bien que très simple d un point de vue conceptuel, cette façon de faire est impossible à mettre en pratique. En effet, une table de lookup, contenant 2 32 entrées, atteint les limites mémoire de la quasi totalité des ordinateurs présents sur le marché. La capacité mémoire requise est de octets 32 Go. De plus, même avec une machine capable de supporter la contrainte précédente, notre table ne serait que partiellement remplie car elle ne pourrait pas entièrement tenir en mémoire vive. Avantage Temps d accès dans la table de lookup en O(n) où n correspond au nombre de données dans la table Inconvénients Taille de la mémoire nécessaire. Impossible de garder toute la table en RAM. 27

33 3.4.2 Hachage Une solution alternative aux tables de lookup, consiste à utiliser la technique de hachage. Pour détailler cette technique, nous nous basons sur le livre "Introduction to Algorithms" écrit par T. Cormen, C. Leiserson et R. Rivest [12]. Nous expliquons en quoi consiste le hachage, le procédé d une table de hachage et comment choisir une bonne fonction de hachage. Nous clôturons cette sous-section en développant deux techniques : le Locality Sensitive Hashing et le Min Hashing. Introduction Aujourd hui, de nombreuses applications nécessitent un ensemble dynamique qui supporte uniquement les opérations Insert, Search et Delete (ex : compilateur Java, C++,...). La table de hachage est une implémentation efficace de la table d association ou du dictionnaire. Ces deux structures supportent les 3 opérations précédentes et consistent à associer une clé à une valeur. Une table de hachage est une généralisation d un tableau classique en utilisant la notion d adressage direct. En général, le but est d examiner ou de rechercher une position arbitraire dans un tableau en temps constant, O(1). Adressage direct L adressage direct est une technique simple qui fonctionne efficacement lorsque l univers des clés U est petit. Supposons que U soit de la forme U = {0, 1,..., m 1}, où m est un entier pas trop grand, et que deux éléments distincts aient des clés distinctes. Pour représenter un ensemble dynamique, nous utilisons une table d adressage direct T [0...m 1], dans laquelle chaque position correspond à une clé dans l univers U. Les opérations de recherche, d insertion et de suppression sont réalisées en O(1). La Figure 3.17 illustre le fonctionnement d une table d adressage direct. FIGURE 3.17 Table d adressage direct [12] 28

34 Table de hachage Le risque d utiliser des tables d adressage direct est évident. Si l univers U des clés est très grand, stocker un tableau T de taille U peut devenir impossible. En effet, nous retombons sur le cas des tables de lookup de la sous-section précédente. L idée fondamentale des tables de hachage est de se ramener au cas de l adressage direct, c est à dire de clés correspondant à des indices dans un tableau. Cependant, contrairement au cas précédent où un élément avec une clé k est stocké en position k, celui-ci va maintenant être stocké en positions h(k). On dit que h est une fonction de hachage tel que h fait correspondre l univers U aux positions de la table de hachage T [0..m 1] : h : U {0, 1,..., m 1} L objectif d une telle fonction est de réduire le nombre d indices à gérer. Au lieu de U valeurs, nous n en traitons plus que m. Le choix d une fonction de hachage adéquate est discuté par la suite. Cependant, nous devons désormais affronter une difficulté. En effet, deux clés distinctes k 1 et k 4 peuvent avoir des valeurs hachées identiques h(k 1 ) = h(k 4 ) (voir Figure 3.18). On dit qu une collision est survenue. La question est de savoir ou ranger l information associée à k 4 si l emplacement dans la table est déjà occupée par k 1? La solution idéale serait d éviter les collisions grâce à une fonction de hachage optimale. Mais cette solution est en pratique impossible et dans le meilleur des cas nous pourrons seulement limiter leurs apparitions. La méthode la plus simple pour résoudre ce problème est appelée le chaînage. Cela consiste à mettre tous les éléments d information dont les clés ont une même valeur de hachage dans une liste chainée. La Figure 3.18 montre une table de hachage avec une résolution des collisions par chaînage. Cette structure est celle utilisée dans notre prototype. FIGURE 3.18 Table de hachage avec chaînage [12] 29

35 Fonction de hachage Avant toute chose, rappelons qu une fonction de hachage est une fonction de la forme h : U {0,..., m 1}. Afin d être considérée comme efficace, une fonction de hachage doit se rapprocher le plus possible d une répartition uniforme des éléments. De manière formelle, cela signifie que si nous donnons une probabilité P sur U et que nous choisissons aléatoirement chaque clé k dans U, nous ayons j avec 0 j m 1, {k h(k)=j} P (k) = 1 m Trois méthodes principales existent afin de générer des fonctions de hachages satisfaisantes : La méthode par division : consiste à faire correspondre une clé k dans une des m positions en prenant le reste de k divisé par m. La fonction est donnée par : Avantages : h(k) = k mod m Très simple à mettre en place. La fonction modulo est intégrée à la majorité des langages de programmation. Inconvénient : Certaines valeurs sont à éviter dans le choix de m. En effet, si m = 2 p alors h(k) correspond aux p bits d ordre inférieur de k. La méthode par multiplication : premièrement il faut multiplier la clé k par une constante A dans le rang 0 < A < 1 et extraire la partie fractionnelle de ka. Ensuite, nous multiplions cette valeur par m et nous prenons la valeur entière inférieure. On a : h(k) = m(ka mod 1) Où "ka mod 1" représente la partie fractionnelle de ka, qui est ka ka. Avantage : Aucune valeur de m n est critique. Inconvénient : Légèrement plus complexe à mettre en oeuvre que la méthode par division. Le hachage universel : consiste à choisir la fonction de hachage de façon aléatoire et totalement indépendante des clés qui doivent être traitées. 30

36 Avantage : Cette méthode, permet d éviter les cas de piratages où un individu pourrait choisir n clés qui donneraient une même valeur hachée. La table de hachage deviendrait une liste chaînée et perdrait tous ses avantages Locality Sensitive Hashing (LSH) Bien que nous n utiliserons pas les méthodes de LSH et de Min-Hash dans notre prototype, celles-ci apparaissent régulièrement dans la quasi totalité des littératures. Afin de rester complet sur le domaine du fingerprinting, nous allons donc en parler brièvement pour comprendre leur fonctionnement. La technique de locality-sensitive hashing a été introduite par Indyk et Motwani [20]. Il s agit d une méthode de recherche approximative dans des espaces de grande dimension. L idée principale est que la probabilité de collision entre deux points p et q est liée à la distance qui les sépare. De manière simple, plus les points seront proches dans l espace d origine, plus la probabilité d avoir la même valeur de hachage est forte. Posons D(.,.), une fonction de distance pour les éléments d un ensemble S. Pour tout p S posons B(p, r) comme l ensemble des éléments de S à une distance r de p. Grâce à la Définition nous avons : Définition Une famille H de fonctions de S à U est appelé (r 1, r 2, p 1, p 2 )-sensitive pour D(.,.) si q, p S on a : si p B(q, r 1 ) alors P r H [h(q) = h(p)] p 1 si p / B(q, r 2 ) alors P r H [h(q) = h(p)] p 2 Par construction, ces fonctions de hachage doivent permettre aux points proches d entrer fréquemment en collision et inversement, les points éloignés ne doivent entrer que rarement en collision Min-Hash Le principe de Min-Hash a été inventé par Andrei Broder en 1997 [3]. Il consiste à estimer rapidement la similarité entre deux ensembles en se basant sur les coefficients de similarité de Jaccard. Pour deux ensembles C i et C j nous avons : sim J (C i, C j ) = C i C j C i C j Le résultat est compris entre 0 et 1. Zéro signifie que les deux ensembles sont disjoints, et un qu ils sont identiques. Si nous prenons les exemples ci-dessous nous avons : 31

37 C i C j sim J (C i, C j ) = 2/5 = TABLE 3.2 Exemple pour la similarité de deux ensemble de bits C i C j Yes No Yes Yes Yes No sim J (C i, C j ) = 1/4 = 0.25 Yes No TABLE 3.3 Exemple pour la similarité de deux ensemble de données C i C j 7 4 C i C j = {1, 2, 3, 4, 5, 7, 9} 3 1 C i C j = 1, 4, sim J (C i, C j ) = 3/7 = TABLE 3.4 Exemple pour la similarité de deux ensemble de données De manière simple, nous pouvons prendre une fonction de hachage h qui fasse correspondre les éléments de C i aux éléments de C j tel qu on ait : P h(c i ) = h(c j ) = sim J (C i, C j ) Où h(c i ) est l indice de la première ligne contenant un 1 de la colonne C i. La technique de Min-Hash trouve sa place dans différents projets multimédia. Initialement, cette technique avait un intérêt dans les méthodes de clustering et d élimination de documents dupliqués au travers du Web. Désormais, celle-ci n est plus uniquement restreinte à ce type de documents et s applique également sur des données comme les images. En 2003, Schleimer, Wilkerson et Aiken [30] se servent de Min-Hash comme élément central dans un schéma pour la détection du plagiat. Le principe se base sur la recherche d extraits textuels copiés à partir d une base de données de documents digitaux. Finalement, nous observons aussi l utilisation de Min-Hash dans le domaine du datamining. Cohen et al. [11] utilise cette technique afin de créer des règles d association. 32

38 3.4.5 Motivation de nos choix Bien que nous en parlons dans ce rapport, nous avons décidé de ne pas employer ces deux techniques de hachage dans notre prototype. En effet, les premiers résultats que nous avons obtenus en implémentant une simple table de hachage ont été satisfaisants. Nous avons donc pris la décision de ne pas compliquer directement l implémentation du prototype en y intégrant une structure plus complexe. Les résultats sont donnés dans la Sous-Section

39 3.5 Protocole expérimental Nous clôturons ce chapitre en présentant le protocole expérimental que nous avons mis en place. Premièrement, nous avons rassemblé un certain nombre de chansons auxquelles nous avons ajouté différents effets sonores. Par la suite, nous avons développé un prototype d extraction d empreinte basé sur le schéma de Haitsma [21]. Le but final est d observer l impact de ces différents effets sur l identification d empreinte Mise en place du protocole L étape initiale consiste à réunir un nombre important de chansons afin de constituer une base de données. Notre choix s est porté dans un premier temps sur cent. D après ce qui a été dit dans les sections précédentes, cent chansons représentent approximativement sous-empreintes. Cela est largement suffisant pour les tests que nous allons réaliser. Les chansons ont quant à elles été choisies suivant deux critères principaux. Tout d abord, nous avons essayé de varier le plus possible le style afin d augmenter la diversité de la base de données. Nous avons donc des chansons de la variété française, du rock, du rap,... Cette variation de style provoque également des extraits musicaux où le timbre et le rythme sont différents. Enfin, les chansons choisies sont des fichiers MP3 de haute qualité pour que l expérience soit la plus réaliste possible. La seconde phase de cette mise en place a pour but d obtenir un ensemble d empreintes. Celles-ci seront utilisées pour effectuer les recherches dans la base de données. Nous avons créé cet échantillon de test grâce au logiciel SoX [27]. Ce logiciel a vu le jour le 5 juin 1991 grâce à Lance Norskog et a été repris en 1995 par Chris Bagwell. Il s agit d un programme en ligne de commande, qui permet d effectuer un grand nombre d actions sur des données sonores. Pour chaque chanson originale, cinq fichiers perturbés ont été générés : Un fichier audio MP3@128kbps Commande : sox test.mp3 -C 128 test128kbps.mp3 Un fichier audio MP3@64kbps Commande : sox test.mp3 -C 64 test64kbps.mp3 Un second fichier audio MP3@32kbps Commande : sox test.mp3 -C 32 test32kbps.mp3 Un fichier dans lequel nous avons modifié le bass et le treble Commande : sox test.mp3 testbasstreble.mp3 bass treble Un dernier fichier pour lequel nous avons modifié le bandpass Commande : sox test.mp3 testbandpass.mp3 bandpass L explication ainsi que de nouvelles commandes sont données en Annexe B. 34

40 3.5.2 Implémentation du prototype La partie centrale de ce protocole expérimental consiste à développer un outil de recherche d empreintes. Le langage que nous avons choisi pour implémenter notre programme est le Java. Nous présentons donc ce langage et les fonctions principales de notre prototype. Une explication détaillée de l utilisation du prototype est donnée en Annexe C. Le Java Java [28] est un langage qui connait depuis de nombreuses années un grand succès. Une multitude de détails font que dans de nombreux cas, Java s avère être un choix judicieux. Premièrement, nous pouvons mettre en évidence le caractère orienté objet de Java. Ce dernier a pour conséquence une découpe logique du code en entités de plus petites tailles. Les avantages d une telle structuration du code sont : 1. Un code plus simple à maintenir. 2. Un code plus facilement réutilisable. 3. Un code intrinsèquement modulaire. Sachant qu une fois ce mémoire terminé, la maintenance et l évolution future du code sera reprise par une personne tierce, ces qualités sont essentielles. Ensuite, puisque nous voulons que notre application soit utilisée par quiconque en ayant le besoin, il faut que celle-ci soit la plus portable possible. Par là, nous entendons qu elle fonctionne de façon optimale quelque soit la machine utilisée ou le système d exploitation installé. Java, grâce à l utilisation de sa machine virtuelle, possède cette caractéristique qui est primordiale pour une bonne distribution de notre outil de recherche d empreintes. Enfin, la conception d une interface graphique facilitant l utilisation du programme est envisagée. Java, de par sa librairie Swing, offre tous les outils pour réaliser cette tâche de manière simple et efficace. Les fonctions principales Dans cette partie, nous expliquons les fonctions que nous avons développées et qui permettent d effectuer une recherche d empreinte. Chacune de celles-ci est illustrée par un pseudo code afin de facilement comprendre son exécution. La première étape consiste à décoder la séquence de 32 bits obtenue par la méthode d Haitsma. Pour ce faire, nous nous basons sur la méthode d Horner [40] qui permet de calculer la valeur d un polynôme en un point x 0. De façon mathématique, nous avons : Soit P = a n X n +a n 1 X n a 0 un polynôme et x 0 un nombre. La valeur du polynôme P en un point x 0 vaut P (x 0 ) = a n x n 0 + a n 1 x0 n a 0. A partir de la, nous pouvons penser qu il est nécessaire de calculer chacune des puissances de x 0, multiplier celle-ci par son coefficient a i (0 i n) et enfin réaliser la somme de ce que nous avons obtenu. Le nombre de produits a réaliser si on calcule x n 0 en multipliant successivement x 0 par lui même est de l ordre de n(n+1)/2. 35

41 La méthode d Horner consiste à améliorer ce résultat en proposant d effectuer le calcul de la manière suivante : P (x 0 ) = ((...((a n x 0 + a n 1 )x 0 + a n 2 )x )x 0 + a 1 )x 0 + a 0 Grâce à ce procédé, le nombre de produit réalisé est alors réduit à n, diminuant de ce fait le temps de calcul d une fonction polynomiale. Un autre avantage de cette méthode est qu elle permet également d effectuer une conversion rapide d un nombre écrit en base N, en écriture en base 10 (décimale). En effet, si un nombre s écrit en base N, ce nombre vaut a n N n +a n 1 N n a 0. La Figure 3.19 illustre le fonctionnement de la méthode d Horner sur nos séquences de 32 bits. A la première étape, val prend la valeur du premier bit de la séquence. Nous pouvons le voir à la ligne 6 de l Algorithme 1. Pour les étapes suivantes, la valeur obtenue à l étape précédente est multipliée par 2 et on lui ajoute ensuite la valeur du bit courant (0 ou 1). A la fin de l exécution, nous aurons la valeur décimale de la séquence choisie. FIGURE 3.19 Conversion d une séquence de bits en valeur décimale Algorithm 1 Convert Input : binaire : séquence de 32 bits sous forme de String 1: val 0 2: taille length(binaire) 3: for i = 0 to taille do 4: bit binaire.charat(taille-1-i) 5: if i = 0 then 6: val bit 7: else 8: val val 2 + bit 9: end if 10: end for 11: return valeur 36

42 Une fois la séquence décodée, nous pouvons la passer à la fonction de hachage. Cette dernière, se base sur la méthode de hachage par division car elle permet une meilleure répartition des sous-empreintes dans notre table de hachage. Le pseudo-code de l Algorithme 2 illustre nos propos. Dans celui-ci, la valeur 2 32 /10 3 correspond à la taille choisie pour notre table de hachage. Algorithm 2 HashFunction Input : valeur : séquence de 32 bits décodée sous forme de double 1: hashpos valeur mod(2 32 /10 3 ) 2: return (int) hashpos La valeur hachée obtenue indique la position à laquelle la donnée doit être stockée dans la table de hachage. La structure de cette dernière est un tableau où chaque position contient une référence vers une liste chainée. Un élément de la liste chainée est quant à lui représenté par une paire "clé-valeur". La clé correspond à la séquence de 32bits décodée sous la forme d un double. La valeur quant à elle est un ArrayList de String contenant les identifiants de chaque chanson où la sous-empreinte a été identifiée. La Figure 3.20 schématise notre structure pour la table de hachage. Pour des raisons évidentes de clarté, nous n avons pas intégré le pseudo-code de ces deux structures directement dans ce rapport. Cependant, ceux-ci sont disponibles en Annexe A. FIGURE 3.20 Structure de la table de hachage 37

43 Les opérations de Recherche, d Insertion et d Identification : La recherche d une séquence dans la table de hachage se fait en deux grandes phases. Premièrement, il faut identifier l emplacement dans la table où la séquence de bits peut se trouver. Ensuite, il faut parcourir la liste chainée associée à cet emplacement afin de déterminer la position de la séquence. Nous analysons ces phases suivant le meilleur des cas, le cas moyen et le pire des cas. Peu importe la situation, nous savons que grâce à notre fonction de hachage, l identification de l emplacement d une séquence dans la table de hachage se fera en O(1) (accès direct). Il suffit donc d analyser la seconde phase qui constitue la recherche dans la liste chainée : Rappel : n correspond au nombre total des données présentes dans la table de hachage. m correspond au nombre de données qui se trouvent dans une liste chainée associée à un emplacement de la table. Le meilleur des cas : La fonction de hachage donne une parfaite répartition des n données dans les différentes listes. Pour la liste sélectionnée, la donnée que nous recherchons se trouve en première position. Nous avons donc O(1) + O(1) = O(1). Le cas moyen : La complexité en moyenne est plus difficile à estimer que le meilleur cas et le pire cas. Pour ce faire, il faut considérer deux situations : une recherche avec succès et une recherche avec échec. Nous allons détailler ces deux situations pour bien les comprendre. Hypothèse : Nous avons une même probabilité 1/m de recherche pour chacune des m données composant la liste obtenue via la table de hachage. Succès : Sous l hypothèse énoncée, la recherche avec succès dans une liste non triée demande de l ordre de m/2 comparaisons de données en moyenne. Preuve. Supposons que la donnée recherchée soit la i ème dans la liste. Nous avons besoin de faire i comparaisons pour la trouver. En moyenne, le nombre de comparaisons vaut : 1 m m i=1 i = 1 m(m + 1) m 2 m 2 Echec : Sous l hypothèse énoncée, la recherche avec échec dans une liste non triée demande de l ordre de m comparaisons de données en moyenne. Il faut alors effectuer la comparaison avec toutes les données de la liste. Le pire des cas : La fonction de hachage envoie les n données dans la même liste chainée. Dans ce cas, notre liste sera de taille n. Si la donnée recherchée est en dernière position de cette liste, alors l opération de recherche se fera en O(1) + O(n) = O(n). 38

44 L insertion d une nouvelle séquence dans la table de hachage, revient à rechercher celle-ci dans la liste chainée et à l ajouter à la fin si elle n y est pas présente. Nous pouvons donc se baser sur les complexités ci-dessus et additionner un temps constant (O(1)) pour l opération d ajout. De ce fait, les complexités sont identiques. Enfin, pour effectuer l action d identification d une empreinte, nous utilisons un simple tableau où chaque position fait référence à une piste audio. La première chanson ajoutée à la table de hachage est par exemple liée à la position 0 du tableau d identification. Lors de la recherche d une empreinte, les identifiants de chansons où une séquence est trouvée, se voient incrémentés de 1. A la fin du processus, il suffit de récupérer l id du tableau contenant la valeur la plus élevée. Remarque Dans notre prototype, nous ne tenons pas compte pour l instant de l ordre de traitement des séquences. Par là, nous voulons dire que leur ordre d apparition dans le temps ne joue aucun rôle dans ce cas ci. Nous nous contentons simplement de vérifier leur présence dans la table. Le facteur temps pourra éventuellement être intégré dans le futur mais il risque de compliquer l opération de recherche. En effet, il faudra dans un premier temps, identifier dans le morceau original le moment où la sous-empreinte recherchée commence. Ce qui s avère être de plus en plus compliqué si l extrait audio est de faible qualité. Enfin, il faudra vérifier les séquences les unes à la suite des autres. 39

45 3.5.3 Résultats obtenus avec le prototype Dans cette sous-section, nous abordons les principaux résultats obtenus grâce au prototype de recherche d empreintes que nous avons développé. Pour ce faire, nous allons utiliser l échantillon initial composé de 100 chansons sur lesquels nous avons appliqué l ensemble des perturbations présentées en Sous-Section Pour chaque fichier audio perturbé, nous avons généré des sousempreintes de différentes tailles afin d effectuer nos tests. Les sous-empreintes peuvent ainsi avoir une taille de 1, 5, 10, 25, 50, 100, 250, 500, 1000, 2000 et 3000 séquences de 32 bits. Tous ces éléments permettent d avoir un échantillon de test complet et diversifié. Des résultats ainsi que des graphiques supplémentaires sont disponibles en Annexe D. Les différents types de tests : Déterminer le pourcentage de sous-empreintes correctement identifiées en fonction de la taille de celles-ci et de la perturbation appliquée. Etablir la qualité de la correspondance, si celle-ci existe, pour les sous-empreintes identifiées. Il s agit de déterminer le pourcentage de séquences de 32 bits composant la sousempreinte et qui sont présents à la fois dans celle-ci et dans le morceau original. Montrer que lorsqu une correspondance est trouvée dans la base de données, celle-ci est clairement identifiée par l algorithme. Pourcentage d identification en fonction de la taille et de la perturbation : Pour débuter nos tests, nous allons déterminer la capacité de notre prototype à identifier correctement les différentes sous-empreintes qu un utilisateur pourrait fournir. Dans cette optique, nous avons généré 100 sous-empreintes pour chaque taille citée ci-dessus et pour chaque perturbation énoncée dans la Sous-Section Sur les résultats obtenus après avoir testé ces différentes séries de 100 sous-empreintes, nous avons appliqué un nouvel algorithme : Matching.java. Ce dernier a été développé afin de vérifier la validité d une correspondance. En effet, en présence de sous-empreintes de petite taille, il se peut que l algorithme n identifie aucune chanson ou pire, que celui-ci identifie la sous-empreinte comme appartenant à une autre chanson que la chanson originale à laquelle elle est supposée appartenir. Nous pouvons dès lors mettre en évidence les principes de vrai positif et de faux positif. Ces deux concepts sont développés dans la suite de nos analyses et nous tenterons d évaluer l importance de ces deux phénomènes. Tout d abord, analysons les résultats qui sont représentés graphiquement dans la Figure Il apparaît clairement, pour des sous-empreintes dont la taille est de 1 à 5 séquences de 32 bits, que les performances du prototype ne sont pas élevées. En effet, nous voyons que le pourcentage de sous-empreintes correctement identifiées varie entre 0 et 30% selon la dégradation appliquée. Ces pourcentages signifient qu au mieux, moins d une chanson sur 3 est correctement identifiée. 40

46 Bien que ces résultats puissent sembler faibles à première vue, ils sont toutefois logiques. En effet, si l on se souvient que 256 séquences de 32 bits correspondent à un extrait audio d environ 3 secondes alors nous avons pour 5 séquences : 1 séquence = seconde 5 séquences = seconde Avec des extraits de si courte durée, il est facilement concevable que l algorithme puisse ne pas fonctionner ou se tromper. FIGURE 3.21 Pourcentage de sous-empreintes identifiées en fonction de la taille de celles-ci et de la perturbation appliquée. Ensuite, nous observons que la performance du prototype augmente significativement dès que nous doublons la taille de la sous-empreinte à 10 séquences (0.116 seconde). Désormais, dans le meilleur des cas 9 chansons sur 10 seront correctement identifiées et dans le pire des cas environ 1 chanson sur 2. A partir de là, nous pouvons dégager un premier classement sur la qualité des sous-empreintes en fonction de la perturbation appliquée kbps 2. Bandpass 3. Bass and Treble 4. 64kbps 5. 32kbps 41

47 Enfin, il faut utiliser des sous-empreintes d une taille de 250 séquences ( 3 secondes) afin d obtenir pour la première fois un taux de correspondance de 100%. Il s agit des sous-empreintes sur lesquelles nous avons modifié le bit rate à 128 kbps. Cela confirme le fait qu elles sont les empreintes ayant subit la plus faible dégradation. Cependant, il est nécessaire d utiliser une taille de 500 séquences pour voir successivement les empreintes dont nous avons modifié le Bandpass, le bit rate à 64kbps et ensuite à 32kbps atteindre également une correspondance de 100%. Le Bass and Treble atteindra ce taux grâce à des empreintes de 2000 séquences. Afin de valider les résultats obtenus grâce au prototype, nous avons triplé les échantillons de sous-empreintes dont la taille est de 250, 500, 1000, 2000 et 3000 séquences. L objectif est de vérifier que les taux de correspondance mis en évidence à l étape précédente restent identiques indépendamment du nombre de sous-empreintes fournies. En analysant les résultats donnés par la Figure 3.22, nous arrivons aux mêmes constatations que ci-dessus. En conclusion, nous pouvons émettre l hypothèse qu un échantillon de musique d une durée de 1.5 à 3 secondes (500 à 1000 séquences) est suffisamment long pour être identifié, dans la majorité des cas, de façon correcte par le prototype. FIGURE 3.22 Pourcentage des 300 sous-empreintes identifiées en fonction de la taille de celles-ci et de la perturbation appliquée. 42

48 Vrai positif - Faux positif : Au début de cette sous-section, nous avons émis le fait que notre prototype pouvait, dans certain cas, se tromper. Cela se produit lorsque les sous-empreintes sont de très petite taille. De là, nous avons énoncé les concepts de vrai positif et de faux positif. Nous définissons respectivement ces deux éléments en et et évaluons leur importance dans l utilisation de notre prototype. Définition Dans un test de classification binaire, un résultat est considéré comme étant vrai positif lorsqu un élément est correctement identifié par le test. Dans notre cas, il s agit d une sous-empreinte correctement identifiée par le prototype. Définition Dans un test de classification binaire, un résultat est considéré comme étant faux positif lorsqu un élément est identifié par le test comme étant correct alors qu en réalité il ne l est pas. Dans notre cas, il s agit d une sous-empreinte pour laquelle le prototype trouve une correspondance mais celle-ci est différente de la chanson originale à laquelle la sous-empreinte est supposée appartenir. En se basant sur le même échantillon que précédemment, nous évaluons ces deux éléments. Il n est pas nécessaire de recommencer le processus afin de connaître la valeur des vrais positifs car ceux-ci ont déjà été calculés pour la Figure Il nous suffit donc d utiliser à nouveau l algorithme Matching.java pour déterminer les faux positifs. La Table 3.5 montre les résultats obtenus pour toutes les séries de sous-empreintes. Taille sous-empreinte 128Kbps 64Kbps 32Kbps Bandpass Bass-Treble VP FP VP FP VP FP VP FP VP FP TABLE 3.5 Tableau contenant les valeurs des vrais positifs et des faux positifs obtenus par le prototype sur les différentes séries de sous-empreintes En conclusion, comme énoncé ci-dessus, nous voyons que le prototype se trompe pour des sous-empreintes de petite taille et particulièrement lorsque celles-ci sont composées de 10 à 100 séquences. Ce phénomène peut s expliquer par le fait que le prototype est en possession de suffisamment de séquences pour qu une ou plusieurs de celles-ci se retrouvent, par hasard, dans une autre chanson mais pas assez pour identifier l extrait auquel la sous-empreinte appartient réellement. Il est en effet possible que la perturbation appliquée ait modifié l ensemble des séquences composant la sous-empreinte. Nous observons également que le taux de faux positifs est plus élevé selon l importance de la dégradation appliquée. Pour finir, il est à noter que les résultats obtenus dans la Table 3.5, confirment les conclusions que nous avions mis en évidence à l étape précédente. 43

49 Etablir la qualité de la correspondance : Un second test que nous effectuons afin d évaluer la performance de notre prototype, consiste à établir la qualité de la correspondance dans le cas où cette dernière existe. Nous entendons par la, de déterminer le pourcentage de séquences de 32 bits composant la sous-empreinte et qui sont présents à la fois dans celle-ci et dans le morceau original. Pour ce faire, nous nous basons une nouvelle fois sur l échantillon de 100 sous-empreintes utilisé pour les tests précédents. Les résultats que nous obtenons sont représentés graphiquement dans la Figure Premièrement, il est facile de voir que plus la taille de la sous-empreinte augmente, plus la qualité de la correspondance diminue. Ainsi, pour une sous-empreinte constituée d une seule séquence, si une correspondance est trouvée, alors elle sera logiquement de 100%. Pour 5 séquences, la qualité diminue de manière brutale et avoisine les 30 à 60% suivant la perturbation appliquée. Cette diminution de la qualité va se poursuivre lentement et se stabiliser lorsque la sous-empreinte approche d une taille de 100 séquences. Pour des tailles supérieures à 100 séquences, il ne semble plus y avoir de perte de qualité. On pourrait penser que ces valeurs sont faibles mais nous verrons dans le test suivant qu elles sont suffisantes. A ce stade, d un côté nous pouvons conclure que la taille de la sous-empreinte n influence pas la qualité de la correspondance. De l autre, que la qualité de la correspondance est liée à la qualité des sous-empreintes. FIGURE 3.23 Pourcentage de séquences de 32 bits composant la sous-empreinte et qui sont identifiées dans le morceau original. 44

50 Lorsqu une correspondance est trouvée, elle est clairement identifiée : Avant de clôturer cette sous-section réservée au prototype que nous avons développé, nous désirons effectuer un dernier test. Il s agit de montrer que lorsque notre prototype identifie correctement un extrait sonore, celui-ci le fait de manière à ce qu il ne puisse y avoir de discussion sur les résultats. La Figure 3.24 représente le top 3 des correspondances identifiées par le prototype pour chacune des 100 sous-empreintes. Dans ce cas, il s agit des sous-empreintes dont nous avons modifié le bit rate à 128kbps et dont la taille est de 1000 séquences. Grâce aux tests que nous avons effectués précédemment, nous savons que cette série de sous-empreintes possède un pourcentage d identification de 100%. Cependant, la qualité des correspondances est en moyenne de 40%. Cette valeur peut paraître faible mais au vue des résultats de la Figure 3.24, elle est clairement suffisante. En effet, la qualité de la deuxième ainsi que de la troisième correspondance dépassent rarement 1%. L origine de ces valeurs vient du fait qu un faible nombre de séquences peuvent se retrouver par hasard dans une autre chanson que la chanson originale. Afin de confirmer nos propos, d autres exemples sont disponibles en Annexe D. FIGURE 3.24 La qualité des 3 meilleures correspondances pour une sous-empreinte donnée dont le bit rate est de 128kbps et la taille de 1000 séquences La Figure 3.25 illustre les résultats précédents sous une forme textuelle. Les deux types de résultats sont générés simultanément par le prototype. La figure ci-dessous montre les résultats obtenus pour 3 sous-empreintes sélectionnées au hasard parmi les 100 disponibles. 45

51 FIGURE 3.25 Résultats sous une forme "textuelle" du test précédent pour 3 sous-empreintes sélectionnées au hasard 46

52 Chapitre 4 Présentation de l application Ce chapitre est principalement consacré à l application que nous avons développée sous Android. Le but de celle-ci est de permettre une utilisation de MediaCycle à partir des nouveaux terminaux mobiles. La première partie de ce chapitre a pour objectif d introduire les différents éléments nécessaires au fonctionnement de l application. Ainsi, la Section 4.1 permet d introduire Android. Le protocole REST ainsi que la base de données que nous utilisons sur le dispositif mobile sont détaillés respectivement dans les Sections 4.2 et 4.3. La Section 4.4 expose le premier élément nécessaire au processus de traitement d un extrait audio, le serveur. La base de données employée est décrite dans la Section 4.5. Les logiciels MediaCycle et AudioCycle qui constituent les derniers éléments du processus de traitement sont exposés dans la Section 4.6. Enfin, nous clôturons ce chapitre en présentant, dans la section 4.7, les différents modules que nous avons développés lors de la mise en place de l application. Nous y expliquons l utilité de chaque module ainsi que son fonctionnement. 4.1 Android Android est un système d exploitation open source développé par Google pour les technologies mobiles. Il a été annoncé officiellement le 5 novembre 2007 et a vu son utilisation augmenter considérablement ces derniers mois. D après Mark Murphy dans son livre "Beginning Android 2" [25], le but d Android est d offrir un support dans lequel une partie du travail a déjà été réalisée, ceci afin de faciliter la vie des développeurs : Android se base sur Java et inclut un ensemble de librairies qui fournissent la plupart des fonctionnalités déjà présentes dans le langage Java. Par la même occasion, il offre un support pour les outils de développement disponibles tel que Eclipse. Chaque application Android s exécute au sein de son propre processus. De cette manière, aucun programme présent sur l appareil mobile ne va interférer avec les autres programmes installés. 47

53 Les concepts pour développer des applications sous Android sont similaires à ceux nécessaires pour la réalisation d applications de bureau. Les composants principaux sont : Les activités : il s agit d un composant de l application qui fournit une interface avec laquelle l utilisateur peut interagir dans le but d effectuer une action. Une application est généralement constituée d un ensemble d activités. Le gestionnaire de contenu : il fournit un niveau d abstraction pour gérer les données stockées sur le dispositif et qui sont accessibles par plusieurs applications. Les services : ils correspondent aux processus qui continuent de s exécuter en arrière plan tant que cela est nécessaire et indépendamment de toute activité. Ils ne fournissent pas d interface utilisateur. Les intents : il s agit des messages système circulant à l intérieur du dispositif. Ils servent à notifier les applications de l apparition d un évènement. Par exemple : changement d état du hardware, entrée de données,... L intérêt majeur d Android est qu il offre directement un ensemble de fonctionnalités qui facilitent le développement d applications en tout genre. Les développeurs de Google ont particulièrement concentré leurs efforts sur cinq domaines : le stockage, le réseau, les multimédias, les services téléphoniques et pour finir, une structure pour la gestion GPS. Nous expliquons ci-dessous ces cinq domaines qui sont la base d Android : Le stockage : Android offre un ensemble de méthodes pour la gestion de base de données au sein d une application. Il est également possible d utiliser des espaces de stockages externes tel que des cartes SD. Le réseau : Les dispositifs Android sont généralement "connectés". Nous pouvons gérer les réseaux au niveau que l on souhaite, du plus bas (socket) au plus élevé. Les multimédias : Android possède des librairies intégrant toutes les méthodes nécessaires pour gérer l ensemble des éléments multimédias présents sur un appareil. Il peut s agir entre autre de la caméra ou des éléments audio. Les services téléphoniques : Vu que la plupart des dispositifs Android sont des téléphones, les fonctionnalités de Short Message Service (SMS), d appel ou toutes autres fonctions d un téléphone moderne sont présentes. Le GPS : Aujourd hui, les GSM sont souvent utilisés comme des GPS. Les appareils d Android intègrent ces particularités et tirent également profit des systèmes de géolocalisation et de Google Map. La Figure 4.1 illustre les différentes couches qui composent le langage Android en partant du noyau Linux jusqu à la couche la plus élevée à partir de laquelle nous obtenons les applications. 48

54 FIGURE 4.1 Les différentes couches qui composent Android [6] 4.2 Protocole REST Dans cette Section, nous présentons le protocole REST. Nous employons celui-ci dans notre application lors de l envoi de données entre le dispositif Android et le serveur. Nous expliquons tout d abord en quoi il consiste, son architecture, ses composants et les alternatives qui existent. Ensuite, nous mettons l accent sur les avantages ainsi que sur les inconvénients d utiliser ces principes pour bâtir une application. Les principales sources d informations sur lesquelles nous nous appuyons dans cette section sont la thèse de Roy Fielding [16] et l article écrit par Jean-Paul Figer [17] REST REST est l acronyme de REpresentational State Transfert qui a été introduit en l an 2000 par Roy Fielding dans sa thèse : "Architectural Styles and the Design of Network-based Software Architectures". REST représente un style d architecture, une manière de construire des applications distribuées. Il ne s agit en aucun cas d un standard. Dans ce type d architecture, on dit qu un composant lit ou modifie une ressource en utilisant une représentation de celle-ci. Dans la phrase précédente, trois mots sont importants : ressource, représentation et composant. La ressource constitue un élément qui peut évoluer avec le temps. Une représentation est une séquence d octets parfois accompagnée de métadonnées. Le composant représente "l acteur", il est lié à d autres composants, ce qui permet des interactions. Bien que REST ne soit pas un standard, il repose sur quelques principes "standardisés" simples : 49

55 Une URI est utilisée comme syntaxe afin d adresser les ressources. Celle-ci sera expliquée dans la suite. Il utilise le protocole HTTP et les opérations que celui-ci supporte, GET, POST, PUT,... Il se base sur de l HTML ou de l XML pour créer des documents contenant des liens hypermédias. On emploie également les MIME types pour représenter les ressources. Remarque REST définit une architecture globale pour un système et non une façon de la réaliser en détails. Des architectures REST peuvent donc être réalisées quelque soit le langage choisi (Java,.NET, Android,...). Une particularité de REST est qu il provoque une séparation entre l état du client et le serveur. Les données sont toutes maintenues chez le client et le serveur se contente uniquement de traiter les requêtes. Avec son protocole REST, Roy Fielding propose une alternative, censée être plus simple à mettre en oeuvre, au style architectural RPC (Remote Procedure Call) dont nous pouvons citer SOAP ou XML-RPC. Les applications qui suivent les principes énoncés par Fielding sont appelés RESTful. Une alternative à SOAP et XML-RPC Nous présentons REST comme l alternative aux deux protocoles RPC les plus utilisés, à savoir SOAP et XML-RPC. Nous définissons en quoi consistent ces deux protocoles. SOAP [9] est un style d architecture RPC orienté objet qui est développé sur l XML. Il est utilisé pour transmettre des messages entre des objets distants. Un objet peut donc invoquer les méthodes d autres objets situés sur des entités, ordinateurs ou serveurs différents. Contrairement au protocole REST qui se base uniquement sur les méthodes proposées par HTTP, SOAP ajoute une couche d abstraction supplémentaire pour encapsuler les données. Cette pratique scinde un élément SOAP en deux parties : l enveloppe et le modèle de données. La première contient des informations sur le message lui même tandis que la seconde définit le format du message. Bien que l on accorde à SOAP les qualités d être extensible et indépendant du langage et de la plateforme, on lui reproche très fortement sa complexité d utilisation. La deuxième alternative est XML-RPC [47]. Tout comme SOAP, il permet à des logiciels s exécutant dans des environnements différents de faire des appels de méthodes au travers du réseau. Il se sert de HTTP pour le transport des données et de XML pour l encodage. XML-RPC a été développé de manière à être le plus simple possible et souffre de ce fait d un manque de complétude. URI, ressource et représentation Internet est un espace d informations constitué d éléments, de ressources, qui sont désignés par des identificateurs globaux appelés URI (Uniform Resource Identifier). Une URI se décompose 50

56 en deux parties nommées URL (Uniform Resource Locator) et URN (Uniform Resource Name). Si nous prenons l URI de la Figure 4.2, l URL correspond à et l URN à weather/local/frxx0076. FIGURE 4.2 Interaction entre URI, représentation et ressource [17] L URI est le point central de l architecture Web. Grâce à elle nous pouvons accéder en un "simple clic" à une multitude de protocoles et de représentations. La portée globale des URI entraîne donc un effet de réseau global. Les URI ne se limitent pas au protocole HTTP. Elles peuvent par exemple être de la forme : mailto:individu@adresse.org ftp://ftp.futurenet.co.uk/pub/dailyradar/ Lorsque nous cliquons sur notre URI de départ, le navigateur interprète cette action comme le fait de vouloir obtenir une représentation de la ressource désignée. Il identifie le protocole HTTP et envoie au serveur une requête GET. Ce dernier envoie alors en retour une représentation en deux parties de la ressource. La donnée elle-même et les métadonnées qui lui sont associées. Comme nous pouvons le voir dans la Figure 4.2, les métadonnées sont constituées d un élément Content-Type ou MIME Type. Ce dernier est très important car il est utilisé par le navigateur pour déterminer le type du fichier et donc l action à accomplir avec celui-ci. HTTP, GET et POST Le deuxième élément qui compose une architecture REST est le protocole HTTP associé à ses deux méthodes principales : GET et POST. Il s agit de deux manières de transmettre des informations, soit via un formulaire, soit en utilisant l URI. La Figure 4.3 montre le fonctionnement de ces deux méthodes. Bien que celles-ci aient la même fonction de base, on conseille d utiliser GET lorsque l état de la ressource ne doit pas être modifié. On dit que l utilisation de GET est safe et il est donc utilisé pour simplement accéder aux ressources. En revanche, la commande POST est utilisée lorsque l état de la ressource est modifié ou que l utilisateur est responsable du résultat de l interaction. 51

57 FIGURE 4.3 Schéma du fonctionnement de HTTP [17] D autres commandes complètent les protocoles HTTP mais elles sont moins souvent utilisées. Il s agit par exemple des méthodes PUT et DELETE qui permettent de créer ou de supprimer une ressource. Nous pouvons encore citer HEAD qui agit comme un GET mais uniquement sur les métadonnées de la ressource Avantages et inconvénients de REST L utilisation de REST a des avantages et des inconvénients. En se basant une nouvelle fois sur la thèse de Roy Fielding nous allons tenter de les mettre en évidence dans cette sous-section : Les avantages de l utilisation de REST sont : Une application plus facile à entretenir et mieux structurée. Une utilisation du protocole HTTP avec les opérations, l enveloppe et les en-têtes de ce dernier, contrairement à SOAP qui ajoute un couche d abstraction supplémentaire à HTTP. L absence de gestion d état du client côté serveur permet une réduction de la consommation mémoire au niveau de celui-ci. Un grand nombre de requêtes peuvent être traitées simultanément. L absence de gestion d état du client offre la possibilité de répartir les requêtes sur plusieurs serveurs. Les vitesses de traitement sont accrues et nous avons une meilleure tolérance aux pannes. L inconvénient de REST est qu il impose au client l obligation de conserver localement l entièreté des données nécessaires pour effectuer une requête. Cela implique une plus grande consommation de la bande passante du réseau. Dans le cas concret de notre application, le serveur ne maintient aucune information sur le client qui effectue les processus de traitement de données. De plus, l entièreté des informations (les extraits sonores) dont celui-ci a besoin pour réaliser sa requête, doivent être disponibles sur le dispositif mobile. Les résultats obtenus après un processus de traitement seront à leur tour stockés sur ce dernier afin d être conservés. 52

58 4.3 Base de données SQLite Afin de stocker, sur le dispositif mobile, les résultats d une requête de traitement ainsi que les informations associées aux données sonores, nous allons utiliser une base de données SQLite. Nous allons donc parler maintenant des caractéristiques de SQLite et de son utilisation dans Android SQLite pour Android SQLite [33] est un système de base de données transactionnelle autonome et ne nécessitant aucune configuration initiale. Il fait partie du domaine public et peut donc être utilisé à des fins commerciales ou privées. Aujourd hui, nous retrouvons son utilisation dans de nombreux grands projets comme Mozilla ou encore Python. Contrairement aux autres base de données SQL, SQLite lit et écrit directement les informations dans des fichiers disque ordinaires. Nous pouvons faire contenir une base de données SQL avec plusieurs tables, indices et vues dans un seul de ces fichiers. Enfin, il s agit d une librairie très compacte et sous certaines configurations, SQLite peut s exécuter avec des capacités mémoire minimes. Cette caractéristique en fait une base de données très populaire pour les dispositifs ayant des contraintes comme les téléphones portables, PDAs et lecteurs MP3. Le concept fondamental de SQLite repose sur un compromis entre l utilisation mémoire et la vitesse de réponse. En ce qui concerne Android, SQLite est directement intégré dans les librairies de base comme nous pouvons le voir dans la Figure 4.1. De ce fait, toutes les applications Android peuvent créer librement des bases de données SQL si c est nécessaire. 4.4 Serveur Apache Le premier des trois éléments nécessaires pour faire fonctionner l application Android, notamment le processus de traitement d une donnée audio, est le serveur Apache. Ce serveur permet d interagir avec MediaCycle et la base de données qui contient les différents extraits sonores à traiter. L entièreté de ce processus est détaillé dans la Section 4.7. Avant toute chose, nous définissons en ce qu est un serveur. Définition Un serveur est un ordinateur qui exécute des opérations à la demande d autres ordinateurs ou dispositifs mobiles, surnommés clients. De ce fait, nous parlons d architecture réseau client-serveur. Un serveur HTTP fournit des informations pour répondre aux requêtes d un client. [18] Apache La partie centrale dans la mise en place d un serveur correspond à l installation d Apache et sa configuration. C est Apache qui se charge de coordonner les différents éléments que nous employons pour que tout le processus fonctionne. Apache a été conçu pour prendre en charge de nombreux modules lui donnant des fonctionnalités supplémentaires telles que : interprétation du langage Perl, PHP, Python et Ruby, serveur proxy, Common Gateway Interface, Server Side Includes, réécriture d URL, négociation de contenu, protocoles de communication additionnels,... 53

59 4.5 Base de données du serveur et de MediaCycle Nous présentons dans cette section, la base de données que le serveur Apache et MediaCycle se partagent pendant le processus de traitement d un extrait sonore. Nous détaillons ici les différents champs qui la composent. Notre base de données SQL est composée d une table avec 7 champs qui sont l identifiant, le chemin, le nom, le tag, une latitude-longitude et enfin la taille de l extrait sonore (voir Figure 4.4). Le serveur va insérer les données dans celle-ci, MediaCycle les récupérera pour les traiter et enfin, elles seront extraites et renvoyées à l utilisateur grâce à Apache. 1. ID (INT) : Un identifiant unique est associé à chaque élément qui est inséré dans la base de données. Cet identifiant permet de rechercher les contenus similaires identifiés après le traitement de MediaCycle. 2. Path (TEXT) : La donnée physique n est pas stockée dans la base de données mais sur le disque dur du serveur. Le champ path contient donc le chemin où cette donnée est localisée. MediaCycle utilise ce chemin pour charger et traiter l extrait sonore. 3. Name (TEXT) : Le champ name correspond au titre de la chanson. Il peut servir de filtre lors de certaines recherches. 4. Tag (TEXT) : Le tag peut soit être des informations sur le rythme, soit le genre ou encore le nom de l interprète d une chanson. Ce champ aura un intérêt important dans le filtrage des informations pour les recherches de contenus similaires. 5. Latitude-Longitude (INT) : Comme énoncé dans la Sous-Section 4.7.4, nous pouvons nous baser sur la géolocalisation pour taguer des éléments sonores. Dans des cas particuliers, comme l Exemple du festival, ces données peuvent servir de filtre très puissant pour rechercher des informations contenues dans la base de données. 6. Size (BIGINT) : Le champ size nous permet de stocker la taille de l extrait sonore à traiter. FIGURE 4.4 Structure de la base de données 54

60 4.6 MediaCycle-AudioCycle Le dernier élément nécessaire au processus de traitement d un extrait sonore est le logiciel MediaCycle. Pour rédiger cette partie, nous nous basons sur les rapports scientifiques [32] et [13] publiés par le laboratoire de Théorie des Circuits et Traitement du Signal. Nous commençons par introduire les logiciels MediaCycle et AudioCycle. Enfin, nous clôturons cette section en parlant des différentes interprétations visuelles MediaCycle Comme nous l avons déjà énoncé dans la Section 2.4, MediaCycle est un logiciel qui permet d analyser des données multimédias (son, images, vidéo,...). Il a été développé par le laboratoire TCTS depuis l année Initialement, les recherches dans une base de données s effectuaient sur les métadonnées des médias composant celle-ci. Il pouvait par exemple s agir d une légende ou d un ensemble de motsclés. Cette approche souffrait de deux inconvénients majeurs : 1. Le tagging : ce procédé est fastidieux et ne trouve donc un intérêt que pour les petites bases de données. 2. La signification : cette façon de faire ne représente pas forcément la signification réelle du média. De plus cela peut varier suivant les personnes. Récemment, de nombreux logiciels sont passés d une approche basée sur les métadonnées à une approche basée sur le contenu. Dans ces deux types d approches, les recherches s effectuent suivant des requêtes. Le projet MediaCycle vise quant à lui à développer un nouvel environnement de navigation qui offre une alternative à la recherche par requête. Pour ce faire, l architecture de la base de données est telle qu un utilisateur pourra facilement récupérer les données qu il désire. Dans le domaine de l audio, l outil développé par le laboratoire TCTS et qui reprend le même principe que MediaCycle porte le nom d AudioCycle AudioCycle AudioCycle fournit aux utilisateurs un affichage graphique, dans lequel les données audio extraites sont vues et organisées suivant leurs similarités en terme de propriétés musicales. Il s agit par exemple du timbre, de l harmonie et du rythme. L utilisateur peut naviguer au travers de cette représentation visuelle, écouter chaque morceau audio et rechercher de nouvelles pistes qui l intéressent. Le logiciel a été conçu à partir de différentes technologies telles que l analyse audio grâce à des informations musicales, de la visualisation 3D, de l interprétation d audio dans l espace,... L approche proposée a pour but d étendre les navigateurs musicaux et audio présentés précédemment. Les concepts développés ici trouvent un intérêt pour les DJs, les mixeurs, les musiciens, les compositeurs et les ingénieurs du son. En effet, de nos jours, la production de musique repose de 55

61 plus en plus sur des morceaux audio pré-enregistrés et organisés en différentes librairies. Cependant, les outils disponibles pour naviguer au travers de ces librairies entravent le processus créatif. Avec ceux-ci, les pistes audio sont recherchées dans une hiérarchie rigide de fichiers, ou en utilisant des descripteurs symboliques stockés en tant que métadonnées. De façon plus générale, avec l augmentation du nombre de contenus multimédias, la demande en logiciels flexibles et efficaces pour visualiser et rechercher ces données est importante. Les opérations d indexation et de recherche peuvent s appuyer d une part sur des technologies automatiques de description de contenu, et d autre part, sur la formulation de requêtes. Une architecture adaptée pour la base de données contenant les médias est également nécessaire afin que l utilisateur puisse voyager dans celle-ci. AudioCycle présente donc un moyen pratique et rapide pour explorer et extraire de la musique de grandes librairies. Il se base sur des analyses de similarités et des caractéristiques musicales pertinentes incluant le rythme, l harmonie et le timbre. L architecture du logiciel peut être observée dans la Figure 4.5. FIGURE 4.5 Architecture d AudioCycle [13] Visualisation La représentation de larges bases de données multimédias a été sujette à de nombreuses recherches scientifiques. Une visualisation de ces bases de données doit satisfaire trois critères : L overview : une représentation fidèle de la distribution des morceaux composant la collection. Préservation de la structure : les relations entre les extraits musicaux doivent être préservées dans l espace de projection. La visibilité : une compréhension visuelle du contenu de chaque morceau de musique. 56

62 Lorsque nous désirons afficher la totalité des extraits musicaux, l idée est d associer à un objet x i un vecteur y i visant à traduire la similarité entre x i et ses voisins dans une représentation 2D ou 3D. Pour ce faire, trois approches sont possibles. Réduction dimensionnelle Le but de cette approche est de préserver les distances entre les points se trouvant dans un espace à haute dimension lorsque nous les projetons dans un sous-espace à deux dimensions. Graphes Lorsque nous utilisons des graphes pour la visualisation, chaque morceau de musique est représenté par un sommet dans le graphe. Les arcs entre les extraits adjacents sont quant à eux utilisés pour la navigation. L objectif des graphes est de préserver le voisinage entres les morceaux audio et d améliorer la structure générale des données. Clustering Les clusters peuvent être représentés visuellement comme un schéma en forme de fleur, où le centre représente l extrait sélectionné et les autres sont positionnés dans les clusters situés autour de celui-ci. La Figure 4.6 schématise une représentation des données sous la forme de clusters telle que nous pouvons l observer grâce à AudioCycle. FIGURE 4.6 Représentation des données en clusters [13] 57

63 4.7 Présentation des différents modules de l application Dans cette section, nous présentons les différentes vues qui constituent notre application. Nous démarrons de l étape initiale qui est la capture d un son, jusqu à l étape finale qui correspond à la réception des données par le serveur et MediaCycle. Nous intégrons dans ces sous-sections des captures d écran afin d illustrer nos propos. Pour visualiser une démonstration complète du fonctionnement de l application, nous avons joint une vidéo sur le DVD fournit en annexe du mémoire. Notre application porte le nom de Catch a Sound et elle peut être identifiée dans le menu des dispositifs mobiles par l icône illustré dans la Figure 4.7. FIGURE 4.7 Icône permettant de lancer l application dans le menu du smartphone Interface d accueil La Figure 4.8 correspond à la page d accueil de notre application. Nous pouvons y voir les boutons Record a sound (Sous-Section 4.7.3), List Sound Files (Sous-Section 4.7.5) et Informations (Sous-Section 4.7.2). Ces trois boutons sont les plus importants de l application car c est à partir de ceux-ci que nous pourrons accéder à l ensemble des différents modules. De façon brève, le bouton Record a sound va nous permettre d enregistrer un son. Le bouton List Sound Files propose de visualiser l ensemble des extraits audio présents sur le dispositif et d effectuer sur ceux-ci les différentes actions supportées par l application. Enfin, le bouton Informations contient les données qui sont propres à l application développée. 58

64 FIGURE 4.8 Interface d accueil de notre application Informations de l application Comme nous pouvons le voir dans la Figure 4.9, cette interface contient uniquement les informations sur l application que nous avons développée. Nous pouvons ainsi y apprendre le titre du projet, l objectif de l application, le nom du développeur et enfin l administrateur ou encore la personne à contacter en cas de problème ou de question. Ces données sont parfois utiles pour les utilisateurs et sont accessibles grâce au bouton Informations de l interface d accueil. FIGURE 4.9 Interface contenant les informations liées à l application développée 59

65 4.7.3 Enregistrer un son L objectif principal de notre application est la reconnaissance de morceaux audio. Il semble de ce fait logique que l utilisateur doive commencer par capturer un son, un extrait sonore. La Figure 4.10 représente l interface utilisateur dont celui-ci devra se servir pour effectuer ses enregistrements. Nous pouvons y voir un chronomètre et les boutons Begin/Stop recording, Play/Stop playing recording et Save recording. FIGURE 4.10 Interface pour les sons Le chronomètre a pour seule fonction d informer l utilisateur sur la durée de l extrait que celui-ci capture. Il se déclenche au moment où il appuie sur le bouton Begin recording et s arrête logiquement lorsqu il appuie sur le bouton Stop Recording. Il n y a pas de limite de durée à l enregistrement d un extrait. Nous observons le processus d enregistrement sur la Figure 4.10 (a). Comme nous l avons énoncé dans la Section 4.1, Android offre des librairies très complètes pour gérer les éléments multimédias qui équipent chaque dispositif. De ce fait, pour les opérations d enregistrement et d écoute des sons, nous utilisons celles-ci et plus particulièrement les librairies MediaRecorder et MediaPlayer. MediaRecorder permet d encoder des sons uniquement aux formats 3GPP ou MPEG4. Une fois l enregistrement terminé, l utilisateur a la possibilité de réécouter l extrait grâce aux boutons Play Recording et Stop Playing Recording. Eventuellement, si l extrait convient, il peut le sauvegarder via le bouton Save Recording (Figure 4.10 (b)). Pour ce faire, il suffit de compléter la boîte de dialogue avec le nom du fichier, un tag, choisir entre activer ou non la géolocalisation (Sous-Section 4.7.4) et enfin d appuyer sur "save". Le fichier est alors sauvegardé sur la carte SD intégrée au dispositif mobile et les différentes informations sont insérées dans la base de données mise en place. 60

66 La structure de la base de données SQLite que nous utilisons sur le dispositif mobile est identique à celle employée sur le serveur à un détail près. Comme nous pouvons le voir sur la Figure 4.11, un champ supplémentaire new_data de type INT est utilisé. L intérêt de cette colonne est de pouvoir gérer les données sonores présentes sur le dispositif. Ainsi une donnée enregistrée par l utilisateur aura une valeur de 0. Une donnée reçue par le serveur sera ajoutée à la base de données avec une valeur de 1 et enfin, la donnée en cours de traitement par MediaCycle aura une valeur égale à 2. Nous expliquons l utilité de ces trois valeurs dans les sous-sections suivantes. FIGURE 4.11 Structure de la base de données du dispositif mobile Tagging et géolocalisation Chaque donnée sonore a des métadonnées qui lui sont associées. Parmi celles-ci, un champ particulier est développé ici : le tag. Ce tag sera introduit par l utilisateur et peut représenter une multitude d informations différentes comme le genre, le titre ou l auteur d une chanson. Cependant, dans une plus large mesure, il peut également s agir de coordonnées GPS permettant de faire correspondre un évènement musical à un lieu. Comme par exemple lors d un festival ou d un concert. Nous parlons de géolocalisation. La géolocalisation, comme son nom l indique, consiste à localiser géographiquement son dispositif mobile et, par la même occasion, soi même. Nous savons qu aujourd hui tous les dispositifs possèdent des fonctionnalités de GPS et rendent désormais cette action banale. Pour s en apercevoir, il suffit de regarder le nombre d applications Facebook (Foursquare, Bing,...) qui permettent en temps réel de savoir où vous êtes et avec qui vous êtes. L utilisation de la géolocalisation pour taguer des éléments audio peut paraître étrange, mais elle trouve un intérêt dans certains cas. Nous pouvons nous baser sur le scénario décrit dans l Exemple Exemple L organisateur d un grand festival de musique, désire mettre en place un système de reconnaissance. Chaque participant pourrait via son appareil mobile identifier les musiques qui sont jouées sur les différentes scènes du festival. Dans le cas où il tomberait sur un groupe inconnu, il pourrait ainsi obtenir rapidement le nom et le titre de la chanson. L avantage d utiliser la géolocalisation dans cette situation, découle du fait que nous pourrions effectuer un filtrage important et très précis pour les éléments présents dans la base de données qui nous intéressent. 61

67 4.7.5 Lister les sons Comme nous pouvons le voir dans la Figure 4.8, une deuxième possibilité offerte à l utilisateur permet de lister l ensemble des fichiers audio déjà présents sur la carte mémoire de l appareil. Il s agit des fichiers pour lesquels la valeur de new_data est positionnée à 0. Pour ce faire, nous utilisons une structure de ListView à laquelle nous avons appliqué un filtre de manière à n afficher que les données audio (MP3, WAV, 3GPP,...). Le résultat peut être visualisé dans la Figure 4.12 (a). Pour chaque élément de la liste, deux données sont fournies. La donnée de gauche correspond au nom, au titre de l extrait tandis que la donnée de droite correspond au tag. Lorsque l utilisateur fait défiler la liste des éléments, il peut à tout moment, en appuyant de manière prolongée sur une donnée, faire apparaître un menu d options. Par l intermédiaire de ce menu, l utilisateur peut écouter, supprimer, renommer, retaguer ou traiter le fichier audio. Nous pouvons observer ce menu d options dans la Figure 4.12 (b). FIGURE 4.12 Lister les sons enregistrés L option Listen To File (Ecouter) mène l utilisateur sur un lecteur audio où il peut simplement écouter l extrait sélectionné. Ceci est représenté via la Figure Nous avons développé nous même ce lecteur audio en utilisant la librairie MediaPlayer d Android. En effet, le lecteur Android intégré au dispositif présente trop de restrictions sur l enregistrement, la lecture et le renommage des différents fichiers. L interface de notre lecteur est constitué du titre et du tag de l extrait choisi ainsi que des trois boutons habituels Play, Pause et Stop. Lorsque l utilisateur clique sur Play, le média est joué par le lecteur et une barre de progression indique l état de l avancement. A tout moment, il peut appuyer sur Pause ou Stop afin d arrêter momentanément ou définitivement la lecture. Si l utilisateur clique sur pause alors le bouton Play est masqué et le seul moyen de reprendre la lecture et d appuyer à nouveau sur Pause. La Figure 4.13(b) illustre nos propos. 62

68 FIGURE 4.13 Représentation du lecteur audio L option Delete permet, comme son nom l indique, de supprimer le fichier audio sélectionné. Pour éviter des suppressions accidentelles, une confirmation est automatiquement demandée à l utilisateur. Ces deux vues sont représentées par la Figure FIGURE 4.14 Interface pour la suppression d un extrait sonore 63

69 Les options Rename et Retag permettent respectivement de modifier le nom ou le tag d un fichier présent sur la carte SD du dispositif. Grâce à la Figure 4.15, nous voyons qu il suffit de remplir la boîte de dialogue affichée à l écran avec le nouveau nom ou le nouveau tag. FIGURE 4.15 Interface pour modifier le nom ou le tag d un fichier La dernière option disponible est Process. Celle-ci est entièrement détaillée dans la Sous- Section et consiste au processus de traitement d une donnée audio. FIGURE 4.16 Option pour le traitement d une donnée 64

70 4.7.6 Envoyer des données La phase la plus importante se produit lorsqu un utilisateur souhaite traiter un extrait sonore. Comme nous l avons énoncé dans la Sous-Section par l intermédiaire des Figures 4.12 et 4.16, il lui suffit de sélectionner le fichier qu il désire et d appuyer sur Process. A partir de là, une nouvelle boîte de dialogue apparaît et l utilisateur peut choisir le nombre de chansons similaires qu il désire obtenir en retour (c.f. Figure 4.17). Nous avons pris la décision de limiter la saisie à deux chiffres maximum (de 1 à 99) et dans le cas où l utilisateur n entre aucune valeur, celle-ci est mise par défaut à 1. FIGURE 4.17 L utilisateur peut choisir le nombre de réponses qu il désire Le processus de traitement d un extrait se fait en différentes étapes. Tout d abord, la donnée audio choisie est uploadée sur un serveur Apache grâce à un code implémenté suivant une architecture REST. Cette manière de faire est décrite dans la Section 4.2. Au même moment, la valeur new_data de la donnée est mise à 2. Cela signifie que la donnée est l élément central d un processus de traitement. Une fois la donnée sur le serveur, nous pouvons mettre en évidence cinq opérations successives qui sont représentées dans la Figure 4.18 et le Listing 4.1 : 1. Insertion dans la base de données : une fois l extrait uploadé sur le serveur, un script php permet de l insérer dans une base de données utilisée par MediaCycle. La structure de la base de données est expliquée dans la Section 4.5. L objectif d insérer chaque donnée envoyée sur le serveur vise à récolter un maximum d éléments pour créer une base de données aussi complète que possible. 2. Le serveur informe MediaCycle : lorsque le morceau audio a été inséré dans la base de données, le serveur informe MediaCycle qu il doit traiter un élément en lui fournissant l identifiant de celui-ci dans la base de données. 65

71 3-4. MediaCycle accède à la base de données : après avoir été informé par le serveur, MediaCycle effectue une requête sur la base de données pour récupérer l élément associé à l identifiant qui lui a été fourni. Une fois en possession de cette donnée, le processus de traitement expliqué dans la Section 4.6 peut commencer. 5. MediaCycle retourne ses résultats : la dernière étape consiste à retourner les résultats obtenus par MediaCycle au serveur Apache. Les résultats sont en réalité la liste d identifiants des éléments similaires. A la fin de ces cinq opérations, les données similaires obtenues par le serveur sont uploadées sur le dispositif mobile de l utilisateur. Les données physiques, c est-à-dire les extraits sonores, sont stockées dans un dossier temporaire nommé DownloadedFile présent sur la carte SD de l appareil mobile. Les informations liées à ces données sont quant à elles insérées dans la base de données SQLite avec une valeur new_data égale à 1 (donnée temporaire). Celles-ci serviront dans le cas où l utilisateur effectue une requête similaire pour ne pas recommencer l entièreté du processus. FIGURE 4.18 Processus d envoi de données 66

72 Listing 4.1 Script traitant les données reçues par le serveur 1 <?php 2 require_once c o n f i g. php ; 3 require_once i n c l u d e. php ; 4 5 global $gdb ; 6 7 / / open mysql connexion 8 $gdb = new DatabaseMySql ( ) ; 9 $gdb >connect ( ) ; 10 $gout = new Output ( ) ; 11 $guser = new User ( ) ; $target_path = ". / " ; 14 $target_path = $target_path. basename ( $_FILES [ u p l o a d e d f i l e ] [ name ] ) ; / / Move t h e f i l e 17 i f ( move_uploaded_file ( $_FILES [ u p l o a d e d f i l e ] [ tmp_name ], $target_path ) ) 18 { 19 / / Data r e c e i v e d from Android a p p l i c a t i o n 20 $path = $_FILES [ u p l o a d e d f i l e ] [ name ] ; 21 $longitude = floatval ( $_POST [ l o n g i t u d e ] ) ; 22 $latitude = floatval ( $_POST [ l a t i t u d e ] ) ; 23 $numberofknn = floatval ( $_POST [ knnnumber ] ) ; 24 $title = $_POST [ t a g ] ; 25 $size = floatval ( $_POST [ s i z e ] ) ; / / I f f i l e doesn t e x i s t 28 i f (! $path ) 29 echo "No p a t h p l e a s e t r y a g a i n! " ; 30 e l s e 31 { 32 / / Mediacycle : : l o a d L i b r a r y ( ) ; 33 $nber = $gdb > query ( "SELECT id, c o u n t ( i d ) FROM f i l e s WHERE p a t h = $ p a t h " ) ; 34 $result = mysql_fetch_array ( $nber, MYSQL_NUM ) ; / / I f d a t a i s n t i n t h e d a t a b a s e. We c r e a t e t h e f i l e 37 i f ( $result [ 1 ] == 0) 38 $file = LCFile : : createnewfile ( $title, $path, $type, $size, $recording, $longitude, $latitude ) ; 39 e l s e / / E l s e we l o a d i t 40 $file = new LCFile ( $result [ 0 ] ) ; / / We add t h e f i l e t o MediaCycle f o r p r o c e s s 43 MediaCycle : : addfile ( $file ) ; / / I f i t s a new f i l e we save i t i n MediaCycle 46 i f ( $result [ 1 ] == 0) 47 MediaCycle : : savelibrary ( ) ; / / Knn p r o c e s s t o g e t t h e n e a r e s t sound f i l e s 50 $knn = Mediacycle : : getknn ( $file, $numberofknn ) ; / / Loop over t h e r e s u l t of Knn method 53 f o r ( $i=0;$i<count ( $knn ) ; $i++) 54 { 55 $var = $knn [ $i ] ; 56 $sql= $gdb > query ( "SELECT id, t i t l e, path, s i z e, l o n g i t u d e, l a t i t u d e FROM f i l e s WHERE i d = $ var " ) ; w h i l e ( $row=mysql_fetch_assoc ( $sql ) ) 59 $output [ ] = $row ; 60 } 61 / / Send d a t a t o t h e Android a p p l i c a t i o n 62 print ( json_encode ( $output ) ) ; 63 } 64 } 65 e l s e 66 echo " There was an e r r o r u p l o a d i n g t h e f i l e, p l e a s e t r y a g a i n! " ; 67?> 67

73 L interface à laquelle l utilisateur est confronté durant le processus de traitement est illustrée dans la Figure A tout moment, celui-ci peut observer l état d avancement à la fois de l upload de la donnée ainsi que du download des résultats. Lorsque les résultats sont chargés sur le dispositif, il est possible de les visualiser en appuyant sur le bouton Show Cluster qui devient alors disponible. FIGURE 4.19 Interface utilisateur lors du traitement d une donnée 68

74 4.7.7 Visualiser les clusters Après le processus de traitement, le dernier module offert à l utilisateur lui permet de visualiser les résultats de MediaCycle. Cette représentation a été développée avec l idée de se rapprocher au maximum de celle présente dans le logiciel de base développé par le TCTS. La Figure 4.20 montre les résultats obtenus. Dans le cluster, chaque point rouge correspond à une donnée audio. La donnée sélectionnée se trouve au centre et les éléments similaires autour. En appuyant brièvement sur une de ces données, le titre, le tag et le path sont retournés à l utilisateur (c.f. Figure 4.20(c)). FIGURE 4.20 Affichage des deux résultats obtenus par MediaCycle 69

75 A tout moment, celui-ci peut effectuer une nouvelle requête à partir de cette vue. Pour ce faire, il lui suffit d appuyer longuement sur une des données. Dès lors, le cluster sera mis à jour et la nouvelle donnée sera repositionnée au centre comme nous pouvons le voir dans la Figure De plus, celle-ci est déplacée dans le dossier courant et sa valeur de new_data est mise à 0. Elle sera donc maintenant visible dans la liste des extraits audio présents sur le dispositif mobile. FIGURE 4.21 Résultat d un second traitement Remarque La totalité de l application a été développée et testée à partir de l émulateur intégré à Eclipse. Celui-ci a également été utilisé pour réaliser les différentes captures d écran se trouvant dans ce chapitre. Par la même occasion, il est important de savoir que les tests ont été réalisés grâce à un serveur fonctionnant en local. Sur celui-ci, nous avons installé une version de MediaCycle. 70

76 Chapitre 5 Conclusion Les objectifs de ce mémoire étaient dans un premier temps, l analyse du processus d extraction d empreintes et l étude des algorithmes de recherche et correspondance dans une base de données. Dans un second temps, en se basant sur ce que nous avions étudié précédemment, nous avons implémenté un prototype Java de recherche de sous-empreintes. Enfin, nous avons développé une application Android permettant d utiliser le logiciel MediaCycle sur les dispositifs mobiles. Avant toute chose, nous avons exposé l état de l art afin de bien se situer par rapport aux objectifs énoncés. Nous avons mis en avant les différentes technologies mobiles disponibles sur le marché et sur lesquelles nous comptons nous appuyer afin d utiliser notre application. Nous avons ensuite parlé des divers médias du monde actuel. Nous pouvons citer les données multimédia, hypermédia et les rich média. Nous avons clôturé l état de l art en exposant les apports que ce mémoire pourrait offrir par rapport aux différentes applications (Shazam et Midomi-SoundHound) déjà disponibles et qui effectuent un travail similaire. Par la suite, au niveau théorique, nous avons présenté la notion de fingerprinting. Nous avons introduit le sujet en exposant une définition claire de ce que cela représente ainsi que les concepts qui y sont liés. Nous avons également énoncé les différentes méthodes qui existent afin de représenter visuellement des données sonores. La suite du chapitre est consacrée au processus d extraction d empreinte. Nous avons vu que celui-ci peut se décomposer en quatre étapes principales. Tout d abord, il y a la phase de framing qui consiste à scinder chaque signal audio en blocs superposés de plus petite taille que l on appelle trames. Ensuite, sur chaque trame obtenue, nous appliquons une transformation de Fourier afin d obtenir une représentation spectrale du signal audio. La troisième étape a pour objectif de créer un banc de filtres suivant l échelle de Bark ou l échelle de Mel. De cette troisième phase, nous obtenons une énergie qui sera utilisée lors de la création de l empreinte binaire au cours de la quatrième et dernière étape. A la fin de ce chapitre, nous avons analysé les différentes approches possibles pour la recherche et correspondance d empreintes dans une base de données. Nous avons mis en avant les contraintes liées à un tel système à savoir, le nombre de sous-empreintes à traiter. Toujours avec l objectif de développer un prototype performant, nous avons étudié différentes structures de données comme les tables de lookup ou les tables de hachage. Bien que nous ayons cité les techniques de LSH et de Min-Hash, notre choix s est porté sur une table de hachage classique. En effet, celleci offre des résultats satisfaisants sans augmenter la complexité du prototype. 71

77 La présentation du protocole expérimental et le développement du prototype Java ont permis de conclure ce chapitre. Par l intermédiaire de ce dernier, nous avons ensuite réalisé un ensemble de tests sur des sous-empreintes de différentes tailles (1, 5, 10, 25, 50, 100, 250, 500, 1000, 2000, 3000). Par exemple, nous avons étudié le pourcentage de sous-empreintes correctement identifiées ainsi que la qualité de cette correspondance en fonction de la taille des sous-empreintes. Désormais, nous pouvons affirmer que dans la plupart des cas, une sous-empreinte composée de 500 séquences de 32 bits, c est-à-dire environs 6 secondes, est suffisante pour être identifiée par le prototype. Finalement, nous avons décrit l application Android que nous avons développée. Celle-ci servira à utiliser les fonctionnalités qu offre MediaCycle sur les dispositifs mobiles. Au cours de ce chapitre, nous avons expliqué les différents éléments qui ont un rôle dans l application. Il s agit du protocole REST, du serveur Apache ainsi que la base de données que celui-ci et MediaCycle vont se partager. Nous y expliquons également en détails les logiciels MediaCycle et AudioCycle développés par le laboratoire TCTS. Nous concluons ce rapport, en présentant les différents modules qui composent l application Android. Ainsi, chaque vue présentée est expliquée. Les perspectives liées à ce mémoire sont nombreuses. A l avenir, nous pourrions envisager une amélioration du prototype Java que nous avons développé en intégrant le facteur "temps" à la recherche de séquences. D autres fonctionnalités comme la génération des vrais positifs et des faux positifs pourraient être directement intégrées au prototype. Ajouter la production automatique des différents graphiques serait également une bonne idée. Nous pourrions également tester le prototype sur une base de données composée d un très grand nombre d extraits musicaux. L idée est de pousser le prototype au maximum de son efficacité. Quant à l application Android, des modules supplémentaires peuvent être ajoutés afin de la rendre plus conviviale. De plus, différentes méthodes de recherche complémentaires peuvent être ajoutées de manière à ce que l application soit encore plus complète. Nous pouvons également envisager une commercialisation de l application sur l Android Market afin que celle-ci soit disponible à tout un chacun. 72

78 Bibliographie [1] Dancers project : Interactive video database of professional dancers. URL : (consulté le 30/04/2011). [2] Face on TV. URL : (consulté le 05/05/2011). [3] Finding near duplicates. URL : (consulté le 15/05/2011). [4] Shazam vs Soundhound : which is better? URL : (consulté le 28/04/2011). [5] ABC-NETMARKETING. Définitions des formats rich media. URL : (consulté le 27/04/2011). [6] ANDROID DEVELOPPERS. What is Android? URL : (consulté le 26/05/2011). [7] AVERY LI-CHUN WANG. An Industrial-Strength Audio Search Algorithm. URL : (consulté le 28/04/2011). [8] BOERSMA, P., AND WEENINK, D. Praat : doing phonetics by computer. URL : (consulté le 06/05/2011). [9] BORDERIE, X. SOAP, XML-RPC et REST : différences et intérêts. URL : (consulté le 22/05/2011). [10] CNUCED. Technologie mobile, convergence et outils de création de réseaux sociaux au service du développement et de l éradication de la pauvreté. URL : (consulté le 25/04/2011). [11] COHEN, E., DATAR, M., FUJIWARA, S., GIONIS, A., INDYK, P., MOTWANI, R., ULLMAN, J., AND YANG, C. Finding interesting associations without support pruning. Knowledge and Data Engineering, IEEE Transactions on 13, 1 (2001), [12] CORMEN, T., LEISERSON, C., AND RIVEST, R. Hash tables. In Introduction to Algorithms (03 /1990), M.-H. Companies, Ed., vol. 1, The MIT Press, pp (consulté le 12/05/2011). [13] DUPONT, S., D ALESSANDRO, N., DUBUISSON, T., FRISSON, C., SEBBE, R., AND UR- BAIN, J. Audio cycle. In QPSR of the numediart research program ( ), T. Dutoit and B. Macq, Eds., vol. 1, numediart Research Program on Digital Art Technologies, pp URL : (consulté le 30/04/2011). 73

79 [14] DUPONT, S., DUBUISSON, T., III, J. A. M., MOINET, A., SIEBERT, X., TARDIEU, D., AND URBAIN, J. Laughtercycle. In QPSR of the numediart research program (6 2009), T. Dutoit and B. Macq, Eds., vol. 2, numediart, pp URL : (consulté le 30/04/2011). [15] EMMANUEL, D. Transformation de Fourier. URL : (consulté le 07/08/2011). [16] FIELDING, R. Architectural styles and the design of network-based software architectures. PhD thesis, Citeseer, [17] FIGER, J.-P. REST : un style d architecture universel. URL : (consulté le 22/05/2011). [18] FUTURA-SCIENCES. Dictionnaire : Serveur. URL : (consulté le 31/05/2011). [19] GEDEON, T. Schéma d un document hypermédia. URL : (consulté le 27/04/2011). [20] GIONIS, A., INDYK, P., AND MOTWANI, R. Similarity Search in High Dimensions via Hashing. URL : (consulté le 15/05/2011). [21] HAITSMA, J., AND KALKER, T. A highly robust audio fingerprinting system. In Proc. ISMIR (2002), vol. 2002, Citeseer, pp [22] HARDWARE.FR. Onde sonore. URL : 1.htm (consulté le 07/08/2011). [23] LAMBEEK, A. La technologie mobile, porteuse de changements et d opportunités dans les pays en développement. URL : (consulté le 25/04/2011). [24] MAWSTON, N. Strategy Analytics : Tablets Shipments. URL : (consulté le 26/04/2011). [25] MURPHY, M. Chapitre 1 : The big picture. In Beginning Android 2 (2010), Apress, Ed., vol. 1, pp (consulté le 26/05/2011). [26] MUSICOLOGIE.ORG. Onde sonore. URL : (consulté le 07/08/2011). [27] NORSKOG, L., AND BAGWELL, C. Sound exchange. URL : (consulté le 16/05/2011). [28] ORACLE, S. D. N. Java. URL : (consulté le 17/05/2011). [29] PEETERS, G. A large set of audio features for sound description (similarity and classification) CUIDADO project. URL : cuidadoaudiofeatures.pdf (consulté le 07/05/2011). 74

80 [30] SCHLEIMER, S., WILKERSON, D., AND AIKEN, A. Winnowing : local algorithms for document fingerprinting. In Proceedings of the 2003 ACM SIGMOD international conference on Management of data (2003), ACM, pp [31] SHAZAM. Shazam. URL : (consulté le 28/04/2011). [32] SIEBERT, X., DUPONT, S., FORTEMPS, P., AND TARDIEU, D. Mediacycle : Browsing and performing with sound and image libraries. In QPSR of the numediart research program (3 2009), T. Dutoit and B. Macq, Eds., vol. 2, numediart Research Program on Digital Art Technologies, pp URL : (consulté le 06/05/2011). [33] SQLITE. About SQLite. URL : (consulté le 31/05/2011). [34] TARDIEU, D., CHESSINI, R., DUBOIS, J., DUPONT, S., HIDOT, S., MAZZARINO, B., MOINET, A., SIEBERT, X., VARNI, G., AND VISENTIN, A. Video navigation tool : Application to browsing a database of dancers performances. In QPSR of the numediart research program (9 2009), T. Dutoit and B. Macq, Eds., vol. 2, numediart Research Program on Digital Art Technologies, pp URL : (consulté le 30/04/2011). [35] TECHNO-SCIENCE. Techno-Science : Média. URL : (consulté le 27/04/2011). [36] TECHNO-SCIENCE. Techno-Science : Multimédias. URL : (consulté le 27/04/2011). [37] VAN RIJN, R. Creating Shazam in Java. URL : (consulté le 08/05/2011). [38] WIKIPÉDIA. Définition : Cepstre. URL : (consulté le 08/05/2011). [39] WIKIPÉDIA. Echelle de Mel. URL : (consulté le 08/05/2011). [40] WIKIPÉDIA. Méthode de Ruffini-Horner. URL : (consulté le 27/07/2011). [41] WIKIPÉDIA. Spectrogram. URL : (consulté le 06/05/2011). [42] WIKIPÉDIA. Tablet PC. URL : (consulté le 26/04/2011). [43] WIKIPÉDIA. Téléphone mobile. URL : (consulté le 26/04/2011). [44] WIKIPÉDIA. Transformée de Fourier discrète. URL : (consulté le 08/05/2011). [45] WIKIPÉDIA. Transformée de Fourier rapide. URL : (consulté le 08/05/2011). [46] WIKIPÉDIA. Wikipédia : Hypermédia. URL : (consulté le 27/04/2011). [47] XML-RPC.COM. What is XML-RPC? URL : (consulté le 22/05/2011). 75

81 [48] YAN KE AND DEREK HOIEM AND RAHUL SUKTHANKAR. Computer Vision For Music Identification. URL : (consulté le 04/05/2011). 76

82 Annexe A HashTable et HashList Voici les codes implémentés pour la création de la table de hachage et des listes qui la constitue. Il s agit de la structure décrite dans la Sous-Section Listing A.1 Code de la table de hachage 1 i m p o r t java. io. BufferedReader ; 2 i m p o r t java. io. FileNotFoundException ; 3 i m p o r t java. io. FileReader ; 4 i m p o r t java. io. IOException ; 5 i m p o r t java. util. HashMap ; 6 i m p o r t java. util. Hashtable ; p u b l i c c l a s s FingerprintHashTable 10 { 11 p r i v a t e String filename ; 12 p r i v a t e Hashtable<Integer, HashList> hash ; 13 p r i v a t e String idsong ; 14 p r i v a t e i n t numberfingerprint ; p u b l i c FingerprintHashTable ( String filename ) 17 { 18 t h i s. filename = filename ; 19 numberfingerprint = 0 ; 20 hash = new Hashtable<Integer, HashList>( ) ; 21 } p u b l i c v oid filltable ( ) 24 { 25 t r y 26 { 27 BufferedReader reader = new BufferedReader ( new FileReader ( filename ) ) ; BinaryConverter binconv = new BinaryConverter ( ) ; String line = reader. readline ( ) ; 32 w h i l e ( line!= n u l l ) 33 { 34 i f ( line. startswith ( " # " ) ) 35 { 36 idsong = line ; 37 numberfingerprint++; 38 } 39 e l s e 40 { 41 d ouble value = binconv. convert ( line ) ; i n t indice = t h i s. hashfunction ( value ) ; i f ( hash. get ( indice ) == n u l l ) 46 { 47 HashList hlist = new HashList ( ) ; 77

83 48 hlist. addsubfingerprint ( value, idsong ) ; 49 hash. put ( indice, hlist ) ; 50 } 51 e l s e 52 { 53 HashList hlist = hash. get ( indice ) ; 54 hlist. addsubfingerprint ( value, idsong ) ; 55 hash. put ( indice, hlist ) ; 56 } 57 } line = reader. readline ( ) ; 60 } reader. close ( ) ; } 65 c a t c h ( FileNotFoundException e ) 66 { 67 e. printstacktrace ( ) ; 68 } 69 c a t c h ( IOException e1 ) 70 { 71 e1. printstacktrace ( ) ; 72 } 73 } p u b l i c i n t hashfunction ( d o u b le value ) 76 { 77 i n t val = ( i n t ) value ; 78 i n t position = val / 1000; 79 r e t u r n position ; 80 } p u b l i c Hashtable<Integer, HashList> gethashtable ( ) 83 { 84 r e t u r n hash ; 85 } p u b l i c i n t getnumberfingerprint ( ) 88 { 89 r e t u r n numberfingerprint ; 90 } 91 } Listing A.2 Code des listes chainées contenue dans chaque position de la table de hachage 1 i m p o r t java. util. ArrayList ; 2 i m p o r t java. util. HashMap ; 3 i m p o r t java. util. LinkedList ; p u b l i c c l a s s HashList 7 { 8 p r i v a t e LinkedList<HashMap> list ; 9 p r i v a t e ArrayList<String> songidlist ; 10 p r i v a t e HashMap<Double, ArrayList<String>> hash ; p u b l i c HashList ( ) 13 { 14 list = new LinkedList<HashMap > ( ) ; 15 } p u b l i c void addsubfingerprint ( do ub le value, String idsong ) 18 { 19 i n t pos = t h i s. getpositionsubfingerprint ( value ) ; i f ( pos == 1) 22 { 23 hash = new HashMap<Double, ArrayList<String> >() ; 24 songidlist = new ArrayList<String > ( ) ; 78

84 25 26 songidlist. add ( idsong ) ; hash. put ( value, songidlist ) ; list. add ( hash ) ; 31 } 32 e l s e 33 { 34 hash = gethashmap ( pos ) ; songidlist = hash. get ( value ) ; i f (! songidlist. contains ( idsong ) ) 39 { 40 songidlist. add ( idsong ) ; 41 } hash. put ( value, songidlist ) ; 44 } } p u b l i c HashMap<Double, ArrayList<String>> gethashmap ( i n t position ) 50 { 51 r e t u r n list. get ( position ) ; 52 } p u b l i c LinkedList<HashMap> getlist ( ) 55 { 56 r e t u r n list ; 57 } p u b l i c i n t getlengthlist ( ) 60 { 61 r e t u r n list. size ( ) ; 62 } p u b l i c ArrayList<String> getsongidlist ( do ub le value ) 65 { f o r ( i n t i = 0 ; i < list. size ( ) ; i++) 68 { 69 i f ( list. get ( i ). containskey ( value ) ) 70 { 71 r e t u r n ( ArrayList<String>) list. get ( i ). get ( value ) ; 72 } 73 } r e t u r n n u l l ; 76 } p u b l i c i n t getpositionsubfingerprint ( d o u b l e value ) 79 { 80 f o r ( i n t i = 0 ; i < list. size ( ) ; i++) 81 { 82 i f ( list. get ( i ). containskey ( value ) ) 83 { 84 r e t u r n i ; 85 } 86 } r e t u r n 1; 89 } } 79

85 Annexe B Commandes SoX Dans cette annexe, nous expliquons les différentes commandes que nous utilisons ainsi que les arguments nécessaires à leur fonctionnement. La première perturbation que nous avons appliquée à nos fichiers sonores, consiste à modifier le bit rate des fichiers MP3 grâce aux commandes ci-dessous. Le bit rate correspond aux nombres de bits traités par unité de temps. Un fichier audio MP3@128kbps Commande : sox test.mp3 -C 128 test128kbps.mp3 Un fichier audio MP3@64kbps Commande : sox test.mp3 -C 64 test64kbps.mp3 Un second fichier audio MP3@32kbps Commande : sox test.mp3 -C 32 test32kbps.mp3 Un fichier de type GSM ou la fréquence est MP3@8kbps Commande : sox test.mp3 -C 8 testgsm.mp3 Un fichier audio MP3@2kbps Commande : sox test.mp3 -C 2 test2kbps.mp3 L argument -C permet de modifier le bit rate à la valeur indiquée. Il faut savoir qu une valeur de 8 correspond à 8000Hz. La deuxième perturbation appliquée, consiste à modifier le bass (son grave) et le treble (son aigu). Nous avons ajouté un gain de 20 au bass et une perte similaire au treble. La valeur centrale de la fréquence que le filtre utilisera pour les bass est de 100Hz et dans le cas du treble elle est de 3000Hz. Un fichier dans lequel nous avons modifié de le bass et le treble Commande : sox test.mp3 testbasstreble.mp3 bass treble

86 La dernière perturbation que nous avons appliquée consiste à modifier le bandpass. Un filtre passe-bande est un filtre ne laissant passer qu une bande de fréquences compris entre une fréquence basse et une fréquence haute. Nous utilisons cette commande avec une fréquence centrale de 2500Hz pour le filtre et une longueur de 250. Cette commande a pour effet d appliquer un filtre Butterworth sur les données sonores. Un tel filtre consiste à " lisser" les données comme nous pouvons le voir dans la Figure B.1. Un dernier fichier pour lequel nous avons modifié le bandpass Commande : sox test.mp3 testbandpass.mp3 bandpass FIGURE B.1 Application d un filtre Butterworth sur des données 81

87 Annexe C Utilisation du prototype de recherche d empreintes Dans cette annexe, nous allons expliquer comment utiliser efficacement le prototype que nous avons développé pour la recherche d empreintes. Afin de l exécuter, il suffit simplement d utiliser le fichier Fingerprint_Prototype.jar fourni sur le DVD joint en annexe du mémoire. Aucune librairie supplémentaire n est nécessaire. C.1 Interface d accueil Nous avons développé une interface d accueil pour notre prototype afin que celui-ci soit plus intuitif et plus simple à utiliser. Cette interface, illustrée par la Figure C.1, permet également de rendre l application plus portable. En effet, l utilisateur ne doit pas accéder au code source et modifier lui même les chemins vers les différents fichiers MTF nécessaires. FIGURE C.1 Interface d accueil du prototype de recherche d empreintes 82

88 C.2 Traitement des données Lorsque l utilisateur clique sur Select Data, un Chooser apparaît comme nous pouvons le voir sur la Figure C.2. L utilisateur doit sélectionner le dossier contenant les fichiers MTF originaux. Ces derniers doivent dans un premier temps être traités pour sortir au format binaire comme présenté dans la Section FIGURE C.2 Sélection du dossier contenant les différents fichiers MTF Le dossier MUSIQUE_MEMOIRE_MTF contient différents dossiers où se trouvent les fichiers MTF. Chacun de ces dossiers correspond à une perturbation que nous avons appliquée aux morceaux de musiques originaux. Une fois le dossier choisi, l utilisateur peut désormais cliquer sur le bouton Process Data. Si les données ont déjà été formatées, l utilisateur est averti et il peut décider de recommencer le processus ou de conserver les données existantes. Nous pouvons visualiser cela grâce à la Figure C.3. Pendant cette phase de traitement des données, nous en profitons pour extraire directement 3 types de sous-empreintes pour chaque perturbation. Les 3 types de sous-empreintes diffèrent suivant leur taille respective. Nous extrayons des sous-empreintes de la taille de 1000, 2000 et 3000 séquences. Celles-ci servent par la suite pour effectuer les recherches d empreintes. 83

89 C.3 Recherche d empreintes FIGURE C.3 Traitement des données MTF Une fois les données formatées, l utilisateur peut passer à l étape suivante c est-à-dire, la recherche d empreintes. Dans le cas où il est déjà en possession de données formatées, l étape 1 est facultative. La sélection des données nécessaires à la recherche d empreintes est similaire aux actions de l étape précédente. Comme nous pouvons le voir dans la Figure C.4, il suffit de pointer sur le dossier contenant les fichiers MTF pour lesquels nous désirons effectuer les recherches. FIGURE C.4 Sélection des données pour la recherche d empreinte. Dans ce cas-ci, nous choisissons une série d empreintes dont la taille est de 1000 séquences et dont nous avons modifié le bit rate à 128kbps. 84