Reprise du message précédent :
Gogo-No-Coda

ehhh, mais c'est pas le truc pouris gogo?

C'est le truc super rapide mais qui ne produit pas le meilleur résultat.
Ceci dit, tout ce qui n'obtient pas la qualité produite par Lame n'est pas forcément "pouris".

ok, merci.

ah, j'ai retrouvé, CT helix que je cherchais!!

c'est juste une GUI pour gogo ou est ce qu'il intègre une version spéciale de gogo ?

j'ai des problèmes de stabilité sur oggenc.exe aoTuVb4 . suis je le seul ? (encodage depuis foobar)

Tu parles de Gogo-No-Coda?
L'encodeur que l'on apelle "gogo" s'appelle en fait "Gogo-No-Coda" de son nom complet.

Salut,
 
Je viens de me mette à la page sur les codecs vorbis. J'utilise EAC
 
Problème, le codec oggenc.exe aoTuV proposé par l'auteur fait 1,5 Mo, celui sur le xiph fait 400 ko et je viens de lire un post où gutenberg propose le codec optimisé pour les instructions sse
(son lien est mort)
http://forum.hardware.fr/hardwaref [...] 7481-1.htm
 
Alors, lequel je choisis avec mon barton 2500+ ?

perso j'utilise celui ci (j'ai un 2400+) :
 
Oggenc2.6 using aoTuVb4 (libVorbis v1.1.1)  2005-07-09
VBR Quality setting, SRC libsamplerate high quality resampler added - see Help - ICL 8.1 compiles
P3/AMD (401Kb)
 
http://www.rarewares.org/ogg.html

Pour l'instant idem,  
mais je me demandais bien pourquoi le fichier de l'auteur est trois fois plus gros (une fois décompressé)
 
http://www.geocities.jp/aoyoume/ao [...] TuV_b4.zip
 
M'enfin, ça m'empêchera pas de dormir non plus...

peut-etre parceke le fichier de l'auteur n'est pas optimiser pour une plateforme mais pour plusieur plateforme

il l'a peut être compilé en mode debug

Je sais pas ce que c'est que le mode debug.  
Mais je pense que je vais faire sous peu l'expérience d'encoder avec les deux versions chrono en mains pour voir. Je suis totalement incapable de différencier une différence éventuelle de qualité, on verra sur la quantité.

si c'est en mode debug, ce sera plus lent

poussé par ma curiositer et le fait ke j'avait envie de mettre un de mes vieux CD sur mon PC, j'ai fait le test
 
j'ai donc fait une extraction du CD audio avec EAC comme dab, 1h02 de music
apres conversion avec l'aide de foobar (la consol va m'etre utille) sur mon PC portable équiper d'un P4 2.66Ghz, 512 Mo de ram DDR 333 cas 3-3-3, DD 40 Go Seagate 5400 RPM
pour donnée une idée de vitesse je donne la vitesse annoncer par la consol de foobar sur la piste 1 d'une durée de 5m51
compresion en Q5.3 (j'aime bien les virgule   )

j'ai aussi utilliser le codec P3/AMD pour voire, mais seulement sur le 1er morceau du CD
 
 
bref y a pas photo en ce ki concerne la vitesse, les version "optimiser" donne un vrai gain, du moin avec une plateforme P4
pour le poid des fichiers, je n'ai regarder ke la 1er piste audio et a kelke octet pret il sont de poid équivalent  
 
 
PS: ce test ne porte ke sur la vitesse d'encodage et non sur la qualiter, mais vue le poid des fichier et leur bitrate identique je suppose ke si il y a une difference celle-ci serai difficilement perceptible

Mon test :  
Ripp du cd de Genesis "We can't dance", 1H11:36s avec EAC 0.95 beta 3
- Encodage avec EAC Q6
- Chronométrage déclenché à la main sur mon portable
- Config Barton 2500+, 512 Mo ram corsair LL 2-2-2-6
 
  codec                        temps d'encodage album                          Taille du fichier en octets
aoTuV_B4                             6mn46                                                  100 109 953
enc P3/AMD                          6mn01                                                  100 110 156
 
Vu la différence d'octets, j'ai cherché à en savoir plus avec ogginfo. Il ne semble pas que les références aoTuV soient différentes. Pourtant, ça modifie le bitrate d'un petit poil..
 

 
    Le gain de temps est moins important que sur le P4 de Dakans (45 sec contre 1mn42) mais il reste significatif.
Moi qui est l'habitude d'aller chercher les fichiers directement sur le site de l'auteur, c'est bien une des rares fois  où j'aurais été désavantagé.

Vu ton processeur, j'essairai LANCER (compilation de vorbis aoTuVb4 optimisée SSE3 je crois):
http://homepage3.nifty.com/blacksword/
lien direct : http://homepage3.nifty.com/blacksw [...] 050709.zip

Waouh !
Sur les conseils de gURuBoOleZZ, voici le test avec lancer
 
  codec                        temps d'encodage album                          Taille du fichier en octets  
aoTuV_B4                             6mn46                                                  100 109 953  
enc P3/AMD                          6mn01                                                  100 110 156  
lancer                                  3mn10                                                  100 110 406
Presque 3 minutes de différence !
 
Comme j'y croyais pas, je l'ai refais sur "No son of mine"d'une duréé de 6mn40
 
  codec                        temps d'encodage                        Taille du fichier en octets  
aoTuV_B4                             39 sec 70                                        9 165 697
enc P3/AMD                          35 sec 00                                        9 165 601
lancer                                  18 sec 03                                        9 165 657
 
Les détails ogginfo pour le codec lancer sur la première chanson ("No son of mine" ) :

 
  Merci gURu  

Wow! Le gain en vitesse atteint les 100% dans ton cas! J'avais lu que l'on pouvait désormais espérer plus de 50% avec LANCER, mais je ne pensais pas que le gain puisse être aussi conséquent.

Euh, là je crois que tu te laisses déborder par l'enthousiasme    
On est bien dans ce que annoncent tes lectures et c'est déjà énorme !
 
Pour être précis, 53.2% de gain entre l'encodage avec l'aoTuV original et celui modifié par lancer

Dans ton cas, la vitesse double - ce qui fait bien du 100%
Sur mon PC portable, j'atteint péniblement les 50% de gain (de mémoire [imprécise], cela passe de X10 à x15).

100% de gain en vitesse et 50% de gain en temps, comme ça tout le monde est d'accord.
 
Comment ça Lame est à la traine au niveau vitesse ? ;-)

A ce sujet, penses-tu que qu'il serait possible techniquement d'obtenir de tels gains avec un encodeur tel que LAME en l'optimisant à son tour pour les derniers jeux d'instructions ayant cours sur les CPU x86 ?

Réduire de 30% le temps d'encodage me parait possible, au dessus c'est moins sur.

Et cela exige-t-il beaucoup de travail ? Ou des compétences particulières ?

même question sur un processeur 64bit ?

 
celon ce vieux test (1er Juin 2004) sur Lame 3.93, un Barton 3200+ fait aussi bien k'un A64 3200+ socket 754 ou k'un A64 3500+ sur socket 939 graver en 0.13µm, les 3 proco ayant la meme vitesse réelle de 2200Mhz
 
je croit k'actuellement un bonne partie des codec s'en foute total ke le proco soit un 32 ou un 64 bit
donc oui celon moi une optimisation 64 bit devrai donner un boost dans la vitesse d'encodage

Un peu de travail, vu que les points les plus faciles et les plus interessants disposent déjà de fonctions assembleur. Comme compétences, cela ne nécessite pas de compétences quand à la compression audio. Comme la version Lancer ou Gogo, il s'agit d'une conversion "brute" de l'existant, sans rien changer aux algos.
 

Il est possible que l'on gagne 10-20% en x64, du fait de l'augmentation du nombre de registres. Sur ce point, c'est principalement le boulot du compilateur et pas le notre. Par contre, que ce soit du 64bits ou pas, on s'en moque.
Pour le moment, Lame est handicapé en 64bits car nos routines assembleur necessitent NASM, qui ne produit pas de code 64 bits. Donc en 64bits, pas d'assembleur actuellement.
Pour donner une idée, ajouter "--noasm mmx --noasm sse --noasm 3dnow" à Lame.

Surtout dans un test comme celui-là qui utilise des applis 32bits sous un OS 32bits...

il faut attendre les optimisation en 64 bits
mais entre le passage de 32 à 64bits et l'arrrivé des proco multi coeurs, les fans de l'assembleurs ont du pain sur la planche

Pour l'heure il n'y a aucune optimisation pour le 64bits, que ce soit sur le compilo Intel ou gcc. Aucun gain de perf n'est à attendre donc, sauf pour MySQL d'après les bench que j'ai pu consulter.
D'autre part il me semble que les registres supplémentaires ne sont activés qu'avec un OS 64 bits.

Dans notre cas ce n'est pas vraiment le 64bits qui nous interesse mais les registres supplémentaires apportés par le x86-64.
VC++ (ou plutôt le platform sdk de Ms) doit bien en faire quelque chose, vu que sans les optims assembleur faites à la main Lame est plus rapide en x64 qu'en x86.
 
note: pour l'utilisateur final cela n'a pas grand interêt, vu que le gain ne compense pas la perte de vitesse due à la désactivation des optims assembleur.

Ca c'est évident. Un programme 64bits ne fonctionne que sous un OS 64bits, donc sous win32 pas d'optims pour les processeurs 64bits.
Par contre sous 2003-x64, xp64 ou Linux64, c'est possible.

je n'avais pas vue cet effacement, mais maintenant que je sais qu'une maj pourait arriver, me v'la tout impatient  

Je ne compterais pas trop dessus. C'est très improbable.

Tu ne pourrais pas tout simplement remettre le contenu et renommer le thread en "2002: Tout sur les ...."
Je trouve que d'un point de vue "historique" c'est dommage.

Pour les nostalgiques, le texte est encore disponible au milieu de la page suivante, le tout dans un style très disco encore plus daté que  les textes eux-même.

dommage

Chouette, ça veut dire que tu vas refaire ton guide foobar à la sortie de la 0.9

Il devrait être prêt à la fin du mois de février 2004, si tout va bien