1、 Rec. UIT-R BS.1693 1 RECOMMANDATION UIT-R BS.1693 Procdure de test des systmes automatiques de requte par fredonnement (Question UIT-R 8/6) (2004) LAssemble des radiocommunications de lUIT, considrant a) que, terme, des mtadonnes accompagneront la plupart des systmes de diffusion audio; b) que la p
2、roduction automatique de mtadonnes sera ncessaire pour offrir dans lavenir un service complet prsentant un bon rapport cot-efficacit; c) que les systmes de requte par fredonnement offrent un moyen naturel dinterrogation des bases de donnes audio; d) que diffrents systmes dextraction de mtadonnes son
3、t mis au point actuellement; e) que la Recommandation UIT-R BS.1657 Procdure de test des systmes automatiques didentification audio, dcrit une procdure de test des systmes automatiques didentification audio; f) que le Groupe de Travail 11 de lISO/CEI JTC 1/SC 29 labore actuellement, sous la forme df
4、initive, des systmes de codage de mtadonnes pour les donnes multimdias; g) que, jusqu prsent, aucune procdure dvaluation de la qualit des systmes dextraction de mtadonnes audio relatifs la reconnaissance des mlodies na t normalise, recommande 1 dutiliser la procdure dcrite dans lAnnexe 1 pour valuer
5、 la qualit de fonctionnement des systmes automatiques de requte par fredonnement. Annexe 1 Procdure de test des systmes automatiques de requte par fredonnement 1 Introduction A lheure dun accroissement toujours plus grand des bases de donnes contenu musical, quelles contiennent de vritables donnes a
6、udio ou des mtadonnes associes (donnes sur les donnes), lexigence doutils permettant de conserver ces masses de donnes devient galement chaque jour plus urgente. Ce souhait nest pas seulement exprim par des professionnels, mais galement par le simple amateur de musique utilisateur de lInternet qui n
7、avigue frquemment sur la Toile la recherche de son style musical prfr. Pour faciliter lextraction des donnes souhaites, on peut distinguer ici deux niveaux dabstraction: La recherche de mtadonnes de haut niveau telles que les dcrivait un auditeur (mlodie, rythme, timbre, instrumentation ou genre par
8、 exemple). On peut citer comme exemple dapplication les systmes de requte par fredonnement, qui peuvent tre utiliss par les moteurs de recherche. 2 Rec. UIT-R BS.1693 Lextraction de mtadonnes de niveau intermdiaire pour lidentification automatique de certaines interprtations de contenus musicaux. De
9、s caractristiques techniques dcrivant les donnes audio (contenu spectral, etc.) sont gnres puis compares une base de donnes connue, crant ainsi un lien vers des mtadonnes pertinentes telles quun nom dartiste, le titre dune chanson, etc. Pour un aperu de ltat actuel des techniques en matire de systme
10、s de requte par fredonnement, on se rfrera au Document de lISMIR 2002 (3rd International Conference on Music Information Retrieval, IRCAM Centre Pompidou Paris, France, octobre 2002). 2 Objet Pour rpondre aux exigences de lindustrie musicale, le taux de reconnaissance des techniques appliques de req
11、ute par fredonnement doit tre lev et ne pas tre dgrad par les altrations courantes subies par les reprsentations stockes dans la base de donnes musicales. Ce problme est trait par un certain nombre de solutions diffrentes, souvent propritaires, qui sont apparues rcemment (Clarisse et autres, 2002, G
12、hias et autres, 1995, Haus et Pollastri, 2001, Heinz et Brckmann, 2003). Pour toutes ces mthodes, cependant, les mmes problmes se posent quant leur robustesse vis-vis de modifications ou de dtriorations des donnes dorigine. Il convient donc de proposer que les systmes de requte par fredonnement soie
13、nt idalement aussi prcis et robustes vis-vis de modifications apportes aux signaux que le sont la perception et la reconnaissance humaine. Par consquent, un systme de requte par fredonnement sophistiqu doit tre robuste vis-vis des diffrentes distorsions de qualit du signal et variations par rapport
14、la mlodie idale. Par ailleurs, le maniement fiable de grandes bases de donnes musicales comprenant plusieurs milliers de chansons devrait galement tre assur. En consquence, pour valuer la qualit dun systme automatique de requte par fredonnement, il faut dfinir un environnement de test couvrant diffr
15、ents types de modification des signaux et dcrivant la faon de dterminer dautres paramtres essentiels du systme. Une procdure de test unifie est ncessaire pour parvenir une valuation objective de ces systmes de requte. 3 Paramtres de qualit Il convient de considrer les paramtres de qualit ci-aprs pou
16、r valuer les systmes de requte par fredonnement: Donnes audio dentre requises: Doit-on fredonner une partie prcise de la chanson ou peut-on en chanter une partie quelconque? Quelle est la taille minimale des donnes audio dentre pour obtenir un rsultat fiable? Taille de la reprsentation des donnes: C
17、ombien de donnes (octets) par chanson doivent tre stockes dans la base de donnes musicales? Taille de la base de donnes musicales: Combien de chansons peuvent tre traites dans la base de donnes musicales? Rec. UIT-R BS.1693 3 Mode didentification: De quelle faon le type de donnes dentre (chant dans
18、la langue maternelle, ou chant fredonnement dun air tel que na na na, etc., utilisation dun instrument de musique quelconque) a-t-il une incidence sur le taux de reconnaissance et sur la qualit de fonctionnement? Vitesse de reconnaissance de la mlodie: Quel est le temps ncessaire pour identifier une
19、 mlodie? Comment varie cette dure avec le nombre de chansons figurant dans la base de donnes? Comment varie cette dure avec la qualit des donnes dentre? Pour valuer ces proprits dune manire raliste et donc pour dterminer si un systme est adapt des applications relles, un environnement de test doit p
20、rsenter des conditions aux limites constantes en ce qui concerne les caractristiques testes. Les conditions de test doivent porter sur: la taille et le contenu de la base de donnes musicales (voir le 4); la taille des donnes de requte (en termes de dure denregistrement) et le nombre denregistrements
21、 de test (voir le 4); les rgles exactes de modification des enregistrements de test (voir le 5 et le 6); et la plate-forme de calcul (spcification de lunit centrale, de la mmoire et du systme dexploitation) (voir le 7). 4 Slection des donnes de test et taille de la base de donnes musicales Une base
22、de donnes contenant des chantillons musicaux de rfrence et laquelle tous les systmes pourraient adresser leurs requtes devrait tre dfinie. Elle devrait comprendre un mlange des diffrents styles musicaux (musiques populaires de diffrents pays, musique classique, ) avec une priorit donne lchelle mondi
23、ale aux chansons les plus connues. Il faudra particulirement veiller viter la duplication des enregistrements dans la base de donnes (reprises, etc.). Une base de donnes musicales comprenant 500 1 000 chansons est suggre pour une valuation statistiquement fiable et pertinente. Etant donn quil est di
24、fficile et coteux dlaborer des reprsentations abstraites de qualit leve des chansons mesure que celles-ci sont ncessaires pour la recherche dans la base de donnes, la cration de la base de donnes musicales de rfrence est laisse linitiative des participants. Cette procdure induira un critre de qualit
25、 implicite qui trouvera son sens la lecture des rsultats de test obtenus. Tous les participants sont libres de choisir le format interne de la base de donnes puisque celui-ci dpend de lalgorithme de recherche. Un ensemble denregistrements de test (base de donnes dchantillons de requte) devrait tre d
26、fini afin de satisfaire aux prescriptions suivantes: pour viter tout talonnage dun ensemble spcifique de requtes, chaque participant devrait fournir un nombre total de 200 mlodies de requte. Ladaptation des paramtres dun systme de requte par fredonnement une base de donnes de requtes fournies subjec
27、tivement peut ainsi tre exclue. Les enregistrements de test devraient prsenter une bonne qualit audio et tre idalement sans distorsion. Les donnes dentre devraient comprendre une diversit de types, telles que des paroles chantes, des mlodies fredonnes (da, na, ta, la, ) ou des compositions instrumen
28、tales. Elles devraient provenir dun ensemble reprsentatif de chanteurs et de musiciens. 4 Rec. UIT-R BS.1693 Tous les enregistrements de test doivent reprsenter des mlodies contenues dans la base de donnes de rfrence. Le rejet dun enregistrement de test nest pas une ventualit envisageable en raison
29、du degr continu de similarit entre les mlodies. Le nombre de systmes de requte par fredonnement nouvellement tests devenant toujours plus grand, la taille de la base de donnes des chantillons de requte saccrotra sans cesse. Le test rpt de ces systmes sera donc ncessaire pour comparer les qualits de
30、fonctionnement mesures en utilisant une base de donnes des requtes statistiquement toujours plus reprsentative. Une procdure de test automatique est recommande. 5 Modifications Pour reprsenter de faon plus raliste les applications relles, les chantillons de test de qualit leve (voir le 4) devraient
31、tre modifis via lapplication des sources habituelles de pollution sonore: compression audio (mp3, aac, .); limitation de la largeur de bande (tlphonie, .); quantification (modulation par impulsion et codage, loi A, .); distorsion GSM ( plein dbit, .); bruit de fond (d un public, dans un restaurant,
32、dans un magasin de musique, .). La liste des rgles exactes est donne dans le 6. 6 Mthode de test Le principal paramtre permettant dvaluer la qualit des systmes considrs sera le pourcentage de mlodies classes correctement. On peut distinguer deux cas: lenregistrement recherch est class en premire pos
33、ition sur la liste des rsultats prsents; lenregistrement recherch figure parmi les dix mlodies considres comme les plus ressemblantes par le systme. Ces chiffres ainsi que la vitesse du processus dextraction et de recherche (classification) doivent tre mesurs test par test. 6.1 Test 1 Lors du premie
34、r test, aucun titre de la base de donnes des chantillons de requte ne doit tre modifi et tous les titres doivent tre identifis. Les conditions optimales en termes de qualit audio sont donc respectes et les rsultats devraient prsenter un taux didentifications correctes trs lev. 6.2 Test 2 Il sagit de
35、 tester la robustesse du systme lorsque diverses modifications sont appliques aux enregistrements de la base de donnes des chantillons de requte. Les modifications choisir doivent correspondre des distorsions acoustiques observes dans la vie courante. Distortion GSM: Les chantillons de test doivent
36、faire lobjet de trois techniques distinctes de codage vocal utilises en tlphonie mobile (GSM plein dbit, plein dbit amlior et mi-dbit). Rec. UIT-R BS.1693 5 Compression audio: Les exemples utiliss doivent tre compresss/dcompresss en utilisant des codecs audio MPEG-1/2 de couche 3 appliquant des dbit
37、s de codage de 64, 96 ou 128 kbit/s. Le codec Fraunhofer classique est recommand. Quantification: Les chantillons de test doivent faire lobjet dune quantification de loi A non linaire (8 kHz, 8 bits). Limitation de la largeur de bande: Le flux dentre est limit par une bande passante correspondant un
38、e qualit de tlphonie courante, cest-dire par la bande 300-3 400 Hz. Les caractristiques de filtrage de la bande passante utilise doivent satisfaire une spcification dinclinaison de pente dau minimum 12 dB/oct. Bruit de fond: Pour avoir une base de donnes de distorsion quasi normalise des signaux voc
39、aux et du bruit de murmures confus (brouhaha) observs dans la vie quotidienne, il convient dutiliser les indications du Document Dreschler et autres. Deux types distincts de signaux de bruit doivent tre associs aux donnes de requte dorigine, savoir respectivement, en utilisant les pistes de bruit et
40、 les versions attnues (6 dB): murmures confus de 2 personnes (effort normal, piste 6); murmures confus de 6 personnes (effort soutenu, piste 8). 7 Plate-forme de test Il convient dutiliser comme plate-forme de calcul et systme dexploitation des quipements adapts ltat davancement des techniques offer
41、tes lutilisateur courant. En 2004, on peut citer comme plate-forme approprie et facilement disponible un ordinateur Pentium 4/Athlon XP fonctionnant 2,4 GHz avec 512 mgaoctets de mmoire vive et utilisant Windows XP ou Linux. 8 Rapport de test Les rapports de test devraient indiquer, aussi clairement
42、 que possible, la logique de ltude, les mthodes utilises et les conclusions auxquelles on a abouti. Ils devraient tre assez dtaills pour quune personne raisonnablement comptente puisse, en principe, reproduire ltude afin den vrifier empiriquement les rsultats. Un lecteur inform devrait tre capable d
43、e comprendre les principaux dtails du test et den dvelopper un point de vue critique, concernant par exemple les raisons sous-jacentes ayant motiv ltude, les mthodes de conception exprimentales et leur mise en oeuvre, ainsi que les analyses et les conclusions. Une attention particulire devrait tre p
44、orte aux points suivants: la spcification et la slection de la base de donnes musicales et de la base de donnes des chantillons audio; la description dtaille des systmes tests; la description dtaille de lensemble des conclusions tires. 6 Rec. UIT-R BS.1693 Rfrences bibliographiques CLARISSE, L. P.,
45、MARTENS, J. P., LESAFFRE, M., DE BAETS, B., DE MEYER, H. et LEMAN, M. octobre 2002 An Auditory Model Based Transcriber of Singing Sequences. ISMIR 2002, 3rd International Conference on Music Information Retrieval, IRCAM Centre Pompidou Paris, France, p. 116-123. GHIAS, A., LOGAN, J., CHAMERLIN, D. e
46、t SMITH, B. C. 1995 Query By Humming. Musical Information Retrieval in an Audio Database. Procs ACM Multimedia 1995, p. 231-236. HAUS, G. et POLLASTRI, E. 2001 An Audio Front End for Systmes de requte par fredonnement. Procs ISMIR 2001, p. 65-72. HEINZ, Th. et BRCKMANN, A. mars 2003 Using a Physiolo
47、gical Ear Model for Automatic Melody Transcription and Sound Source Recognition. AES 114th Convention. Amsterdam, Pays-Bas. DRESCHLER, W. A., VERSCHUURE, H., LUDVIGSEN, C. et WESTERMANN S. ICRA Noises: Artificial noise signals with speech-like spectral and temporal properties for hearing aid assessment. Audiology, 40, p. 148-157.
