The root of these problems is the MP3 spec, which allows audio frames to "borrow" unused bandwidth from earlier frames, making it impossible for the MP3 audio codec to specify a fixed size for a self-contained audio block.
Ca c'est sure que les codecs de compression décale la source, mais entre 0,010 et 1,314 s il y a quand même une sacrée difference
Bruce
Ok, résultat de mon petit test. J'ai encodé en MP3 "meet her at the love parade" de "Da Hool". La chanson en WAV PCM dure 9 minutes 34.533 secondes.
Encodé avec lame 3.88 : 9 minutes 34.563 secondes.
Encodé avec Musicmatch (dernier Fgh officiel) : 9 minutes 34.563 secondes.
Encodé avec virtualdub et le codec Fgh fourni avec le DivX : 9 minutes 33.219 secondes.
Il est clair que l'écart le plus gros est obtenu avec le codec du DivX... Mais TOUS font un écart, et ce même légé !
Pour pousser le test, j'ai aussi encodé en WMA à 64 Kbps, toujour avec Vdub : 9 minutes 34.580 secondes...
Je passe le fait que dans ce cas là je n'ai pas eu à faire de convertion 48->44.1 kHz...
Niveau temps d'encodage, le WMA est le plus rapide (un peu plus d'une minute), les deux autres codecs (Lame et Musicmatch) prennent dans les 3/5 minutes. Le codec du DivX met plus de 12 minutes !
Strike_Again
Bruce a ses zélotes on dirait. Je critique pas l'intégré qu'il a produit je ne le connais pas et je ne me permettrait pas de déscendre un soft que j'ai pas tésté dans tout les sens. Je précise les faits c'est tout. Si je devais craché sur frau je dirais que c'est un codec de pédé, ce que je ne pense pas mais il faut être claire le codec rippé a un défaut c'est prouvé. Maintenat on est au courant, on sait à quoi s'attendre et quoi en tirer et comment le corrigé. C'est comme dire que Windows n'a pas de bug. Tout le monde sait que c'est faux et pourtant tout le monde fait avec.
Bruce
Non... Mais comme tout codec, il as subit des évolutions, et le codec du rippack (du DivX en fait...) est légèrement plus vieux que le dernier Fgh officiel...
Lame aussi évolue. La 3.88 est sortie il y as peu.
ben84
bruce a écrit a écrit :
Ben84 : tous les codec font un décalage ! Si j'ai mis celui là, c'est que c'est celui fourni avec le codec DivX donc le plus simple à utiliser.
Oui donc Lame est aussi bien sinon un peu moins bien que frau.
Donc aucune raison de cracher sur le frau.
Bruce
Ben84 : tous les codec font un décalage ! Si j'ai mis celui là, c'est que c'est celui fourni avec le codec DivX donc le plus simple à utiliser.
Strike_Again : TOUS les codecs font un décalage ! Je suis en train d'encoder une chanson assez longue pour le prouver...
ben84
Strike_Again a écrit a écrit :
J'ai jamais utilisé Change video/audio duration avec LAME alors que c'est trés souvent le cas avec Frau
Desolé mais moi non plus je n'ai jamais utilisé Change video/audio duration avec le Rippack, donc avec Frau, à moins que le rippack le fasse tout seul, mais je pense pas.
Strike_Again
J'ai jamais utilisé Change video/audio duration avec LAME alors que c'est trés souvent le cas avec Frau
ben84
Strike_Again a écrit a écrit :
Ah bon c'est beau de dire FAUX, maintenant précise
Demande à Bruce, il a mis le codec fraunhofer dans son Rippack, et c'est pas pour rien.
Et je n'ai pas eu un seul decalage depuis que j'encode avec le Rippack, et Bruce non plus d'ailleurs......
Je peux me tromper, mais j'en doute fortement.
Bruce, c'est vrai ou c'est pas vrai ?
Bruce
Lame aussi change la durée du son... Donc... C pas le codec du DivX qui est en cause, c la compression MP3...
Strike_Again
Another problem with this codec is that it is an enormous hack. In particular, it sets the nBlockAlign member of the wave format to 1. This means that applications think a single byte can be decompressed into audio, when in fact the Fraunhofer-IIS codec will buffer up data until it has enough to decompress a Layer 3 frame. Extracted sections of such audio streams will often have muted tails because the audio codec discards fractions of frames at the start. The root of these problems is the MP3 spec, which allows audio frames to "borrow" unused bandwidth from earlier frames, making it impossible for the MP3 audio codec to specify a fixed size for a self-contained audio block.
Finally, the Fraunhofer-IIS codec is very lazy and incorrectly sets the bitrate of the stream. For instance, a 48Kbit stream encoded by the Fraunhofer-IIS codec has a specified rate of 6000 bytes/sec, when in reality the stream is about 5971 bytes/sec. This 0.0048% difference may not seem like much, except that it causes the audio to race past the video approximately one second for every 200 seconds of video. One way to ‘fix’ this problem is to correspondingly adjust the video frame rate to compensate. VirtualDub will automatically correct for this problem when compressing audio to MPEG format.
J'ai pas dit que le codec original était nul, j'ai dit que le codec rippé avait un problème
tixi
Fraunhofer, ya pas mieux :) :)
Strike_Again
Ah bon c'est beau de dire FAUX, maintenant précise
ben84
Strike_Again a écrit a écrit :
Le codec fraunhofer fourni avec le codec divx est un codec rippé et il provoque un décallage qq secondes de la bande son ce que ne fait pas le codec original ou LAME
:fou: :fou: :fou: FAUX :fou: :fou: :fou: :fou:
Strike_Again
Le codec fraunhofer fourni avec le codec divx est un codec rippé et il provoque un décallage qq secondes de la bande son ce que ne fait pas le codec original ou LAME
Bruce
Les deux sont très bien. Musicmatch utilise le codec fraunhofer qui est (de l'aveux des créateur de Lame !) encore un peu meilleur. Mais honettement c pareil !
Castor666
LAME.
Mais tu devrais essayer le WMA inclu dans le DivX ;-)
Alload
Lequel des deux logiciels est le mieux pour encoder le son d'un film?
