Salut, en voyant la nouvelle version 3.98b6 de LAME, une soudaine envie de refaire un comparatif des codecs entre eux m'a pris !!!
J'ai récupéré toutes les versions de codec que j'ai pu (plus d'une 20ène lol), mais après test de chacun, il n'y a qu'à partir de la version 3.90 que les options de commandes que nous connaissons jusque sur les dernières versions fonctionnent.

Donc voilà, est-ce que ça vous intéresse ce genre de comparatif ? Ou est-ce que ce n'est pas la peine que je prenne du temps pour le faire ?

Pour info, voici la liste des codecs que je peux comparer :

LAME 3.90.1
LAME 3.90
LAME 3.91
LAME 3.92
LAME 3.93.1
LAME 3.94
LAME 3.95
LAME 3.95.1
LAME 3.93
LAME 3.96
LAME 3.97
LAME 3.98b5
LAME 3.98b6
LAME 4.0a14

Ce serait super intéressant... Le truc serait aussi de faire le comparo sur plusieurs extraits variés, je pense (je suis pas trop connaisseur dans ce domaine).
J'en avais trouvé plusieurs, naguère, sur http://lame.sourceforge.net/quality.php
Mais bon, comme je ne sais pas trop comment on fait ce genre de test... --;

moi j'aimerais savoir si les versions beta comme la dernière 3.98b6 sont meilleures que les normales (3.97^^) donc oui ça m'interesse

OK ça marche, je ferai ça dans la semaine, d'ici ce WE je pense queje posterai.
J'en profiterai pour faire un comparatif des bitrates avec la version que j'aurai choisie.

Si ton test reprend le protocole employé ici, tu ne feras que mesurer la valeur du filtre passe-bas indiqué par le développeur. Ce qui est sans grande utilité. Un encodage ne procède pas par suppression/maintien des informations (donc avec pour seule disparition la partie manquante dans le haut du spectre) mais plutôt par codage/suppression. Autrement dit, disparaissent outre les hautes-fréquences l'ensemble des informations du fichier original. Ce qui signifie que la partie colorée de tes représentations spectrales sont entièrement différentes de celle du fichier original. Différentes mais très proches. Cette différence se nomme erreur de quantification.
Ainsi, lorsqu'un fichier est mauvais à l'écoute, ce n'est pas forcément parce que les hautes fréquences sont manquantes mais souvent parce que celles qui sont présentes et “maintenues” (codées) présentent trop d'erreurs. Et plus un encodeur gaspille bits à coder des hautes fréquences (faiblement audibles), moins il en dispose pour réduire les erreurs dans la partie du spectre la plus significative. L'important pour un développeur est donc de trouver un bon compromis, et certainement pas de coder des fréquences entre 0 et 22100 Hz en massacrant ainsi tout le signal.

C'est pour cette raison que les protocoles d'évaluation des codecs reposent tous sur des tests en aveugle. Un des protocoles les plus couramment utilisé est celui de l'ITU-R BS.1116-1. Un exemple récent a été publié par l'EBU (l'Union Européenne de radio-TV, autrement dit un beau paquet de professionnels):
http://www.ebu.ch/CMSimages/en/tec_doc_t33..._tcm6-53801.pdf

Un test de plusieurs versions de LAME devrait ressembler à cela.

C'est un très gros travail, en rien comparable à une gallerie obtenue avec CoolEdit.

J'espère que cela t'évitera cette semaine d'effectuer un travail qui n'a aucune portée pratique. Amicalement

Effectivement, tout cela semble bien complexe (je m'interroge toujours sur la signification des valeurs représentées sur le graphique du test de hydrogenaudio, ça manque de légende ).
Tant pis, pour ma part j'ai toujours des raisons de penser que la version 3.93.1 est la meilleure ^^.


EDIT : cela dit le test que je proposais permettait également de mettre en évidence les modifications spectrales en dessous du seuil du filtre passe-bas, et ce de façon factuelle et non subjective.

Les valeurs dans le tableau correspondent aux notes (située entre 1 et 5) obtenue par chaque encodeur (3 sont testés) et pour chacun des échantillons (le testeur en a utilisé 150 !). Les notes sont données en aveugle, grace à un logiciel de type ABX (le testeur ne peut savoir ce qu'il est en train de noter). Le processus est répété pour chaque échantillon.

Les graphiques situés sur la droite et en fin de tableaux représentent simplement les notes moyennes pour un ensemble d'échantillons. Au lieu de simple points on y trouve des barres verticales, qui représentent l'intervalle de confiance que l'on peut accorder à chacune des moyennes. Par exemple, un encodeur qui obtient une note de 3,80 ne peut être considéré comme statistiquement meilleur qu'un encodeur dont la note est de 3,50 que si les barres ne se croisent pas. C'est un peu étrange mais facile à comprendre. Admettons que tu testes 2 encodeurs (A et B) sur 10 fichiers. Sur les 9 premiers, A obtient à chaque fois une note de 4,0 et B une note de 3,9. Mais sur le dernier échantillon, A obtient un 2 et B un 4.
Moyenne : A = (4x9+2)/10 = 3.8
Moyenne : B = (3,9x9+4)/10 = 3,91
Arithmétiquement, B est supérieur à A. Or, cette supériorité n'est du qu'à un échantillon particulièrement défavorable à A. Si on l'enlève, ou si on y substitue un autre, A redevient > B. D'où ce problème : peut-on réellement dire que B est > A quand bien même dans 90% des cas A>B ? D'où l'importance de ces intervalles de confiance, car ils permettent d'établir le degré de confiance que l'on peut accorder au verdict ferme d'une simple moyenne arithmétique.


Pour la supériorité de 3.93.1, qui a 5 ans d'âge, tu es libre de le penser. Mais t'es-tu déjà demandé pourquoi les développeurs de LAME ont publié depuis plus d'une centaine de versions alphas, betas et stables si c'était pour faire moins bien ? Pourquoi des dizaines de testeurs ont contribué à l'évolution de LAME à l'aide de tests d'écoute ABX particulièrement fastidieux si la simple lecture d'une représentation 2D spectrale permettait en 3 secondes de mesurer progrès et regression ?
De deux choses l'une : où ces personnes sont particulièrement ignorantes et inefficaces, ou alors c'est ta propre méthode qui n'est pas adaptée à l'objectif fixé.



Non, pas vraiment. Si tu voulais vraiment illustrer ces changement, il te faudrait un écran d'une résolution de 10000 pixels de haut sur 30000 de large afin de représenter le détail de ces changements. Les captures que tu as posté sont des visions globales où 1 pixel représente plus de 100 ou 1000 bits audio (le calcul est facile à faire).
Cela revient à regarder la photo d'une ville sous GoogleEarth et a en déduire que tous les toulousains ont le même aspect parce que la photo les présente ainsi.


EDIT:
nombre de bits audio pour un morceau de 4 minutes :
44100x2x16x240 = 338.688.000
nombre de pixels (1024x768)
1024x768 = 786432
RATIO = 430
En réalité, il faudrait diviser cette valeur par la résolution en bit de l'échantillonnage graphique de l'affichage de ces logiciels d'analyse mais le multiplier à nouveau en raison des approximations liées au mode de calcul. Au final, la conclusion reste sans appel : un pixel sur un graphique de ce genre se doit de représenter plusieurs centaines d'échantillons - d'où l'impossibilité d'y mesurer les différences entre un fichier original et son équivalent MP3.

En tout cas, je vois mal un programmeur, une personne qui aime la logique, l'algorithmique, les protocoles etc, tester se qu'il fait à son humeur.
C'est comme de dire que parceque l'on préfère la fraise à la banane, la fraise c'est mieux....

Avec une analyse spectrale à haute résolution, sur l'introduction de Lacrimosa de Mozart on voit par exemple clairement que le code 3.98b6 est moins fidèle à l'original que le code 3.93.1. C'est, c'est factuel, ça ne dépend pas de mes capacités auditives qui seront de toute façon toujours douteuses puisque subjectives, ni de mon humeur dont dépend la majorité de mes sens, et qui varie d'un jour à l'autre.

Bref, je ferai tout de même ce test, afin d'expliquer ma position sur le sujet lol !

En tout cas merci pour ton intervention, cela me permet de remettre en cause et de me faire réfléchir une nouvelle fois sur le sujet !

Disons qu'un développeur de codecs audio connait parfaitement les processus mathématiques à l'œuvre dans une opération de codage et il sait donc pourquoi il est au mieux vain et de manière plus générale trompeur de vouloir évaluer un encodeur sur la base d'une capture d'écran
Sois logique à ton tour : ne penses-tu pas qu'un développeur, passionné de logique et pro en algorithmique soit suffisemment compétent pour ouvrir un fichier sur Audacity ou CoolEdit et cliquer sur "show spectral analysis" ? Pourquoi dans ces conditions là ces personnes publieraient-elles des encodeurs dont la représentation graphique est moins flatteuse que la version précédente ?

L'« humeur » n'a rien à voir ici : il s'agit de perception, dont le caractère subjectif peut-être éludé par le protocole décrit plus haut (scénario pluri-testeurs).




Et pourtant c'est ainsi. Et pas seulement en audio mais aussi dans des domaines dont l'enjeu se chiffrent en centaines de millions d'euros. Par exemple, la bouffe.
Prenons deux groupes agro-alimentaires en concurrence, qui cherchent tous deux à améliorer la saveur de leurs produits et ainsi gagner des parts de marché. Pour déterminer ce qui est bon, mauvais et toutes les nuances intermédiaires, nos deux PDG ont le choix entre deux méthodes : la méthode « subjective » et la méthode « objective ».

ENTREPRISE A: notre PDG « A » est un malin. Un finaud à qui on la fait pas. Il s'y connait un peu en philo et en science, et, technophile avéré, il sait pertinemment que les tests subjectifs, on peut leur faire dire n'importe quoi et que la santé de son entreprise ne va pas être compromise par l'humeur changeante de ses testeurs, qui d'ailleurs sont pas toujours d'accord entre eux. Il décide donc de faire appel à la haute technologie logicielle : une jolie modélisation informatique des saveurs qui permet grace à un olfactoscanner branché en USB sur photoshop de savoir exactement quel parfum est le meilleur. Là, le résultat est objectif et ne change pas au gré de la météo. Au grand étonnement des experts mais pas du PDG de génie, c'est le yaourth parfumé au vinaigre avec morceaux d'ail qui obtient les meilleurs scores, loin devant ceux parfumés à la banane et à la fraise. Bilan : la boîte coule (à la grande surprise du PDG mais plus de celle des experts).

Entreprise B: le PDG (qu'on sait déjà victorieux) est plus pragmatique. Il est l'homme de la sentence immortelle : « nous utiliserons l'informatique pour tester la qualité de nos produits le jour où nous vendront nos yaourth aux PC ». Le secret de la réussite de cet homme vient de ce qu'il a su comprendre l'importance d'un protocole de test valide. « Il ne faut pas dénigrer le subjectif dans nos tests puisque c'est précisement au subjectif que l'on s'adresse » disait encore notre homme, dévoilant ici les clés de sa réussite. En effet, des hommes préfèrent le yaourth aux olives à celui à la papaye, mais plutôt que de conclure de manière désabusé que tout est relatif cherchons à savoir quel est l'avis de la majorité. Et miracle, la subjectivité apparait beaucoup moins fluctuante qu'on le croyait et s'il est vrai que les goûts et les couleurs ne se discutent pas, il n'est pas moins vrai que certains sont beaucoup plus communs que d'autres. Bilan (mais on le savait déjà après l'annonce de la déconfiture de la boite A): entreprise B victorieuse.


Les encodeurs audio, c'est pareil. S'ils évoluent et progressent réellement, alors une majorité d'utilisateurs saurait en apprécier les progrès et l'on peut sans crainte de chaos faire appel à des tests subjectifs. Corollaire: si une majorité de testeurs d'un test pluri-utilisateurs conclu à la supériorité d'un encodeur sur un autre, c'est que ce codec est meilleur - quand bien même le logiciel d'analyse va prétendre le contraire. L'analyse logicielle serait bien entendue plus commode car infiniement facile à mettre en œuvre pour les développeurs, mais elle n'a jamais donnée de résultats fiables et encore moins pertinents (si tu veux des vrais logiciels développé à cette fin, va voir du côté de PEAQ ou EAQUAL). Ce n'est pas pour rien que des protocoles aussi rigoureux que fastidieux comme celui de l'ITU mentionné plus haut sont utilisés un peu partout. Mais le jour où des méthodes d'analyses objectives fiables seront mises au point, alors leur emploi sera parfaitement valide (et économique surtout) et tu pourras publier des tests comme bon te semble.





Ben non, la seule chose que tu vois, ce sont les pixels manquants. Quant aux autres, ils ne sont pas identiques et tes yeux ne sont pas capables de discerner les subtiles nuances qui séparent ceux que tu crois être identiques, à moins de faire une soustraction sous photoshop. Sans oublier que le meilleur n'est pas nécessairement celui qui présente le moins de pertes mais celui qui aura su distribuer les erreurs de quantifications dans les parties les moins audibles du spectre. Si l'on appelle le MP3 (et le WMA, l'AAC, Vorbis...) des encodeurs perceptuels, c'est précisement parce qu'ils décorellent le degré de la perte (ou erreur) de l'impact de cette même perte, et ce grâce à des modèles psychoacoustiques élaborés.
Bref, dans tous les cas de figure, la « méthode objective » ne parvient pas à rendre compte de la qualité de sortie et est par conséquent inadaptée comme méthode d'évaluation qualitative d'encodeurs perceptuels.




Tu perds ton temps et plus grave tu vas induire en erreur des lecteurs.
Avant de faire ton test, commence par demander aux dévelppeurs de LAME s'ils sont intéressés par ton protocole (ils cherchent constamment des testeurs et des retours d'utilisateurs, donc ils acceuilleront ta demande d'aide favorablement). Tu verras, leur réponse ne diffèrera-pas de la mienne, j'en suis certain.

Tu trouveras l'adresse d'un développeur français de LAME sur sa page perso:
http://www.mp3-tech.org/

Il va de soi que pour effectuer mes tests je calcule des images de différence, et je modifie la dynamique afin de recadrer les différentiels d'intensité en 32bits (interpolation linéaire). Et je n'utilise pas un logiciel comme CoolEdit, mais un logiciel spécialisé dans l'analyse spectrale qui s'appelle Spectrogram (version 15).

Je comprends que la distribution des erreurs est un facteurs clé dans l'appréhension du principe de fonctionnement du codec, cela étant dit, il n'en demeure pas moi que sur Lacrimosa (pour rester sur cette exemple) le 3.93.1 offre moins de différences que le 3.98b6.
En partant du principe que toute version supérieure du codec est nécessairement supérieure en qualité, de par la motivation qui a conduit à sa conception, une question persiste donc : comment une augmentation de l'écart entre le signal d'origine et le signal encodé, qui se manifeste directement par une variation spatio-temporelle du signal (en intensité, dB, et en fréquence, Hz), peut-elle tout de même conduire à une augementation de la fidelité ?

Enfin, pourquoi n'utilise-t-on pas uniquement l'oreille de testeurs pour vérifer la neutralité d'un casque ? Pourquoi nous basons-nous sur des spectres de réponses acquis avec des dispositifs microphoniques étudiés pour représenter au mieux le relief du crâne humain ?
Enfin, pourquoi, si nous sommes capables d'établir des modèles psychoacoustiques permettant d'écarter d'un signal toute information (quelle soit spatiale ou temporelle) non perçue (ou de manière infinitésimale) par l'oreille humaine, nous ne sommes pas capables d'établir des modèles psychoacoustiques qui vérifient le bon travail de nos précédents modèles ?

Je précise que je ne cherche plus à démontrer quoi que ce soit, je pose réellement ces questions !

Je rappelle que ce que tu vois sur ton écran est une image très largement imparfaite où un pixel, au lieu de représenter un échantillon, en représente plusieurs centaines. Dès lors, tu ne peux même pas voir comment sont distribuées les erreurs au sein d'un même pixel. Ensuite, la nature perceptuelle des encodeurs que tu testes rend caduque la validité de toute appréciation linéaire du volume des erreurs situées dans un fichier. En d'autres termes et pour être plus clair, un fichier peut compter 2.000 erreurs [chiffres fantaisistes] et sonner plus mal qu'un fichier qui en compte 20.000. Un encodeur “intelligent”, autrement dit bien programmé, est capable de distribuer les erreurs de quantifications dans les parties les moins audibles du signal (masquage). L'encodeur “crétin” (celui qui n'est pas développé) est celui qui ne dispose d'aucun modèle psycho-acoustique et qui en conséquence va chercher à maintenir le même degré de fidélité un peu partout.
Analyse spectralement ces deux encodeurs : celui qui présentera le moins de disparités apparaîtra visuellement comme le meilleur mais une écoute permettra de mettre en évidence le caractère obvie de ces erreurs et donc son infériorité qualitative.



Parce qu'un casque ne fait pas appel à des algorithmes psycho-acoustiques. Et c'est en dernier lieu l'écoute qui valide le jugement - le graphique servant surtout à illustrer le propos du testeur.


Je ne vois pas le rapport ou du moins ne saisi pas à quoi tu fais allusion.


Regarde du côté des logiciels mentionnés plus haut (PEAQ est le plus célèbre).
Le problème est simple à comprendre. Il existe plusieurs modèles psychoacoustiques; appellons les A-B-C...
Les encodeurs en utilisent un et un seul. Les logiciels d'analyses comme PEAQ en utilisent un et un seul. Admettons que LAME utilise le même modèle que le logiciel de test : ce dernier va logiquement considérer LAME comme parfait, ou du moins meilleur que des encodeurs faisant appels à d'autres modèles. Pourquoi : parce que si les deux utilisent le même modèle, le logiciel de test est amené à noter la pertinence... de son propre modèle. Il se juge lui-même !
De toute manière, ces logiciels ont d'autres limites reconnues, non épistémologiques cette-fois, notamment en matière de pré-écho qui est un phénomène dont la prise en compte échappe largement à l'analyse de ces modèles psycho-acoustiques. C'est pourquoi certains dévelopeurs d'encodeurs les utilisent pour des tâches très précises mais certainement pas une évalutation globale où là encore, c'est l'écoute du sujet ou d'un ensemble de sujet qui valide ou non la pertinence des changements.

Je te remercie pour tous ces éclaircissement !

Discussion super intéressante. Merci messieurs !

Grâce aux informations apportés par Atys je me rends compte de la complexité d'un algorithme de compression audio, ça donne vraiment envie de se renseigner dans le détail sur le sujet ! Et ça me donne toujours envie de trouver un moyen "technique" de tester le niveau de qualité audio d'un encodage, mais comme j'ai pu le voir sur les liens qu'Atys a fourni, il existe de nombreux papiers proposant des méthodes, mais il s'agit plus de papiers de recherche que de solutions abouties. Ce qui confirme réellement la complexité du sujet.

Atys, sachant que les 2 dimensions que notre oreilles perçoit concernant le son, sont l'intensité et la fréquence, si j'ai bien compris la compression consiste à supprimer l'information non perçu, qui se situe d'abord "bêtement" dans les hautes fréquences et les extrêmes basses fréquences, mais également (et c'est là qu'est toute la subtilité d'un encodeur) dans les phénomènes de masquage (temporel, fréquentiel) qui correspondent à la psychoacoustiques

J'imagine qu'il n'existe pas d'autres types de masquage que les 2 que j'ai cités ?
J'imagine que les modèles psychoacoustiques sont en perpétuelle évolution, car les définir est empirique, et j'imagine qu'il n'existe pas encore de liste exhaustive de leurs règles (pré écho en fonction de l'intensité et de la fréquence du pic, masquage en fonction de la fréquence et de l'intensité du pic précédent et de la fréquence masquée qui suit) ? Si c'est le cas, je suppose que cela vient du fait que l'espace étudié est continu ? Dès lors, on peut supposer qu'un jour on obtiendra tout de même un modèle exhaustif pour l'espace numérique qui est discret ?

Pour ma part, j'ai constaté qu'au fil du temps, les codecs sont de plus en plus performants d'un coté, dans la globalité, mais peuvent régresser d'un autre coté en fonction du type de musique encodée...

Tout reste subjectif mais Guruboolez constate ici ceci:



Donc dans le cas présent, une version plus récente sonne moins bien!

pour ma part j'ai constaté dans les versions successive de Lame une augmentation du temps d'encodage allant jusqu'au triple. Cela témoigne d'une complexification de l'algorithme, donc une amélioration du modèle acoustique utilisé, mais quand on voit les performances du codec 3.96, sur du 192 on triple le temps tout en perdant une bande passante de 2 KHz à partir de 16 Khz, ce qui est somme toute très douteux...

La vitesse d'encodage de LAME s'est très largement améliorée depuis la sortie de la version 3.90. Mais je ne veux pas remettre en cause tes observations. Certaines compilateurs produisent des exécutables sensiblement plus rapides (ou plus lent) que d'autres et il suffit que sa collection d'exécutables soit constituée d'exécutables compilés différemment pour constater des mesures dissemblables.
Ton observation concernant LAME 3.96 ("3 fois plus lent") me laisse penser que tu ajoutes le mode -q 0 à ton paramétrage. Suis-je dans l'erreur ?