Reprise du message précédent :
WavPack 4.31  
http://www.wavpack.com/
 

Le MPEG-4 audio sans perte standardisé au Japon
 
J'aimerais bien voir ce qu'il vaut face à Monkey et Wavpack en terme de ratio, de vitesse (encodage et décodage), support des tags, résistance aux erreurs, etc. Mais où ?

On en a parlé plus tôt dans ce topic (ou ailleurs), il me semble.
 
http://www.nue.tu-berlin.de/forsch [...] p4als.html
(cf "downloads" )
 
PDF: http://www.nue.tu-berlin.de/public [...] ebchen.pdf
 
(je croyais que c'était des Allemands qui faisaient le développement, contrairement à ce qui dit la news de PCINpact).

Bonne question.   Le problème, c'est que tant qu'il n'est pas téléchargeable, il ne faut pas trop s'attendre à de vrais tests publics. Quelque chose me dit que ça va être un pétard mouillé. Mais j'espère me tromper...  

Autant pour moi.
 

Mais si, il est téléchargeable:  
http://www.nue.tu-berlin.de/forsch [...] eg4als.zip
 
Mais je ne sais pas avec quoi lire.  

WOOOT !    
 
Bon, premier test en vitesse sur un morceau (stéréo) :
 
17 456 Ko : Wavpack -h
17 543 Ko : MP4ALS (sans argument)
 
Je retire ce que j'ai dit plus haut sur le pétard mouillé.    

Pas si mal.
J'imagine que ce que ca pourrait apporter, à défaut d'un format 3 fois plus rapide et plus efficient, c'est un standard reconnu par tous les appareils...
Même si avec la démocratisation annoncée du PC pour la lecture de tous les medias, l'intérêt de ce genre de standard diminue...

Quelqu'un se dévoue pour en parler sur HA (si cela n'a pas déjà été fait)?
 
(et aussi quémander gentiment un plugin pour notre logiciel de lecture préféré)

Un test juste de compression sur un CD mono qui pose problème à WavPack comme à MA :
 
43,98% : MA insane
43,30% : WavPack -h
40,52% : FLAC -8
40,03% : MPEG4ALS
39,24% : MPEG4ALS -7 (super lent)
 
 
 
Je sors ce soir et n'ai pas le temps d'en discuter plus que ça ou de faire d'autres tests, mais ça s'annonce passionnant !  

Bigre

 
J'ai posté cela sur HA.org:
http://www.hydrogenaudio.org/forum [...] ntry352885
 
Un comparatif incluant 150 plages de musique classique est en préparation (les premiers chiffres sont dispo sur le forum d'Hydrogen).
 
Merci Zurman pour cette info de taille !

il ne fait pas les choses a moitié le Guru
tres instructif

C'est le moins qu'on puisse dire

Il est si impressionnant que ca? Si ca se standardise c'ets intéressant mais si ca reste lettre morte hein ca ne fait qu'un codec lossless de plus non?

Bah sur le CD testé par Bora² il est 10% plus efficace que MA insane par exemple
 
Bon apparemment sur le test de Guru on revient à une hiérarchie Monkey > Mpeg-4 > Wavpack fx5
 
Dans tous les cas si ca permet une standardisation du lossless ca peut pas être un mal

Il faudra voir aussi ce que ça donne en lecture (seeking par exemple) et au niveau du support des tags.
 
En attendant bien sûr de pouvoir lire.  

Ouaip
 
D'ailleurs ca me fait penser à une question que j'avais déjà posée et qui était me semble-t-il restée sans réponse : La vitesse du seeking est-elle toujours proportionnelle à celle du décodage ? Et comment la mesurer précisément ?

Il n'y a rien d'impressionnant, sauf peut-être sur le CD à problème de BoraBora, pour lequel sont surtout impressionnantes les contre-performances de Monkey's et de Wavpack (qui se produisent avec un certain type d'enregistrement monophonique).
Le MPEG-4 a surtout pour but d'offrir aux industriels une solution standardisée. Pas de révolutionner l'encodage lossless par des outils surpuissants Le problème est que cette standardisation vient assez tard.  
C'est ce retard qui aurait poussé par exemple Apple, très MPEG-4 dans l'ensemble, à développer sa propre solution d'encodage et rien ne permet d'affirmer qu'elle sera abandonné au profit du nouveau format standardisé. Il y a aussi le cas des fabricants de baladeurs: iAudio et iRiver supportent flac, et il n'est pas certain que la solution MPEG-4 soit adopté par eux (de la même manière que l'AAC MPEG-4 a été évincé au profit de Vorbis). D'autres fabricants comme Creative tendent à préférer Microsoft au MPEG-4, et Microsoft a sous la besace un format lossless pour ses clients (avec DRM en plus, ce que le MPEG-4 se dispense d'offrir). Même Sony a récemment annoncé son propre format lossless.
 
Rien ne permet de condamner d'avance le MPEG-4 lossless, mais il faut bien reconnaître que sa situation est plutôt compromise. Ce format vient avec un retard de deux bonnes années, qu'il va falloir rattraper. Heureusement pour lui, le marché du lossless est si faible que rien n'est véritablement joué.

Oui, gaffe : j'ai bien précisé que c'était un CD "à problèmes". Sur ce CD, même FLAC fait mieux que Wavpack -h et MA insane. Je voulais juste voir comment MP4ALS se comportait et s'il avait le même genre de problème, ce qui en l'occurence n'est pas le cas.
 
Je fais des tests depuis ce matin avec un disque ordinaire, le CD 1 du dernier Kate Bush. J'essaye un peu tous les switches. Voilà quelques résultats intermédiaires, je posterai plus en détail quand j'aurai fini :
 
PCM : 393 173 Ko / 2282,4 secondes
 
172 843 Ko : MA -c5000
174 117 Ko : MA -c4000
175 711 Ko : MP4ALS -z1
176 182 Ko : MA -c3000
176 583 Ko : MP4ALS -7
177 193 Ko : MA -c2000
179 494 Ko : WavPack -hx
180 730 Ko : WavPack -h
181 344 Ko : MA -c1000
182 520 Ko : MP4ALS -p
183 214 Ko : MP4ALS default
187 141 Ko : WavPack default
191 336 Ko : FLAC -8
192 126 Ko : FLAC default
 
Une bonne chose en tout cas : il est asymétrique. J'ai décompressé le fichier -z1 pour voir et heureusement il a mis une fraction seulement du temps d'encodage à le décoder.

Pour les tags: la compatibilité avec le conteneur MP4 devrait satisfaire tout le monde.
 
Pour le seeking et sa vitesse: elle dépend directement du format, pas de la vitesse d'encodage ou de décodage. WavPack 3 était plus rapide à l'encodage/décodage que WavPack 4 (grace à un mode -ff), mais son seeking se comptait en secondes, voire en dizaines de secondes, alors qu'il frise l'instantanéité avec la nouvelle mouture.
Ensuite, pour certains formats, le seeking devient plus ou moins lent selon les profils (et donc les vitesses) utilisés ; c'est le cas de Monkey's Audio.
En gros, la vitesse dépend:
1/ du format (privilégiant plus ou moins la rapidité du seeking)
2/ du profil d'encodage, et encore pas toujours
3/ du support (sur une clé USB 1.1, le seeking devient franchement poussif...)

Ok, donc ne pas se baser sur le decoding speed pour extrapoler la qualité du seeking. Y'a des méthodes autres que le feeling pour mesurer tout ça ?

J'avais pensé un jour à utiliser un micro et un enregistreur, et mesurer après-coup l'écart entre le click de la souris et la lecture du nouveau passage  
 
Cela se fait au feeling: ou tu es gêné par le seeking ou tu ne l'est pas. L'habitude joue un grand rôle: demande aux utilisateurs du MPC

Et alors ca donnait quoi ?  
 

Ok... Pour moi le seeking est bon lorsqu'on peut naviguer en faisant de "l'avance rapide" en seeking continu de 5 sec. Pour Monkey High (que j'utilise) c'est ric-rac sur ma config malheureusement

C'eut été une perte de temps
 
J'oubliais: le seeking peut dépendre de la taille du fichier (ou de sa durée putôt), et bien entendu de la vitesse processeur. Certains formats comme l'encodeur d'OptimFROG disposent de commandes qui permettent de faire varier cette vitesse et donc de gagner ou de perdre un peu de place.
Enfin, un changement de conteneur peut également avoir un impact.
 
Donc beaucoup de paramètres peuvent entrer en jeu. Le plus simple est d'encoder un fichier avec différents encodeurs et d'éprouver la réactivité du seeking avec son propre PC et son logiciel favori. Tout le monde procède ainsi je pense. Je ne crois pas que des mesures précises en milli-secondes soient réellement d'un grand intérêt.

Et c'est toi qui dit ça

Ces switches ont peut-être (sans doute ?) un rapport avec le seeking ?
 
-r#: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)  
-u#: Random access info location, 0 = frames (default), 1 = header, 2 = none  

-z1 est censé être un mode asymétrique par rapport au mode par défaut ? Ou par rapport à -7 ? Car aussi bien -z1 que -7 sont affreusement lents. Je suis en train d'encoder les mêmes fichiers avec -z1 (je doute pouvoir finir les 150 fichiers de la liste (j'encode à x0.6 et il y a 16 heures de musique...), mais je note des gains parfois très importants.

Ah les autres modes, je ne sais pas. J'ai juste encodé/décodé un fichier avec le mode -z1 et constaté qu'il le décompressait relativement vite alors qu'il avait mis une éternité à l'encoder. Je ne fais pas (encore) de timings car j'ai besoin de bosser intensivement sur le micro cet après-midi donc ça me donnerait des chiffres assez farfelus. Mais dès que je pourrai le laisser tourner tout seul, je noterai les temps d'encodage/décodage. Pour l'instant, je fais joujou avec les switches pour voir les ratios.  

Je suis en train de faire -z2 et je vais enchaîner avec -z3.    

J'ai stoppé l'encodage avec -z1 après une vingtaine de fichiers. Le gain moyen par rapport au mode par défaut est de 26 kbps sur les fichiers testés. Pas mal. Reste à connaître la vitesse de décodage.
Or là, mon PC portable n'est pas un outil très fiable, car il dispose de peu de RAM (et sollicite donc la mémoire virtuelle trop souvent) et d'un disque dur poussif. Plus un encodage ou décodage est censé être rapide, et plus les résultats varient d'un test à l'autre.
 
Pour preuve:
 
décodage d'un fichier ALS {défaut} : les vitesses obtenues vont de x9 à x58 !
décodage d'un fichier ALS -7 : entre x9 et x10
décodage d'un fichier ALS -z1 : x0,9
 
BoraBora, pourrais tu vérifier que le décodage s'est fait de manière instantané avec -z1 comme référent ? Car de mon côté, mon Athlon 2000+ n'atteint pas le temps réel. Chez moi, -z1 n'est pas vraiment asymétrique (inférieur au temps réel en encodage comme au décodage). Par contre, -7 l'est (x1.1 à l'encodage, x9.9 au décodage).
 
Ces chiffres me semblent assez faibles. A ratio égal, les vitesses sont plus lentes que celles mesurées avec les formats rivaux sur mon Duron 800. Il faudrait que j'essaie WavPack, flac et MAC sur mon portable pour m'assurer d'une comparaison équitable.
On va mettre cela sur le compte du défaut de maturation de cette première version de l'encodeur

Yep, je regarde ça en fin de soirée !   J'ai fini les -z : le -z3 a mis 2 heures pour encoder mon CD de 38 minutes. En ratio, il bat d'un minuscule chouia le MA -c5000 sur ce CD (0,4%). Là, j'essaye -7 -p et ça va pas vite non plus. Pendant le repas et le film du soir je ferai -7 -p -z1 pour voir. Après, je décoderai tout ça. Mais ce ne sera pas super précis, juste un ordre de grandeur. Il faudrait que je ré-optimise ma bécane spécialement pour ça.  

Sur HA, Garf a supputé de grosses améliorations futures au niveau de la vitesse. Espérons qu'il est bon prophète.  

Bon, j'ai déliré : le mode -z n'est pas asymétrique.    
 
Les résultats, avec des timings très approximatifs :
 

 
Edit : j'ai pas fait -z2 en décompression, comme on peut le voir.  

Un p'tit comparo avec le LPAC aurait pu montré les gains de compression et perte en vitesse, vu que l'ALS est basé sur ce format, ça pourrai donner une idée du vrai travail fourni pendant ces long mois.
 
Enfin bon c'est a priori un encodeur basique sans optimisations, on peut esperer une grande augmentation, puis on est bientot à l'ere du dual/multi-core, alors meme si faut utiliser un CPU entier a "3GHz" pour decoder l'audio, c'est pas non plus irrealiste en utilisation, vu qu'on est bientot a du Dual Core/Quad Core a ~4GHz

Pour tester LPAC, je suppose qu'il faut installer iTunes ou au minimum Quicktime ? Si oui, je vais laisser le comparo à quelqu'un d'autre pour cause de boycott absolu et irrémédiable de tout ce qui vient de chez Apple. Cela dit, on connaît la place de LPAC grâce aux tests de Guru, donc il est facile de le replacer dans l'échelle.

Oui enfin pas vraiment. D'une part, on utilise le codec le plus optimisé en fonction de ses critères, donc pourquoi en utiliser un qui décode à 1,5x plutôt que l'autre qui fait la même chose à 70x ? Ensuite, même si c'est encore jouable en lecture, ça reste un calvaire pour les transcodages. Si tu veux te coller une vingtaine d'MP3/AAC ou autres sur ton baladeur le matin avant d'aller au boulot et qu'il faut 1h20 juste pour décoder les morceaux, le lossless perd tout son intérêt pour cette tâche.
 
C'est un codec prometteur du point de vue ratios, mais il est clair que les optimisations en matière de vitesse d'encodage/décodage vont devoir être énormes pour qu'il prétende seulement envisager de remplacer le FLAC ou le WavPack. D'autant que l'évolution matérielle concerne aussi les disques durs. Une différence de 2 ou 3% en ratio de compression va avoir de moins en moins d'importance.

J'ai aussi l'impression que pour moi la vitesse de décodage (et de seeking ) va bientôt prendre le pas sur le ratio... Demain, retour au wav ?  
 
Plus sérieusement, je pense que dès que foobar permettra un véritable transcodage, je passe tous mes ape en wv-hx4 ou -x4

Qu'est-ce que tu veux dire par "un véritable transcodage" ?  

J'attendais la question    
Une option pour que le transcodage supprime le fichier d'origine. Sinon il faut avoir 50% d'espace vide sur le HD, ce qui n'est pas gagné avec plusieurs centaines d'albums en .ape (et on ne peut pas non plus convertir un ape en ape, par exemple pour mettre à jour des 3.97 en 3.99)
 
edit : et une option pour que les fichiers lossless ne puissent pas être modifiés. Ca m'est arrivé récemment, un truc très bizarre d'ailleurs. Je faisais des tests avec wavpack : j'avais par erreur laissé coché "use replaygain values" et le fichier wv -hx4 optenu faisait 30% de taille en moins que Monkey High  Si quelqu'un peut expliquer ca...

Ah oué, pas pensé à ça. Ceci dit, si tu convertis du APE en WavPack -hx4, tu en as bien pour 1 heure par CD, donc tu peux les lancer 10 par 10 en nettoyant derrière après chaque batch. Ca te laisse quand même pas mal d'heures tranquilles avant de devoir recommencer la manip', non ?
 
Mais si tu as des centaines d'albums en MA et que tu as du mono, il vaut sans doute mieux que tu attendes la prochaine optimisation de WavPack, déjà intégrée à l'encodeur mais non encore active. Parce que 400 ou 500 heures de transcodage, c'est pas trivial et il vaut mieux être sûr de ne pas avoir à le refaire 3 mois après.  

Sans doute parce qu'il a du coup normalisé le fichier au niveau indiqué par la valeur RG. Or plus le volume d'un fichier audio est bas, mieux il se compresse.

Ok pour la prochaine version de wv, de toute facon je pense pas le faire tout de suite.
 
Pour le replaygain, je pensais que le truc faisait une bete translation du signal audio (réversible en faisant l'inverse) donc pour moi y'avait la même quantité d'info à coder. Faut croire que non
 
Edit : et les lancer 10 par 10 en nettoyant après chaque fournée, c'est précisément le truc que je veux éviter. Pour le setting, je m'étais à peu près décidé mais j'ai oublié si c'est -hx4 ou -x4  

Et le comparatif de Guru qui n'est plus accessible