La curiosité m’a poussé à réaliser précédemment plusieurs comparatifs de formats audio, tous rendus publics sur Hydrogenaudio.org. Tous ces tests partageaient cependant trois mêmes limites :  
• échantillons limités à un type musical (« classique »)
• échantillons en nombre limités (15…20)
• résultats propres à une seule personne
 
Borner mes évaluations au genre dit « classique » me permettait de mieux cerner les performances des différents encodeurs avec le genre exclusif que j’affectionne. Mais malgré cela, je sentais qu’un panel de quinze échantillons environ ne pouvait couvrir pleinement l’ensemble des situations auxquelles les encodeurs sont confrontés lors de l’encodage d’une large discothèque. En testant 15 échantillons à peine, j’étais assuré de laissé de côté plusieurs problèmes, et donc de fausser une évaluation qui avait pour but d’être représentative. Il faudrait en effet plusieurs centaines d’échantillons pour représenter un instrumentarium foisonnant (une centaine d’instruments différents), offrant pour la plupart de larges possibilités dynamiques, et pouvant être combinés à loisir. Sans parler de la voix – soliste ou en chœur – ni même des possibilités infinies de l’électronique, utilisée depuis une cinquantaine d’années…
 
On peut évidemment s’interroger sur la nécessité d’une telle précision. Pourtant, l’intérêt pratique me semble réel. Il existe désormais des appareils supportant des formats émergeants, plus efficient (normalement) que les sempiternels MP3 & WMA, et qui permettent d’accroître leur capacité musicale sans trop compromettre la qualité. Encore faut-il être certain que ces formats tiennent leur promesse, et que les performances étonnantes que l’on peut noter par le biais de comparatifs ponctuels n’aient pas pour contreparties des régressions sur d’autres types de signaux. D’où l’intérêt – du moins lorsqu’on s’en sent le courage – de tester de manière extensive l’ensemble des solutions de codages actuellement offertes à l’utilisateur. Ce qui est mon cas, du moins actuellement.
 
 
 
Pour mener à bien ce projet, j'ai entrepris de collecter un maximum d'échantillons sonore, de les trier pour enfin en organiser la sélection en un vaste catalogue raisonné. Cette galerie reflète la variété des instruments et des combinaisons que l'on retrouve avec la musique dite classique. Elle s'organise de la manière suivante :  
 
• musique artificielle : catégorie musicale apparue dans la 2de moitié du XXème siècle, constituée de signaux générés électroniquement ou de sonorités concrètes modifiées par ordinateur (5 échantillons)
 
• musique soliste : suite d'échantillons d'instruments enregistrés seuls, et scindée en diverses catégories : instruments à cordes et archet, claviers, instruments à vents, à cordes pincées et quelques raretés. Total : 55 échantillons
 
• musique jouée de concert : instruments jouant ensemble [concert n'est pas à prendre ici dans le sens de "live"], soit par effectif réduit (musique de chambre) soit par effectif plus imposant (musique orchestrale). Chacun de ces deux groupes est subdivisé en deux catégories : instruments d'époques (instrumentarium correspondant à l'âge de la Renaissance, du baroque et du classique, cordes en boyau, pianoforte, etc...) et instruments modernes (apparus pour l'essentiel au cours du XIXème et toujours joués dans les salles actuelles). Total : 60 échantillons
 
• musique vocale : représentant aussi bien les voix seules, en duo, en chœur ou plain-chant. Voix presque toujours accompagnées d'instruments (d'un seul à la totalité d'un orchestre). Total : 30 échantillons.
 
Le catalogue ainsi défini est constitué de 150 échantillons, assez pour couvrir l'essentiel des situations instrumentales et/ou vocales du genre dit "classique". J'ai également veillé à ce que les caractéristiques techniques les plus variées y figurent : enregistrements réverbérés, acoustique sèche, présence de bruit de fond, volume sonore bas, très bas ; élevé, très élevé; prise de studio et captation de concert parasitée soit par les toussotements soit par les oiseaux (églises). Voila pourquoi certains instruments sont représentés plusieurs fois. Mais dans l'ensemble, les conditions techniques des échantillons sélectionnés convergent vers la moyenne des enregistrements réalisés ces 20 dernières années : enregistrements précis, détaillés, avec peu voire pas de souffle. Enfin, j'ai délibérément écarté les vieilles cires de cette galerie ; n'y figurent donc ni enregistrements monophoniques, ni enregistrements dits "pirates" (captation de concert de qualité variant du médiocre à l'épouvantable).
 
 
 
Pour intéressant que puisse être à mes yeux un tel test, il ne sera guère utile à d’autres si seule la musique dite « classique » (fusse au travers de 150 échantillons) se voit être analysée. Aussi ai-je décidé d’ajouter un second groupe d’échantillons, constitué de musique que je nommerais pour faire simple de « variée ». N’ayant pas de CD à ma disposition, j’ai été contraint d’utiliser des échantillons disponibles sur la toile et utilisés lors d’autres tests. En additionnant tous les échantillons « non-classique » sélectionnés lors des différents tests collectifs organisés par Roberto Amorim, j’obtient un total de 35 échantillons, ce qui est déjà deux à trois fois plus important que celui de chacun des tests organisés précédemment.
 
 
En résumé, le test qui va suivre sera articulé autour de 185 échantillons, organisés en deux groupes :  
• classique : 150 échantillons
• variété : 35 échantillons
 
 
 
-----------------
 
Pour ce premier test, j’ai décidé de cibler un débit de 80 kbps. Les raisons d’un tel débit ? Il est de coutume de s’intéresser aux multiples de 64 (64 kbps, 128 kbps, 192….). La raison en incombe certainement aux équations marketing utilisées sans vergogne par tous les éditeurs, qui prétendent tous offrir à 64 kbps des performances au moins égales au MP3 à 128 kbps (débit sans doute le plus couramment utilisé). C’est peut-être vrai pour du MP3 “ISO” façon Blade ou Xing, mais totalement exagéré à mon sens sitôt que l’on oppose à ces formats des encodages MP3 réalisés avec la dernière génération d’encodeurs. Par ailleurs, je n’ai pas encore rencontré un format ayant offert à 64 kbps quelque chose de convenable à mes oreilles et pouvant me satisfaire même en condition d’écoute urbaine. Par contre, j’ai noté que certains de ces formats sont déjà nettement moins en souffrance dès que l’on élevait un peu le débit. Ainsi, si tous ont à souffrir à 64 kbps de la pénurie de bit, à 80 kbps d’aucuns ne manquent pas d’offrir des résultats plus probants, pouvant (me) satisfaire à une utilisation nomade sur des écouteurs moyens.
Voila pourquoi j’ai décidé d’entamer le test par ce débit, projetant quoi qu’il arrive d’en réaliser d’autres à des débits plus élevés.
 
 
 
PREMIÈRES DIFFICULTÉS
 
 
C’est une fois le débit ciblé et les échantillons sélectionnés que surviennent les premières grosses difficultés. Il existe de nombreux formats et une pléthore d’encodeurs. Que tester ? Ce qu’on a envi, ou ce qui nous est utile évidemment. On pourra faire l’impasse sur les formats délaissés (vqf, MP3pro, Qdesing…), explicitement spécialisés vers d’autres débits (DTS, MPC voire MP3) ou ne supportant pas ce débit binaire (Atrac3, WMA9Pro). Ne restent plus véritablement que l’AAC (supporté d’ores et déjà dans des baladeurs tels que l’iPod et employé sur l’iTunes Music Store, les téléphones Nokia & Sony et quelques autres produits), L’ogg Vorbis (supportés dans des produits Samsung, iRiver, iAudio, Olympus, et d’autres encore) et le WMA (qui bénéficie d’un support très large, et qui est employé par de nombreux magasins en ligne).
Mais la difficulté réside ailleurs. Pour chacun de ces formats, il existe plusieurs possibilités d’encodage. Les mieux lotis bénéficient de plusieurs implémentations (on en compte une douzaine pour l’AAC, mais seules quelques unes sont réellement adressées au grand public) ; quant aux autres, ils pourront être utilisés suivant plusieurs paramétrages : CBR, ABR, VBR. Lorsqu’il s’agit d’établir le nom du meilleur format, il faut être certain d’utiliser pour chacun d’eux la meilleure solution d’encodage. Il existe deux manières d’établir un choix :  
 
• procéder par ouï-dire et choisir la version ou le paramétrage qui jouit de la meilleure réputation. Cette méthode n’est évidemment pas très fiable. Car beaucoup de ces rumeurs n’ont d’autres fondements que des croyances (la supériorité systématique du VBR sur le CBR a été invalidée par des tests, surtout avec certains formats) ou des espoirs un peu trop zélés et partiaux (ainsi pour l’AAC, d’aucuns ne jureront que par iTunes parce que c’est Apple, d’autres par Nero parce que c’est VBR et certains par faac parce qu’il est open-source).
 
• procéder par une évaluation méthodique de toutes les solutions d’encodages disponibles. Cette méthode a pour avantage sa rigueur, pour inconvénient son impraticabilité. Car tester une dizaine d’encodeurs AAC, que l’on dédoublera en ABR et VBR, avec parfois des modes dits ‘rapide’ ou ‘qualité’, ‘optimal’ ou ‘bon’… soient 20 à 30 implémentations multipliés par 185 échantillons : autant commencer dès maintenant pour espérer publier le test final à la fin de l’été… prochain.
 
Pour résoudre cette première difficulté, j’ai décidé d’emprunter aux deux méthodes. De la première, je retiens l’idée d’évincer certaines des implémentations dépassées, ou abandonnées, afin de ne garder que celles que le bon sens retient comme étant les plus pertinentes, mais aussi les plus aisément disponibles (pas question par exemple de tester un improbable encodeur vendu sous la forme de plug-in commercialisé au prix d’une automobile destiné à fonctionner dans un logiciel vendu au prix du garage et de la maison qui vont avec). De la seconde méthode, je retiens l’idée de procéder par une évaluation méthodique, mais par sur la totalité des 185 échantillons : simplement sur une sélection d’entre eux.
Au final, j’ai conclu sur l’idée de réaliser des tests préliminaires, organisés en autant de poules que de formats. Le vainqueur de chaque poule sera introduit dans l’arène finale, qui conclura le test. Chacune des poules est constituée de 40 échantillons (25 classiques, 15 de variétés), dont la liste est bien entendu maintenue à l'identique pour chacune des poules (le nom des échantillons sélectionnés figurent dans les tableau de notation, postés plus bas).
 
 
DEUXIÈME DIFFICULTÉ
 
(à venir)
 
 
NOTES CONCERNANT LA METHODOLOGIE
 
 
L'ensemble des évaluations a été réalisée en "double-aveugle", grace au logiciel ABC/HR développé par Schnofler. En d'autres termes, pour chacune des notations :
 
- il m'a d'abord fallu distinguer l'encodé de la référence en les départageant au sein d'une paire anonymée (ce qui, à 80 kbps, n'est pas excessivement difficile)
- j'ai accordé une note sans jamais être informé du nom du format ainsi évalué. Ce n'est qu'une fois le test achevé que sont rendus accessibles les résulats.
 
En raison du grand nombre d'échantillons et de formats testés, j'ai fait l'impasse sur la confirmation de type ABX. La grande quantité d'échantillons permet de gommer d'éventuelles erreurs de notation (note attribuée par mégarde à l'original) au moment de l'analyse statistique. Pour cette dernière, la méthode "Tukey Parametric" a été employée. Voir: ff123's "Web Statistical Analysis of Listening Test Data".

POULE No.1 : NERO AAC-LC
 
 
Depuis plus d’un an, Nero propose à l’utilisateur deux encodeurs AAC différents. Le second encodeur se dissimule sous le mode nommé “rapide” ou “fast” qui, chacun peut le constater, n’est pas plus rapide que le mode nommé “haut” ou “high”. Cet encodeur “fast” est en fait un nouvel encodeur, plus performant, et amené à se substituer à terme au codec actuellement proposé par défaut. S’il ne l’est pas encore, c’est simplement parce qu’il n’est pas jugé suffisamment mature pour affronter l’ensemble des difficultés de codage.
J’avais déjà testé ce mode « fast » à ~130 kbps, et j’avais noté qu’il surclassait largement (et même très largement) l’encodeur « high » sur de la musique classique. Ces résultats enthousiasmants sont cependant trop limités, et ne permettent ainsi  en rien de préjuger des performances de ce codec prometteur à débit inférieur ; par ailleurs, je ne sais rien de ses performances sur d’autres genres musicaux que le classique, seul testé jusqu’alors. Le premier objectif de cette poule sera donc d’établir lequel des deux encodeurs (fast ou high) présente le meilleur compromis. Le second objectif sera d’opposer le mode CBR au mode VBR. Pour ce dernier, seul l’encodeur “high” sera testé, puisque le débit obtenu avec l’encodeur “fast” dépasse largement la limite fixée (67 kbps à peine pour “fast” et 87 kbps pour “high”.
 
En résumé :  
• Nero AAC Codec 3.2.0.15 “fast” CBR 80
• Nero AAC Codec 3.2.0.15 “high” CBR 80
• Nero AAC Codec 3.2.0.15 “high” VBR ::radio:: [87 kbps sur 185 échantillons]
 
 

 
(le tableau analytique des résultats peut être vu >ici<)
 
 
Les résultats sont assez contrastés. Pour ce qui concerne le premier groupe (classique), l’encodeur ‘fast’ surclasse aisément son cousin ‘high’, que ce soit en CBR ou en VBR. J’obtiens donc à 80 kbps ce que j’avais constaté dans le passé à 128 kbps et au-delà. Par contre, avec le groupe No.2, ce même encodeur est légèrement en retrait par rapport au VBR ‘high’ (2.00 vs 2.20) encore que statistiquement, les deux doivent être considérés d’égal à égal. Le véritable perdant est CBR ‘high’, qui arrive dernier dans les deux groupes. Le choix le plus pertinent est indubitablement CBR ‘fast’, qui obtient score d’ensemble (2.38) nettement plus probant que le VBR ‘high’ (1.98), supériorité obtenue avec une marge d’erreur inférieure à 5%.
C’est donc l’encodeur ‘fast’ en mode CBR qui affrontera sous les couleurs de Nero ses rivaux AAC-LC.
 
 
 
POULE No.2 : AAC-LC (Nero, iTunes, faac)
 
 
iTunes n’offre qu’un mode CBR pour l’heure, qui rejoint la poule sans avoir à effectuer de  
pré-test.  
faac par contre présente un mode ABR en plus du mode VBR. J’avais entamé une poule pour départager les deux modes, mais l’écart fut tellement prononcé (le mode ABR est handicapé par un lowpass nettement plus restrictif, mesuré après coup à 8000 Hz, contre 13000 pour le VBR) que j’ai jugé préférable d’y mettre un terme prématuré. Le mode VBR de faac rejoint donc cette poule. –q80 offrant un débit largement supérieur à celui visé, j’ai opté pour –q70, chiffre rond, qui présente malgré tout un débit moyen supérieur à ce qui est toléré pour le second groupe (94 kbps), mais au vu des résultats finaux, cette surcharge ne prêtera pas à conséquence.
L’encodage Nero correspond au mode “fast” CBR (voir POULE No.1 pour les détails).
 
Figurent dans cette poule :  
• faac 1.24.1 –q70 [84 kbps sur 185 échantillons]
• iTunes v4.9.0.17 / QuickTime 7.0.2 CBR 80
• Nero AAC Codec 3.2.0.15 “fast” CBR 80
 
 

 
(le tableau analytique des résultats peut être vu >ici<)
 
 
• faac est très largement inférieur à ses rivaux directs, et ce malgré un débit sensiblement supérieur pour les échantillons du deuxième groupe. Cet écart est moins la conséquence d’un lowpass en défaveur de faac (13 KHz, contre 14 pour Nero et 15 environ pour iTunes) que celle de déformations trop fréquentes et trop marquées. Parmi elles, je signale qu'il m'a été donné d'entendre à de nombreuses reprises un problème de grondement dans les basses fréquences (warbling) dont souffre faac jusque dans les très haut débit. On pardonnera à cet encodeur gratuit et développé bénévolement cette contre-performance en gardant à l’esprit qu’il a surtout été optimisé pour des débits supérieurs à 100 kbps. Il est plus intéressant de noter par le biais de ses deux rivaux les progrès accomplis autour de l’AAC-LC à bas débit, et qui révèlent un potentiel que les implémentations plus anciennes ou moins avancées du format, telle faac, occultaient entièrement.
 
• iTunes obtient des résultats constants d’un groupe à l’autre. A l’évidence, l’encodeur est équilibré et offre des performances similaires quel que soit le type (de manière générale en tous cas) de musique encodé. On signalera un lowpass moins agressif que celui de Nero (15 KHz vs 14 KHz), caractéristique souvent audible et favorisant iTunes AAC en certaines circonstances. C’est surtout avec de la musique variée que l’encodeur iTunes/QuickTime se distingue de son concurrent.
 
• Nero AAC n’offre pas la même homogénéité que son rival direct, puisqu’on assiste à un affaissement des performances d’un groupe à l’autre. Ce résultat n’est pas surprenant, dans la mesure où cette disparité entre musique classique et musique autre avait été constatée lors de la poule de qualification Nero (Poule No.1). Mais la différence n’est pas dramatique non plus : l’avantage qualitatif tangue trop souvent d’un codec à l’autre, ce qui explique pourquoi la supériorité d’iTunes n’est assuré qu’avec 50% de probabilité seulement.
 
=> au final, iTunes et Nero sont au coude à coude (statistiquement, ils ne sont pas départageable avec une certitude de 95%), avec cependant un avantage quantitatif (la moyenne des notes) pour iTunes AAC, obtenu sur le second groupe d’échantillons. C’est donc cette implémentation de l’AAC-LC qui est qualifiée pour la finale.
 
 
 
POULE No.3 : AAC-HE
 
 
Pour ce test, j’ai du me contenter d’une seule implémentation éditoriale du format (Nero), déclinée en deux encodeurs (“fast” et “high”. D’autres sont apparues depuis (Real par exemple) ou sont en cours de portage pour Windows (Apple QuickTime). Comme je ne disposais d’aucune autre version pas plus d’une connexion internet pour télécharger des versions rivales, j’ai du faire avec Nero. Est-ce dommageable ? La version AAC-HE de Nero est considérée (à raison ?) comme la meilleure ; une chose est certaine : elle est la plus ancienne (2 ans), puisque sortie juste après la finalisation du format – et, logiquement, la plus travaillée.
Pour ceux qui s’interrogent sur la différence entre AAC-LC et AAC-HE, une rapide explication. L’AAC est un format audio qui se décline en plusieurs profils d’encodage (LC, HE, Main, LTP… dont le plus courant est le Low Complexity et le plus prometteur l’High Efficiency. L’HE-AAC se distingue essentiellement du LC-AAC par l’introduction d’une couche nommée SBR (Spectral Band Replication) qui permet de coder de manière séparée les plus hautes fréquences avec très peu de bits (mais beaucoup d’approximations !). En conséquence, un encodage HE-AAC nécessite un décodeur adéquat pour être pleinement décodé ; par contre, ce même encodage est compatible avec les décodeurs AAC usuels, mais seule la partie « inférieure » du spectre sera restituée. Cette situation présente des similtudes avec celle déjà ancienne du rapport entre MP3 et MP3Pro. Et c’est normal, puisque le MP3Pro n’est autre chose que du MP3 + SBR, de la même manière que l’HE-AAC n’est rien de plus que de l’AAC + SBR.
Le SBR est une technologie puissante qui assure au format qui lui est associé un bond qualitatif spectaculaire à bas débit. Par contre, à mesure que le débit s’élève (et que la qualité des formats ‘nature’ s’améliore), le SBR devient inutile sinon nuisible. Nero par exemple ne permet pas pour cette raison d’utiliser le SBR au-delà de 96 kbps (techniquement, l’HE-AAC est envisageable jusqu’à 448 kbps en stéréo) – et encore est-ce le LC-AAC qui est proposé par défaut à ce débit. A 80 kbps par contre, Nero ‘suggère’ à l’utilisateur de privilégier l’AAC-HE sur l’AAC-LC.
 
L’AAC-HE s’utilise en CBR comme en VBR. Nero cependant n’offre pas de mode VBR permettant d’atteindre un tel débit (j’obtiens respectivement 61 et 64 kbps au maximum avec les modes ‘fast’ et ‘high’. Opposer des encodages VBR à 60 kbps à des encodages CBR à 80 kbps n’ayant que peu de sens, j’ai limité l’opposition aux deux encodeurs CBR embarqués dans la suite de gravure de l’éditeur allemand :  
• Nero AAC Codec 3.2.0.15 “fast” CBR 80
• Nero AAC Codec 3.2.0.15 “high” CBR 80
 
 

 
(le tableau analytique des résultats peut être vu >ici<)
 
L’analyse des tests n’apporte guère de commentaires. Sur les échantillons du premier groupe, les deux encodeurs offrent des performances similaires. Contrairement au LC qui avait vu l’encodeur nommé “fast” surclasser son aîné sur la musique classique, le profil HE ne bénéficie pas des mêmes avantages. Par contre, on retrouve la même infériorité de l’encodeur “fast” sur les échantillons du groupe 2. On remarquera enfin les notes extrêmement basses obtenues dans cette poule. L’HE-AAC présente en effet des artefacts terriblement gênants à mes oreilles, et ce, quelle que soit la nature des échantillons testés.
 
 
 
POULE No.4 : Ogg Vorbis
 
 
Vorbis ne présente pas la même abondance d’encodeurs que l’AAC. Dans le cadre de ce test, c’est un avantage certain pour le testeur . Deux encodeurs peuvent être mis en compétition : la version officielle et la version d’Aoyumi (nommée aoTuV). Quelques mots sur cette dernière. aoTuV représente une branche de développement indépendante qui a pour racine la version officielle de Vorbis. Elle est apparue il y a 18 mois environ, et s’attelle à corriger nombre de problèmes posés par la version de référence de l’encodeur. Les modifications d’Aoyumi ont été jugées suffisamment pertinentes par XIPH (originaire du format) pour que le code de la beta 2 d’aoTuV soit repris et officialisé (il y a un an) afin de devenir la version 1.1 de l’encodeur de référence. Plus qu’une simple branche expérimentale, aoTuV peut ainsi être considéré comme la grande sinon l’unique source de progrès de l’ogg vorbis. Depuis, deux autres beta d’aoTuV ont vu le jour – et c’est la beta 4 qui sera opposé ici à l’encodeur de référence (1.1.1, qui ne présente d’améliorations que fonctionnelles et non qualitatives par rapport à la 1.1). Cette poule permettra ainsi d’évaluer les apports de cette nouvelle version d’aoTuV.
 
J’ai profité du peu de compétition offert par Vorbis pour y inclure des encodages ABR. Vorbis est un encodeur orienté VBR qui pendant longtemps ne disposait pas de mode CBR/ABR. Ces fonctionnalités ont été introduites ultérieurement (elles ont d’ailleurs été souvent bugguées… pour répondre à des besoins précis (streaming par exemple), mais restent aujourd’hui encore déconseillées pour un usage régulier. Je profite de cette poule pour y ajouter des encodages ABR (testé ici avec l’encodeur officiel, qui est à en croire le changelog le plus avancé en terme de ‘bitrate management’.
 
Quelques mots à propos du débit pour finir. Le mode VBR qui permet d’obtenir 80 kbps avec vorbis correspond à –q1. Le débit final obtenu sur l’encodage des 185 échantillons est de 78 kbps avec l’encodeur 1.1.1, et de 85 kbps avec aoTuV. Cet écart représente 10%, et s’il reste méthodologiquement acceptable de les opposer, il serait cependant inepte de le faire dans la mesure où vorbis permet d’ajuster le débit beaucoup plus finement. J’ai donc décidé de conserver pour aoTuV le paramétrage de –q1 et d’ajuster celui de 1.1.1 en conséquence : -q1.5 (chiffre rond), offrant un débit de 84 kbps. Pour l’ABR, j’ai opté pour un débit cible de 83 kbps, offrant un débit final calculé à 84 kbps.
En résumé, sont testés :  
• vorbis 1.1.1 –q 1,5
• vorbis 1.1.1 ABR 83 (obtenu avec le logiciel – remarquable ! - OggDropXPd de John33)
• vorbis aoTuV beta 4 –q 1,00
 
 

 
(le tableau analytique des résultats peut être vu >ici<)
 
• ABR 83 : sans grande surprise, l’ABR est en retrait par rapport au VBR. Les résultats sont néanmoins loin d’être catastrophiques. Avec la musique classique, l’ABR offre même des performances comparables au VBR, à l’exception toutefois d’échantillons nécessitant un très fort débit (groupe ARTIFICIAL). En quelques rares cas, l’ABR est d’ailleurs préférable au VBR (certains échantillons ultra-tonaux notamment). Il faut cependant garder à l’esprit que les échantillons du groupe 1 sont codés à 84 kbps en ABR et 78 en VBR, et que ce dernier présente donc un surcroît d’efficience que la notation ne reflète pas entièrement. En revanche, la différence est sensiblement plus prononcée avec les extraits du groupe 2, pour lesquels le VBR est nettement préférable, et ce à débit moyen identique. Au final, et à l’exception de quelques échantillons, l’ABR ne présente pour défaut rien d’autre qu’un léger accroissement du bruit de fond, parfois perceptible sous la forme d’une poussée des hautes fréquences ou d’une grossièreté de rendu des timbres.  
 
• Entre les encodages VBR obtenus avec la version officielle et la version aoTuV, la différence est ténue avec les échantillons du groupe 1. J’avoue ma déception, car cette beta 4 présente des modifications qui auraient dû permettre une réduction sensible des défauts du format surtout mis en évidence, à ce débit, avec des échantillons classiques (montée du bruit liée au codage avec perte de la stéréo spécifique à Vorbis). On remarquera tout de même que ce mince écart synthétise des résultats qui analytiquement sont plus contrastés : on assiste avec aoTuV à une chute qualitative sur certains échantillons comme à un bond réel.
L’analyse des résultats du groupe 2 présente plus de lisibilité. Sur de la musique variée, le VBR se détache de l’ABR, et la version aoTuV décolle littéralement pour atteindre le meilleur score toutes poules confondues ! A l’évidence, les modifications apportées par Aoyumi profiteront prioritairement à ceux qui écoutent autre chose que Brahms. En de très nombreuses occasions, il m’a été donné l’occasion de constater une forte réduction de cette poussée du bruit de fond qui caractérise Vorbis.
 
=> la version aoTuV rejoint ses concurrents pour la finale.
 
 
 
POULE No.5 : WMA 9.1 Standard
 
 
Dernière poule de ce comparatif avant la finale, et qui concerne le deuxième format le plus présent dans les appareils actuellement sur le marché : le WMA. Le format utilisé ici correspond au WMA ‘classique’ ou ‘standard’, qui doit être différencié du format baptisé WMA Professional, incompatibles entre eux. Le WMA Pro ne figure pas dans ce test, puisqu’il n’est pas possible d’obtenir un débit de 80 kbps avec la version 9.1 du format (le débit plancher du CBR est 128 kbps, et celui obtenu en VBR est de 69 kbps en mode Q10 et 110 kbps en mode Q25).
 
Depuis la sortie de la « série 9 » de Windows Media, le format s’est enrichi de fonctionnalités intéressantes : encodages VBR, ou encore encodages sur deux passes. L’encodage double passe ne devrait pas être utilisé sur des courts échantillons (de la même manière qu’on ne peut tester les formats vidéos en double passe sur de courts extraits : la distribution doit être effectuée sur une plage de temps plus grande). Deux modes restent ainsi en lice : CBR et VBR. Le mode VBR Q25 semble correspondre au débit ciblé : 81 kbps en moyenne (76 kbps sur les 150 échantillons du groupe 1 et 88 kbps pour celui du groupe 2). Sont donc testés :  
• Windows Media Audio 9.1 CBR 80
• Windows Media Audio 9.1 VBR Q25
 
 

 
(le tableau analytique des résultats peut être vu >ici<)
 
• WMA CBR : très nette recul qualitatif constaté pour les échantillons du second groupe. De toute évidence, le format, en CBR et à ce débit, éprouve moins de difficulté avec la musique classique. Relativement aux encodages VBR, ceux réalisés à débits constants sont inférieurs, et ce quelque soit le groupe choisi. Dès lors, il semble préférable d’utiliser à ce débit et pour ce format VBR Q25.
 
• WMA VBR : progrès par rapport au CBR, surtout d’ailleurs avec les échantillons du second groupe, pour lesquels les notes sont les plus contrastées. Microsoft a donc réussi à faire progresser son encodeur grâce à l’implémentation d’un mode à débit binaire variable dans l’ensemble efficace.
 
=> le mode VBR Q25 est qualifié pour la finale.

FINALE : AAC-HE vs AAC-LC vs MP3 vs Vorbis vs WMA std
 
 
Au terme des poules de qualifications, sont apparus comme meilleurs représentants de leur famille :
 
• AAC-HE : Nero AAC 3.0.0.15 CBR 80 ‘high’
• AAC-LC : iTunes v4.9.0.17 / QuickTime 7.0.2 CBR 80
• Ogg Vorbis : aoTuV beta 4 VBR –q1
• WMA Standard : Serie 9.1, VBR Q25
 
Le débit légèrement plus élevé de Vorbis aoTuV beta 4 (85 kbps calculé avec pondération de la durée des échantillons) me contraint de légèrement réduire le paramétrage pour la finale, et de le rétrograder à –q0.9. Le débit obtenu sur le même mode de calcul tombe ainsi à 82 kbps.
 
Pour accroître la validité du test, j’ai décidé d’introduire deux référents, haut et bas (low anchor et high anchor), dont le but est d’éviter une notation exagérément flottante. En glissant parmi les concurrents un challenger de meilleur qualité (et de débit plus élevé que celui testé), on évite d’accorder une notation excessivement favorable au meilleur des participants réguliers. De la même manière, l’introduction d’un ‘intrus’ délibérément médiocre doit permettre d’accorder des notes outrageusement basses au(x) plus mauvais des participants. Le choix des anchors (littéralement « ancres », puisqu’elles permettent de circonscrire la plage utile de notation) a été effectué à des fins utiles :
 
• référent haut (high anchor) : j’ai décidé d’utiliser « le » mp3 à 128 kbps, puisqu’il est courant de comparer ce format à ce débit à ses rivaux plus efficient pour affirmer la similitude sinon la supériorité des ‘minots’. L’introduction du MP3 à ce débit permettra d’évaluer la pertinence de ces comparaisons. L’encodeur choisi est LAME 3.97 alpha 10 (codec MP3 le plus performant en sa version la plus aboutie qualitativement), utilisé en ABR avec la commande –abr 131 (le débit final est de 124 kbps pour le groupe 1 et 128 pour le groupe 2).
 
• référent bas (low anchor) : j’ai également opté pour le MP3, à 80 kbps. La raison est simple : ce format est jugé inapte à défier ses rivaux à des débits inférieurs à 100 kbps. C’est très certainement vrai : je ne connais personne s’étant montré satisfait par « du » MP3 à 80 kbps. Reste encore à établir si les formats rivaux font véritablement mieux… L’encodeur MP3 utilisé est le même que précédemment (3.97 alpha 10), utilisé avec la ligne de commande --abr 82 (78 & 80 kbps pour les deux groupes).
 
Récapitulatif des participants :
 
• AAC-HE, CBR  •  Groupe 1 : 76 kbps —— Groupe 2 : 78 kbps
• AAC-LC, CBR  •  Groupe 1 : 80 kbps —— Groupe 2 : 80 kbps
• MP3, ABR  •  Groupe 1 : 78 kbps —— Groupe 2 : 80 kbps
• Ogg Vorbis, VBR  •  Groupe 1 : 76 kbps —— Groupe 2 : 83 kbps
• WMA Std, VBR  •  Groupe 1 : 76 kbps —— Groupe 2 : 88 kbps
et, pour référence et hors compétition :
[• MP3, ABR]  •  Groupe 1 : 124 kbps —— Groupe 2 : 128 kbps
 
(débits obtenus avec foobar2000, avec donc pondération de la durée individuelle des échantillons )
 
L’écart entre le participant au débit le plus faible (AAC-HE, 77 kbps) et celui au débit le plus élevé (WMA VBR, 82 kbps) est donc de 7% environ ; enfin, l’écart entre le débit de tous les compétiteurs et le débit cible de 80 kbps étant contenu sous la barre des 3 kbps (+/- 4%), ce qui est insignifiant.
 
 
 
RESULTATS
 
 

 
 
COMMENTAIRES D’ENSEMBLE
 
Il existe de fortes disparités qualitatives à ce débit entre les différents outils de codage. Vorbis m’apparaît très largement plus performant que ses rivaux, alors que le WMA peine à se démarquer du MP3 à un débit pour lequel il n’a pourtant aucune prétention. L’AAC offre des résultats assez décevants, quel que soit le profil utilisé ; l’AAC-HE ne vient pas secourir aux limites de l’AAC-LC, et semble même grever ses performances générales. On notera qu’aucun des participants ne parvient à rivaliser avec le MP3 à 128 kbps, à l’exception peut-être de Vorbis dans le second groupe, qui se hisse à la cheville (au genou même) de l’aîné. Pour les autres, l’écart avec LAME à 128 kbps est tel qu’ils semblent évoluer dans deux univers qualitatifs distincts. C’est bon à savoir lorsqu’on souhaite dépenser un peu plus pour bénéficier un baladeur supportant d’autres formats que le MP3 : on ne doublera pas la capacité musicale de l’appareil, pas en maintenant la qualité en tous cas.
 
 
 
COMMENTAIRES FORMATS PAR FORMATS
 
 
• LAME (3.97a10) MP3 à 80 kbps : il n’y a pas grand-chose à commenter, dans la mesure où ce participant n’avait d’autre but que d’établir un référent négatif. On notera quand même qu’à cette fin il échoue partiellement, dans la mesure où il parvient à faire preuve d’un peu plus d’efficacité que l’un des véritables participants du test (WMA, groupe 1). La qualité demeure dans les deux cas assez basse. J’ai cependant été surpris de manière agréable par la qualité obtenue par certains encodages, loin d’être mauvais. Cela se produit avec certains échantillons qu’on peut qualifier de peu difficiles d’encodage – encore que ce peu de difficulté n’est pas nécessairement partagé par des rivaux théoriquement censés être plus à l’aise ! En gros, le MP3 à 80 kbps est à éviter (mais on s’en doutait), mais n’est pas si mauvais (relativement à la concurrence) qu’on pouvait de prime abord l’imaginer.
 
• AAC-HE (Nero, CBR 80 “high” : score très décevant pour ce successeur du MP3Pro, censé lui-même succéder au MP3… La faute à des artefacts déjà notés dans les 40 échantillons de la poule, et que l’on retrouve sur plus de 90% des 185 testés ici. Musique classique et musique variée souffrent pareillement de ces défaillances. L’AAC-HE ne souffre pas de lowpass, mais la technique qui permet de copieusement garnir le haut du spectre cause à l’évidence d’autres problèmes amplement plus irritants (à mes oreilles en tout cas). On notera également le manque total de finesse du profil HE, cause d’un grave pré-écho ou d’effacement de nombreux détails. Le débit de 80 kbps semble déjà être inutile au profil HE de l’AAC, qu’il semble préférable de réserver à des débits d’encodages moindre.  
 
• AAC-LC (iTunes, CBR 80) : résultats assez médiocres, conséquences de distorsions trop dérangeantes, bien que le résultat d’ensemble soit plus ‘propre’ que son voisin AAC-HE. Les encodages souffrent également de « pauvreté », liée à un lowpass assez perceptible, bien que moins gênant que celui noté avec le WMA ou le MP3 à 80 kbps. On notera une nouvelle fois la constance de l’encodeur d’iTunes, qui offre des performances similaires d’un groupe à l’autre (équilibre que n’atteint aucun des encodeurs AAC-LC de Nero).
 
• Vorbis (aoTuV beta 4, VBR –q 0,9) : la grosse claque de ce test. J’étais déjà interloqué par les performances du codec arrivé au terme de la première série de 150 échantillons de musique classique. Les 35 autres échantillons me laissent interdit… Voilà le seul outil qui permette d’atteindre une qualité décente à 80 kbps, et même véritablement satisfaisante sur de la musique variée. Ce constat doit cependant être nuancé : il ne s’agit nullement de qualité CD, ni même de qualité suffisante à une écoute posée, à domicile, dans son salon, mais simplement de performances adaptées à un environnement plus hostile. Il m’est cependant regrettable que les performances ne soient pas plus équilibrées entre les deux groupes (l’encodeur surclasse néanmoins tous ses rivaux jusque sur son point faible).
 
• Windows Media Audio (9.1 Standard, VBR Q25) : résultats médiocres sur toute la ligne (1.54 & 1.53). C’est d’ailleurs le seul encodeur à obtenir un score moindre au référent bas (groupe 1). WMA et MP3 semble donc faire parti de la même génération d’encodeurs, inapte au codage à faible débit. Il est intéressant de noter à ce titre que les deux encodages partagent le même lowpass (13 KHz environ), le plus faible de tous les participants. En raison de ses faibles performances, Le WMA gagnerait peut-être à être rééchantillonné à 32 KHz, comme c’est le cas pour LAME. Cela permettrait peut-être aux encodages WMA de limiter l’ampleur de certaines distorsions, qui sont la cause d’une notation moindre à celle du MP3 sur le premier groupe, et de creuser un peu plus par la même occasion l’écart par rapport au MP3 sur la musique variée tout en se rapprochant encore de l’AAC. Simple hypothèse bien entendu, mais que l’utilisateur pourra mettre en pratique grâce à certains logiciels pouvant opérer en pre-processing le rééchantillonnage désiré.
On peut également s’amuser à corréler ces résultats avec la formule markemathique  abondamment distillé dans les grandes surfaces et leur tracts explicatifs (WMA 64 = MP3 128, ou encore 150 chansons WMA contre 75 en MP3). On voit mal comment le WMA à 64 kbps pourrait doubler la contenance musicale d’un baladeur MP3, lorsque le MP3 se comporte presque aussi bien à 80 kbps que son rival à débit similaire. Presque aussi bien… voire peut-être nettement mieux : on se rappellera combien le WMA peinait à 80 kbps CBR sur les échantillons du premier groupe (poule No.5), et que le débit obtenu en VBR est ici de 88 kbps, contre 80 kbps pour le MP3… Au mieux, le WMA à 64 kbps pourra rivaliser avec le MP3 à 80 kbps. Mieux vaut y songer avant que d’acheter un baladeur compatible WMA pour cette seule raison.
 
 
 
• LAME (3.97a10) MP3 à 128 kbps : Le référent haut a cette fois pleinement joué son rôle : la qualité de sortie de LAME est supérieure à celle de formats prétendant à la même qualité à débit moindre. Elle semble même être hors d’atteinte pour des formats comme l’AAC et le WMA ; seul vorbis pourrait éventuellement présenter une efficience de 40% supérieure au MP3 (80 <-> 128), mais pour y arriver, l’encodeur devrait encore singulièrement progresser pour affronter toutes les situations de codage (notamment celles, variées, offertes par la musique classique). Pour conclure, il est intéressant de signaler l’identité de performances de LAME 3.97 sur les échantillons des deux groupes. L’encodeur, du moins en ABR, est particulièrement bien équilibré, à même d’affronter une large variété de musique.
 
 
 
ET POUR FINIR…
 
Les plus exigeants s’interrogeront sur l’utilité d’un tel test ou de l’emploi d’un débit aussi dérisoire que 80 kbps. La remise en question est légitime, du moins pour un certain usage de la compression avec perte. Mais il ne s’agissait nullement de viser la transparence perceptuelle, et d’atteindre une qualité pouvant être confondue avec celle de l’original. La valeur de 128 kbps a pendant des années servi de référence (bonne ou mauvaise, là n’est pas le problème), notamment lorsque le MP3 était seul en lice. Avec l’arrivée et surtout le développement de formats plus efficients, il devient envisageable d’abaisser avec sérieux ce plancher. Loin des affabulations aussi caricaturales qu’optimistes propagées par la confrérie des marchands et des labos, on peut affirmer que les progrès en matière d’encodage avec perte ne permettent absolument pas d’atteindre les gains en efficience proclamés, et qu’on ne peut avec sérieux envisager de diviser par deux le débit sans dramatiquement porter atteinte à la qualité finale. Mais certains outils se démarquent nettement de leurs rivaux. C’est le cas de Vorbis, qui se montre d’ores et déjà capable de réaliser un travail admirable à 60% à peine du débit nécessaire au MP3– certes inférieur au MP3 à 128 kbps, mais on n’oubliera pas que ce MP3 à 128 kbps n’est pas non plus « le » MP3 à 128 kbps de ces dernières années, et qu’il représente plutôt une forme d’aboutissement d’une aventure commencée quinze ans plutôt.

En vrac, compte tenu de l'heure :  
 
• Un tableau des débits est disponible :  

 
• Des courbes de distribution des débits pour les deux encodages VBR sont également accessibles :  
- WMA Standard
- Vorbis aoTuV
 
• Les échantillons classiques sont disponibles :
ici, ici et là
 
• Les rapports ABC/HR :  
http://audiotests.free.fr/tests/2005.07/80/ABC/

Merci bien. Plein de choses à analyser et à interpreter...

Impressionnant tout ça...  
 
 
 
Guru, si ça t'intéresses de compléter la partie AAC-HE avec le codec de Real/Helix (pas trop d'améliorations depuis les derniers tests de Roberto à vrai dire), j'ai créé une petite appli qui encapsule directement le flux AAC (LC ou HE) dans un m4a. C'est parce que j'avais commencé à faire quelques blind tests perso et j'aimais pas trop le conteneur/lecteur de Real... donc j'ai développé ça. Si ça te dis, je ferais un package pour le mettre en ligne.
 
Encore Merci pour ces tests.    

Merci pour ce test.
 
Mais j'aurais cru que AAC s'en sortirai mieux.

Bon test, chapeau bas a l'éffort
 
En conclusion : "Vive le libre, vive la gratuit, vive Vorbis !"

*Ce test représente de manière évidente un énorme travail
 
*Voici des estimations de capacités intrinsèques des formatsà ce débit, en considérant le mp3 comme ayant une efficacité de 100%:
mp3: 100
aac-lc: 180
vorbis: 180
wma std: 130
he-aac: je ne connais pas assez le sbr pour estimer correctement son efficacité
 
*je pense que l'on doit pouvoir améliorer les résultats de Lame de 20% maximum à ce débit
 
*je ne suis pas sûr que les encodeurs mp3 FhG soient réellement supérieurs à Lame à ce débit, même si cela semble être une croyance populaire.
 
*wma, compte tenu de ses capacités, ne s'en sort assez bien
 
*Les résultats de l'aac proviennent peut-être du fait que ce soient des encodeurs commerciaux. Tant qu'ils restent les meilleurs encodeurs aac, il n'y a pas vraiment besoin de chercher par tous les moyens à les améliorer (surtout que plus un encodeur est abouti, plus il faut de temps pour l'améliorer). Lame, par exemple, relève franchement de l'acharnement thérapeuthique.
 
*Si il fallait parier sur un vainqueur pour le futur (en prenant en compte les considérations commerciales), je parierais sur l'aac.
 
*Les tunings aoTuV sont vraiment impressionnants. Ils rejoignent mpc au rang des modèles psychoacoustiques et paramétrages les plus épatants. Arriver à ce niveau qualitatif (proche à mon avis des limites du format) sur un format d'encodage aussi jeune est vraiment une performance.
 
*Je remarque que l'encodeur aac-lc de Nero donne de meilleurs résultats en classique. Serait-il possible que tu en sois la cause, en ayant reporté des résultats de tests classiques aux développeurs Nero aac par le passé?

Je ne peux m'empêcher de commenter ceci:
*Vorbis doit ses excellents résultats pour partie au travail d'une seule personne, qui aurait pu effectuer le même travail sans considérations propagandistes.
 
*"libre", dans le cas de Vorbis, reste un peu à définir....
 
(c'était pour ajouter mon grain de sel)

 
Il me semble que le codec Ogg est sous license GPL nan ? D'où le terme "libre" que j'ai employé... jme suis ptete trompé ?  

 
Dire que ce n'est qu'un élément d'un projet plus étendu...
 

Je ne pense pas non plus. D'ailleurs, il me semble que par défaut le lowpass des derniers encodeurs Fhg soit largement plus bas, ce qui les bride assez nettement. Je pense sincèrement que cette idée est fondée... sur une réalité vieille de 4 à 5 ans. Tout le monde la répète depuis, sans même chercher à évaluer les progrès réalisés depuis. Enfin c'est devenu une habitude sur certains forums    
 

Mais est-on sûr qu'il dispose d'un meilleur potentiel ?
 

 
Il serait dommage que les limites soient déjà atteinte. J'en veux davantage, moi !
 

 
Non, pas vraiment (très peu en réalité). L'encodeur testé ici est celui que les développeurs préfèrent ne pas voir être (encore) utilisé. En raison parait-il de problèmes (il y en a en effet) jugés plus importants que ceux dont souffre l'encodeur actuellement utilisé par défaut. A mon avis, c'est une erreur. L'encodeur 'high' a de sérieux problèmes qualitatifs, et ce depuis des années. Problèmes constamment minimisés. Percevrai-je des problèmes pour lesquels d'autres seraient moins sensibles ? Ou ne serait-on pas plutôt sourd aux doléances de certains utilisateurs critiques du côté de l'Allemagne ? Enfin, qu'importe : c'est à l'utilisateur final de jauger la qualité respective des encodeurs.

 
Yeahhh... parmi les plus mauvaises solutions d'encodage à ce débit on trouve notamment faac (open, libre et gratuit) et lame (open, libre et gratuit).
 
Moi je dis vive le Japon-pon-pon ! Aoyumi, Nyaochi et Takehiro powaaa !

 
Euh dans ma citation je faisait juste l'éloge du Vorbis, pas des autres codec quand je disais "vive le libre, vive le gratuit,..."
 
Lame est libre et gratuit mais lame n'est qu'une interface, le codec que lameMP3 utilise est le MP3, or ce codec n'est pas libre et même payant puisqu'il est l'oeuvre de l'institut Frauhnofer si je ne me trompe pas, alors que le OGG Vorbis lui est libre...

Je crois que c'est l'inverse, Lame est un codec, et l'Ogg n'est pas un codec (mais le Vorbis, oui).

MP3, Vorbis, AAC : formats audio (un ensemble de règles, d'outils...).
 
Lame, iTunes AAC, Vorbis aoTuV ou Vorbis 1.1.1 : encodeurs audio (implémentations particulières des règles qui définissent le format).
 
MP4, WMA, OGG : conteneurs multimédias, qui peuvent englober des encodages de divers formats obtenus avec n'importe quel encodeur.
 
 
swoosh2002> lame n'est donc pas une interface, mais un encodeur à part entière. Par contre, cet encodeur est une réalisation ouverte et libre d'un format qui lui est ouvert mais pas libre (puisque protégés par des droits dont il faut s'aquitter).
 
Vorbis est théoriquement libre, ouvert et gratuit, mais on peut raisonnablement penser que le formats utilise frauduleusement des techniques brevetées.

C'est triste mais c'est vrai.  
C'est un peu comme si on venait m'arrêter chez moi parce que je viens de publier un message commençant par "c'est triste mais c'est vrai", alors que cette phrase est brevetée.

C'est un peu limite comme argument. Les techniques qui font l'objet de brevets résultent de travaux généralement poussés, et ne sont pas de simples jets de l'esprit. Si tu composes un poème, tu peux le protéger intellectuellement, et c'est tout à fait légitime. Il s'agit d'une création travaillée. Par contre, "c'est triste m'est c'est vrai" ne peut prétendre au même statut.
 
Des personnes ont été payées par des labos pour développer un maximum d'outils de codage ; ces personnes sont payés des laboratoires ou des sociétés qui trouvent pour principale source de financement l'innovation et la commercialisation de ces dernières. Si ces travaux n'étaient pas protégés (donc non-payants), pas de financement, pas de société, pas de salarés, et au final très peu d'étudiants (qui constituent le moteur principal de l'open-source), et donc peu d'avancées.
 
Le MP3 n'est pas une invention de hacker ; c'est un produit tout droit financé par une entreprise qui espérait bien un jour en tirer profit. La protection me semble tout à fait légitime. Ce qui est discutable, c'est la protection à tout va de tout et n'importe quoi qui à trait au logiciel (le double click, le tag, le lien hypertexte). Or le MP3 n'est pas protégé en Europe par ce type de législation.

Disons que dans le cas de Vorbis, on peut raisonablement se poser des questions (chose déjà faite), et on pourrait espérer obtenir un minimum de réponses (chose présentant un degré d'avancement proche de 0).
 
Pio2001: attention à ne pas confondre copyright (droit d'auteur) et brevet (droit d'invention).
 
Mais bon, on s'éloigne du sujet (je sais, c'est de ma faute), et si on continue il va bientôt faloir expliquer ce qu'est un copyright, ce qu'est un brevet, ce qu'est un brevet logiciel et ce qu'est un brevet sur un procédé.

Moi je trouve qu'une technique de codage (et faut voir ce que Thomson a breveté !), c'est le fruit d'une recherche intellectuelle cohérente, au même titre qu'une méthode scientifique.  
Or, les découvertes scientifiques ne sont pas brevetées. Mais il faut dire que la recherche scientifique est financée par le gouvernement.
Ce qui me gène, c'est que n'importe qui peut retrouver par hasard les méthodes brevetées. Tout développeur est donc potentiellement dans l'illégalité. Je trouve ça aberrant. J'ai l'impression qu'il est interdit de réfléchir, parce qu'on peut aboutir à des idées brevetées ! C'est la négation de la recherche scientifique, si on considère l'informatique comme une science.

Il n'est pas interdit de réfléchir, mais par contre l'exploitation commerciale (ou celle non-commerciale pouvant porter préjudice à l'exploitation marchande) d'une idée trouvée par d'autres et brevetée l'est. Au moins le temps de la validité du brevet (qui n'est pas excessivement longue il me semble dans le cas présent).
 
Bien entendu, tu es en droit de le déplorer. La question est de savoir si la protection des "idées" favorise réellement leur dévelopement. Une chose est certaine : si le XXème siècle a connu une explosion dans le domaine de la recherche c'est surtout en raison de considérations mercantiles (et aussi militaire, encore que les deux soient voisins).

Comment ai-ke pu ne pas drapaliser un topic aussi intéressant... Un grand bravo/merci à guru je prendrai le temps de prendre connaissance de ton test en profondeur dès que je serai rentré de vacances...

 
Coucou aussi à PIO et Gabriel...
 
Au passage je ne dis pas ca dans un mauvais esprit mais je pense que la discussion sur els brevets/l'open source etc est intéressante mais pas forcément à sa place ici... Très honnetment il me semble que cela vaudrait le coupd'ouvrir un topic dédié, que le smodo surveilleraient sans doute attentivement...
 

Finalement j'ai lu ton sujet dans la foulée Guru... En effet cela a du représenter une charge de travail colossale!!! Tu as bien mérité des vacances...
 
Je formulerai cependant une légère critique: pourquoi n'avoir pas aussi pris en compte le MPC à 80kbps? Après tout ce format a pour avantage tt comme Vorbis de ne pas etre représenté par 150 encodeurs... Bien sur tu aurais au moins du tester deux versions (la 1.11 et la 1.15) étant donné la découverte que tu as fait récemment dans des circonstances regrettables... Mais ca ne réprésentait pas plus de travail que pour Vorbis...
 
Evidemment le MPC n'a pas de support hardware pour le moment mais ca devrait venir... (ce qui est sur c'ets que je n'attends les developpeurs du MPC pour esperer l'optimisation temps réelle du codec MPC de Rockbox)
 
Je me doute qu'après l'accueil reçu par tes tests du coté des dev MPC, il faut une bonne dose d'abnégation pour consentir à inclure le codec dans ce test... Enfin ne prends pas cela comme du dénigrement Guru très sincèrement... Ton test force le respect je trouve simplement un peu dommage qu'une bete histoire contingente porte atteinte à sa méritoire exhaustivité...
 
PS: Hum pour ce qui est de Wavpack en lossy d'après ce que j'ai pu comprendre il ne ferait pas vraiment le poids (l'interet residant plutot dans la combinaison hybride)... La lacune me semblerait donc moins dommageable et je ne pense pas que David Bryant en prendrait ombrage...

 
mouais, je voudrais pas paraitre réactionnaire mais vu comme la fondation xiph est sensible à ce problème (cf le codec theora pour lequel ils ont négocié des droits d'utilisation sans limite) et vu que le code est ouvert et pas énorme, je doute fort que leur procédé tombe sous le coup d'un brevet, il aurait déjà été remarqué. Donc à moins que tu ais des preuves ou au moins des indices forts, pourrais tu éviter ce genre de remarque.  
 
Merci et bravo pour le comparatif

http://www.hydrogenaudio.org/forum [...] opic=13531
 
Les indices "forts" y figurent, avec le numéro de code des brevets incriminés.
 
 
P.S. La prochaine fois, commence par demander des preuves et réserve ta leçon de morale uniquement en cas de réponse négative ou d'absence de réponses.

Tang>
 

• Le MPC à 80 kbps est... mieux vaut que tu essaies. Le format n'est pas armé pour ces débits, et se plante. Je l'aurais testé que les critiques auraient aussitôt fusées. Cela aurait été une perte de temps. Si tu veux t'amuser, essaie d'encoder quelques fichiers en MPC à 80 kbps environ (cela doit correspondre à --quality 2, un truc du genre) : cela te convaincra ss doute mieux que tout discours.

• Quant à WavPack lossy, son absence n'est pas le signe d'une lacune, mais la conséquence de l'impossibilité à encoder à moins de 196 kbps. J'avais fixé une tolérence dans les écarts de débit de 10%, et j'aurais été contraint de la pousser un peu (juste 130%...) pour accueiller WavPack Je doute que Bryant puisse m'en vouloir

 
leçon de morale vs FUD à voir. En tout cas, aucun des intervenants de la discussion n'est capable de dire si vorbis enfreint les brevets cités, et en tout état de cause, il n'y a toujours pas de plaintes contre xiph pour ce codec.

D'où mon "on peut raisonnablement penser..." plus haut.
L'absence de plainte ne signifie pas absence de faute. Vu la puissance financière de XIPH, je serais le détenteur de brevet que j'hésiterais avant de me lancer dans de coûteuses poursuites.

Ah decidement j'étais à coté sur toute la ligne... Pour le MPC je dois dire que je pensais aux on dit qui donnaient MPC a ch*er à 128kbps ce qu'un test ABX avait largement battu en brèche... Je pensais qu'il en était de meme à des débits moindre comme 80kbps...
 
Concernant WV là pour le coup j'aurai du me documenter avant de l'ouvrir...
 

 
PS: je barre mon post...

Superbe test !
tu as du y passer un temps fou !
Tes explications et tes syntheses sont facilement lisibles et tres bien rédigés, chapeau ...
Ptite question, ces tests ne sont en rien représentatifs pour un plus haut bitrate ?
Car le wma me paraissait pas mal comme codec (en 192kbps)

Tout dépend à quel niveau tu définies "plus haut bitrate"... Mais l'extrapolation pour des débits supérieurs n'est pas recommandée ici. C'est bien précisé "Tests @80 kbps" et pas autres choses. Je sais que Guru a dans la tête de réaliser d'autres tests à des débits plus élevés, encore faut-il qu'il ait le temps et la motivation...Il pourra t'en dire plus je pense.
 
 
 
 
@Guru : pas de possibilité de faire du RealAudio AAC @80 kbps pour l'instant...j'ai vérifié.
 

merci bien, je reviendrais voir s'il n'y a pas un test a bitrate plus élevé, c'est vrai que je ne me sert pas du 80kbps.
En tout cas, je le redis, jolis travail guruboolezz

J'en suis actuellement aux poules du test à 96 kbps. La poule dédiée au mp3 est déjà achevée et rendue publique, ici.
Real AAC figurera dans ce test (merci encore Kurnoise). Il me faudra encore quelques jours pour finir l'intégralité du test.
En août, j'attaque le test de 128 kbps. Pour les débits supérieurs, rien n'est prévu.
 
Dual_Shock> n'extrapole pas. Le roi du sprint a des chances d'être un tocard en demi-fond ; idem en compression.

J'ai bouclé l'ensemble des poules du test à 96 kbps. Je rendrais public les résultats une fois la finale achevé. J'ai d'ores et déjà testé 12 échantillons (x6 codecs, soient 72 comparaisons), ce qui représente moins de 7% du volume total...
Figurent dans ce test à 96 kbps :  
- AAC (meilleur de 6 encodeurs testés en poules)
- MP3 (meilleur de 5 encodeurs)
- Vorbis (vainqueur entre aoTuV vs 1.1.1 : quel suspense...)
- WMA (meilleur entre CBR 96 et VBR 50)
- MPC (inclus sans poule, version 1.14 --quality 3 : débit moyen de 100 kbps)
+ MP3 à 128 kbps en guise de référent haut.
 
A noter que j'ai préféré tester LANCER (l'encodeur vorbis optimisé SSE et 50% plus rapide) plutôt que les autres compiles. Et puis avec le MPC, Tang aura son comparatif (et peut-être l'illustration des reproches amers que je redoute: [I]mon dieu, tester le mpc à ce débit c'est insensé![/I])

Je sens déjà la blague : "Wow, mpc -q3, that's Insane ! "

J'ai retrouvé les vieilles discussions tenues autour de "thumb" sur HA.org à l'époque où d'aucuns croyaient ferme que le MPC devait s'imposer en tout (j'en faisais parti), et dans lesquelles ont peu lire que le MPC à 64 kbps est loin d'être mauvais, qui dépasse même l'aac, etc...
Tape "thumb" dans HA : ca doit être le plus ancien message de la liste (fin 2002).

J'ai rendu consultable des résultats intermédiaires sur le blog que je viens de créer aujourd'hui :
 
http://guruboolez.blogspot.com/

Il y avait plus ancien. Le lien est le suivant :  
http://www.hydrogenaudio.org/forum [...] c=4466&hl=

Tout le monde s'en fout, mais bon...
http://guruboolez.blogspot.com/200 [...] 00_28.html
 
J'ai ajouté ici les résultats d'un deuxième ensemble d'échantillons. Les différences d'avec le premier sous-groupe sont assez marquées, et LAME vers 128 kbps manque de souffle pour tenir à distance certains rivaux à 96 kbps.