Pour un DivX: Lame ou MusicMatch?

Pour un DivX: Lame ou MusicMatch? - Video & Son

Marsh Posté le 13-04-2001 à 19:58:45    

Lequel des deux logiciels est le mieux pour encoder le son d'un film?
 
Thanks.

Reply

Marsh Posté le 13-04-2001 à 19:58:45   

Reply

Marsh Posté le 13-04-2001 à 20:21:03    

LAME.
Mais tu devrais essayer le WMA inclu dans le DivX ;-)


---------------
Mon blog de nerd...
Reply

Marsh Posté le 13-04-2001 à 20:43:44    

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 !


---------------
A+++ Bruce - http://www.bheller.com
Reply

Marsh Posté le 13-04-2001 à 21:16:39    

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

Reply

Marsh Posté le 13-04-2001 à 21:34:00    

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:

Reply

Marsh Posté le 13-04-2001 à 21:35:50    

Ah bon c'est beau de dire FAUX, maintenant précise

Reply

Marsh Posté le 13-04-2001 à 21:36:35    

Fraunhofer, ya pas mieux :) :)

Reply

Marsh Posté le 13-04-2001 à 21:44:37    

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

Reply

Marsh Posté le 13-04-2001 à 21:44:42    

Lame aussi change la durée du son... Donc... C pas le codec du DivX qui est en cause, c la compression MP3...


---------------
A+++ Bruce - http://www.bheller.com
Reply

Marsh Posté le 13-04-2001 à 21:54:09    

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 ?

Reply

Marsh Posté le 13-04-2001 à 21:54:09   

Reply

Marsh Posté le 13-04-2001 à 21:57:49    

J'ai jamais utilisé Change video/audio duration avec LAME alors que c'est trés souvent le cas avec Frau

Reply

Marsh Posté le 13-04-2001 à 22:00:37    

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.

Reply

Marsh Posté le 13-04-2001 à 22:01:34    

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...


---------------
A+++ Bruce - http://www.bheller.com
Reply

Marsh Posté le 13-04-2001 à 22:05:45    

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.

Reply

Marsh Posté le 13-04-2001 à 22:07:06    

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.


---------------
A+++ Bruce - http://www.bheller.com
Reply

Marsh Posté le 13-04-2001 à 22:16:46    

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.

Reply

Marsh Posté le 13-04-2001 à 22:16:56    

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 !


---------------
A+++ Bruce - http://www.bheller.com
Reply

Marsh Posté le 13-04-2001 à 22:51:25    

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

Reply

Marsh Posté le 14-04-2001 à 02:43:58    

En effet... Je passe sur Lame pour la v3 :)


---------------
A+++ Bruce - http://www.bheller.com
Reply

Marsh Posté le 14-04-2001 à 09:39:38    

Pour pas avoir de décalage
 
y a q'a encoder divx + ac3
 
là c'est nickel et sont wazaaaaaa up :sol:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed