[Scirocco]

Je viens de répondre à une question sur ce sujet dans un post et je me dis que finalement ça devrait intéresser pas mal de monde, donc je le mets ici en nouveau topic.
----------

L'une des grandes faiblesses du format AVI est le problème de désynchronisation audio/vidéo. Il y a une quantité astronomique de tutoriaux sur le web qui expliquent comment resynchroniser les streams audio et video, en mettant un décalage initial ou on changeant le framerate, selon le type des symptômes rencontrés. Ce sont des manips bien connues, en tout cas qui devraient l'être par toute personne qui a pris le temps de fouiller le web avant de poster une requête.

Néanmoins, il y a un cas très particulier de désynchro qu'on rencontre dans les topics liés à quasiment toutes les platines de salon, quelque soit la puce, quelque soit la marque : un fichier AVI qui est parfaitement synchro sur un player PC mais qui n'est pas synchro sur la platine. Autre cas de figure, le fichier qui passe tout à fait normalement sur PC, est lu sans la bande-son sur la platine, alors que le codec audio utilisé est parfaitement reconnu dans d'autre fichiers. D'après les tests que j'ai pu effectuer, 95% des problèmes sont liés à un mauvais facteur I/L (je n'ai toujours pas réussi à identifier le problème des 5% restants).

L'objectif de ce mini-tutorial est simplement de faire le point sur ce que je sais sur la question. Je serais particulièrement heureux si d'autres lecteurs pouvaient apporter leur expérience personnelle sur ce point.

1 - Un peu de théorie

Dans un fichier AVI, le signal video est découpé en blocs (chunks) chainés les uns aux autres, dans lesquels il y a à la fois le stream video et des pointeurs vers le (ou les) streams audio. La fréquence de ces pointeurs dépend du ratio d'entrelacement (en anglais "interlacing ratio" ou I/L en abrégé).

C'est la taille occupée par ces pointeurs qu'on appelle "overhead" (ceux qui utilisent GordianKnot doivent reconnaitre ce terme). Ca peut se traduire par "surcoût", dans le sens où ces pointeurs prennent de la place dans le codage sans apport qualitatif pour le signal encodé. C'est un peu la mauvaise graisse du format. C'est d'ailleurs une des raisons pour lesquelles AVI est considéré comme un format peu performant par rapport à d'autres tels que OGG pour lequel l'overhead est extrêmement petit. Mais bon, le format AVI a été conçu à l'époque de Windows 3.0, donc on peut être un peu tolérant avec la mauvaise graisse du papy.

A priori, moins il y a de pointeurs, moins il y a d'overhead, donc on se dit qu'il faut en mettre le moins possible. Evidemment, ce n'est pas si simple...

En effet, la synchro audio/video ne peut se faire que grâce à ces pointeurs (un peu comme un métronome en musique), donc s'il n'y en a pas assez, la désynchro est garantie, tout simplement parce que la décompression audio et video se font dans des threads (asynchrones) différents et qu'il faut bien de temps en temps battre la mesure.

Difficulté supplémentaire, le format AVI ne précise aucune règle concernant le positionnement des pointeurs audio dans les chunks. En clair, on peut les mettre n'importe où... même en plein milieu d'une image du signal vidéo. Wavavoum ! (enfin, juste pour les puristes, ce n'est pas tout à fait vrai, mais le résultat est le même).

Comme dit plus haut, le positionnement de ces pointeurs par rapport aux frames vidéo est ce qu'on appelle le ratio d'entrelacement (symbolisé par I/L) et c'est notamment ce que fournit le logicel GSpot (couteau suisse indispensable pour tout possesseur de platine divx, cf. plus bas).

Il s'agit d'un nombre décimal dont la signification est très simple à comprendre: il représente le nombre de video frame qu'on trouve entre deux pointeurs audio. Ainsi:

I/L = 1 signifie 1 frame A, 1 pointeur audio, 1 frame B, 1 pointeur audio, etc
I/L = 4 signifie 4 frames A B C D, 1 pointeur audio, 4 frames E F G H, etc
I/L = 1.2 signifie 1 frame A, 1/5 de frame B, 1 pointeur audio, 4/5 de frame B, 2/5 de frame C, 1 pointeur audio, 3/5 de frame C, etc

Donc lorsque l'I/L est un nombre entier, cela signifie que les pointeurs audio sont systématiquement rangés entre deux images, alors que si I/L est un nombre fractionnaire, les pointeurs audio peuvent se placer au milieu de l'information codant l'image.

Quand on voit ça, on se dit qu'il est complètement crétin d'utiliser un I/L fractionnaire vu la complexité supplémentaire que cela entraine pour le codage et le décodage. Oui... et non Le problème c'est que les unités de mesures usuelles pour l'audio et la video ne sont pas les mêmes: la vidéo raisonne en images, l'audio raisonne en millisecondes. Donc un I/L fractionnaire peut sembler très complexe si on raisonne du point de vue des images, mais très simple si on raisonne du point de vue du son (un pointeur audio toutes les 10ms, par exemple). L'API de Windows permettant de manipuler les fichiers AVI n'a jamais voulu trancher entre les deux manières de voir les choses et permet un choix libre entre ces deux approches: on synchronise en se basant soit sur le flux video, soit sur le flux audio.

C'est là que les choses diffèrent entre les players software sur PC et les platines de salon. Les players software étant basés sur l'API Windows, traiter des I/L entiers ou des I/L fractionnaires ne change absolument rien. Malgré tout, comme la plupart des codec audio sont à bitrate constant (CBR) alors que les codec video sont presque toujours à bitrate variable (VBR), les applications de montage et de traitement vidéo ont généralement tendance à se synchroniser sur le flux audio pour lequel les données arrivent en paquets de taille régulière. C'est notamment pour cela qu'Avery Lee (l'auteur de VirtualDub, l'un des logiciels les plus utilisés pour la manipulation des fichiers AVI) qui est certainement l'une des personnes qui maitrise le mieux les arcanes du format AVI, n'a jamais accepté d'inclure des streams audio VBR dans son logiciel.

Inversement, les platines de salon sont basés sur un équipement électronique issu du domaine de la télédiffusion, dans lequel la base de temps c'est 50Hz pour le SECAM et le PAL et 60Hz pour le NTSC. Par conséquent l'espace naturel de fonctionnement pour ce type d'équipement, c'est de se synchroniser sur le flux video, et donc d'utiliser un un I/L ENTIER .

Parmi tous les fichiers AVI que j'avais encodé et gravé sur CD, les seuls qui ont engendré une désynchro audio/video était justement ceux qui avaient un I/L fractionnaire. Selon les fichiers (et d'après ce que j'ai pu voir dans les posts, selon les platines) le symptôme résultant de la lecture d'un fichier avec un I/L fractionnaire est variable mais il n'est jamais agréable : pas de son du tout, ou alors lecture correct pendant un minute ou deux puis arrêt du son, ou alors un décalage progressif du son par rapport à l'image, ou alors accélération de la vidéo pour essayer de rattraper le son, etc. Evidemment je ne possède qu'une platine (trois si j'emprunte celles des copains) je n'ai donc pas la garantie que tous ces problèmes soient systématiquement un problème d'I/L fractionnaire, mais je suis assez confiant dans mon diagnostic.

Néanmoins, tous les fichiers avec un I/L fractionnaire ne se désynchronisent pas. En particulier, si le stream audio est encodé avec un codec CBR, les choses ont l'air de bien se passer (comme si la régularité du flux audio permettait d'assurer un deuxième niveau de synchronisation, en plus des pointeurs d'entrelacement). Par contre, le cocktail I/L fractionnaire + codec audio VBR (dans mes exemples c'était soit un stream audio en MP3 VBR ou un stream en AC3) a l'air assez explosif pour les platines de salon.

Et ce n'est pas fini Indépendamment du facteur I/L qui fournit la position des pointeurs audio, il y a aussi plusieurs manières de positionner physiquement le(s) stream(s) audio sur le(s)quel(s) vont pointer ces pointeurs. Soit on met le stream tout à la fin du fichier, derrière le stream video (dans ce cas là, le booléen SPLIT de Gspot est à NO), soit on le découpe en tranches comme le signal vidéo et on le met dans les chunks (dans ce cas là, SPLIT=YES). Dans le cas d'un bivx (fichier divx avec plusieurs streams audio) on peut même panacher un stream SPLIT=NO et un stream SPLIT=YES, si on le désire

Lorsque le fichier AVI est stocké sur un support lent comme un CDR, il faut impérativement avoir SPLIT=YES, sinon la tête de lecture n'arrête pas de faire des aller-retours entre le chunk video en cours et la fin du fichier où se trouve l'audio. Sans faire gaffe, j'ai gravé un ou deux CD avec un SPLIT=NO, et même avec des players sur PC la lecture peut être saccadée (on entend la tête de lecture qui danse la java pendant tout le film). Il faut noter que si l'on recopie le fichier incriminé sur disque dur, généralement ça se passe bien mieux car les temps d'accès sont suffisamment courts (et les têtes suffisamment silencieuses) pour qu'on ne remarque rien.

Avec un gros cache de lecture sur la platine, on peut néanmoins avoir une lecture fluide même avec des fichiers qui ont un SPLIT=NO (il y a suffisamment de posts qui en témoignent), mais il me semble que ce n'est pas très bon pour la longévité de platine d'infliger ce traitement à la tête de lecture.

2 - Un peu de pratique

Comment faire pour soigner les problèmes de désynchronisation chronique ? Premier conseil, ne jamais graver bêtement un fichier AVI avant d'avoir ausculté son contenu avec deux outils (freeware) indispensables: GSpot (http://www.headbands.com/gspot/) et AviCheck (j'ai perdu l'URL, mais ça se trouve facilement, c'est édité par la société Sigma qui a créé les premières puces divx).

Le rôle de GSpot est de fournir des renseignements très complets à la fois sur la taille des flux audio et video, les codecs audio et vidéo utilisés, les bitrates correspondants, ainsi que le facteur I/L qui nous intéresse plus spécifiquement ici. Voici une capture d'écran du logiciel :



Le logiciel AviCheck permet de compléter les infos de GSpot, notamment en fournissant la valeurs des options d'encodage DivX Pro (Bframes, GMC et QPel) qui peuvent faire planter le décodage selon la puce utilisée. Il faut noter que ces infos DivX Pro devraient être directement fournies par la prochaine version de GSpot (en test beta actuellement), donc AviCheck ne sera bientôt plus utile.

-----

Bon, je suis un peu crevé (02H51). La suite au prochain numéro...

[ahdiddum]

Bravo à toi pour ces informations si précieuses
C'est d'autant plus méritoire si l'on voit l'heure à laquelle tu les as tapées
Je ne suis pas sûr d'avoir tout compris mais j'y retourne, je vais bien finir par piger !

[NewBe]

Excellent tutorial !! Ca mérite d'être en Post-it !!

[Segamaniac]

Impressionnant le Scirroco.
D'après mon vécu avec la LIfetec.
Lit les XVID sans pb.
Son qui grésille je trouve (via péritel)
Quand le I/L est un entier , on n'a pas toujours la syncro.
Et d'après mes tests, c'est plus quand le split est à No que ça marche, avec un preload de 460 ou 480...
En tous cas le I/L doit toujours être (1/fps)*1000 soit par ex. 1/25 *1000 =40.
Pour moi ça marche avec des 23.976 fps etc... du moment que la règle ci dessus est vérifiée.
Réflection basée sur 5 divx pour le moment.
Au fait, elle reconnait les fichiers avec extensions .divx (cool).
Je suis en train de faire le tri pour espèrer aider ce bon scirocco à définir la règle de codage.
Tu parles de la reco. du son même les wma ?
@+

[Segamaniac]

Cette fois j'en ai un qui marche top avec split Yes mais I/L =25 vid (1000ms)
vidéo 25 fps.
Hum...

[Scirocco]

C'est vrai que mon texte n'était pas clair (je l'ai édité depuis). Quand je dit I/L entier, je veux dire un nombre entier de video frames : 1 vid, 2 vid, etc, et pas des 1.2 vid ou des 0.66 vid. La valeur en millisecondes n'est pas significative dans ce cas. Quand tu donnes ta règle (1/fps)*1000, cela signifie justement que c'est entrelacé à 1 video frame... ce qui est parfait.

De même I/L = 25 vid frame comme dans ton deuxième exemple, ca doit marcher bien aussi, sauf qu'il n'y plus qu'un pointeur audio par seconde, ce qui veut dire que si tu fais un accès direct (touche SEARCH ou GOTO, selon les télécommandes) tu as soit un risque de désynchro, soit un risque d'absence d'audio pendant une seconde (pas trop grave).

Pour le split=No, tu n'es pas le premier à dire que ca marche correctement sur la LifeTec. Avec un gros buffer audio, on peut éviter les désynchro, mais ce qui est clair c'est que la tête de lecture doit faire des aller-retour réguliers (as-tu écouté la tête de lecture pour les Split=No ?) ce qui implique un risque d'usure prématurée sur le long terme.

Sinon, si tu dis qu'avec un I/L entier en video frame, tu as une désynchro, je suis intéressé pour avoir des infos plus complètes car moi je n'ai que deux exemples qui plantent dans ce cas, donc c'est difficile de faire un diagnostic.

[patrice21]

J'ai traité certains fichiers avec VirtualDubMod en mettant simplement
Video : stream copy
Audio : stream copy
après les coupures sons et/ou décalages ont disparu, le fichier faisant ~2Mo de plus on peut penser que virtualdubmod à rajouté des infos de synchronisation dans l'avi ?

[Segamaniac]

Ce qui marche sur ma Lifetec:
Filesize.....: 663 MB (or 679,194 KB or 695,494,656 bytes)
Runtime......: 01:12:16 (103,970 fr)
Video Codec..: XviD
Video Bitrate: 895 kb/s
Audio Codec..: ac3 (0x2000) Dolby Laboratories, Inc
Audio Bitrate: 384 kb/s (5 ch) CBR
Frame Size...: 576x336 (1.71:1) [=12:7]
I/L:1 aud frame (32 ms) Split: No
FPS:23.976
*************
Filesize.....: 699 MB (or 715,990 KB or 733,174,272 bytes)
Runtime......: 01:16:16 (114,409 fr)
Video Codec..: DivX 3 Low-Motion
Video Bitrate: 1182 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 96 kb/s (48/ch, stereo) CBR
Frame Size...: 400x256 (1.56:1) [=25:16]
I/L:25 vid frames (1000 ms) Split: Yes
FPS:25.000
*************
Filesize.....: 693 MB (or 709,696 KB or 726,728,704 bytes)
Runtime......: 01:47:41 (154,910 fr)
Video Codec..: XviD
Video Bitrate: 763 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 128 kb/s (64/ch, stereo) CBR
Frame Size...: 608x256 (2.38:1) [=19:8]
I/L:1 vid frame (42 ms), p=480 Split: No
FPS:23.976
*************
Filesize.....: 660 MB (or 676,410 KB or 692,643,840 bytes)
Runtime......: 01:44:05 (156,134 fr)
Video Codec..: DivX 4 (OpenDivX)
Video Bitrate: 783 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 96 kb/s (48/ch, stereo) CBR
Frame Size...: 720x320 (2.25:1) [=9:4]
I/L:1 vid frame (40 ms), p=480 Split: No
FPS:25.000
*************
Fige la platine

Filesize.....: 682 MB (or 698,396 KB or 715,157,702 bytes)
Runtime......: 02:16:50 (205,257 fr)
Video Codec..: DivX 3 Low-Motion
Video Bitrate: 565 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 128 kb/s (64/ch, stereo) CBR
Frame Size...: 416x240 (1.73:1) [=26:15]
I/L:18 vid frames (720 ms) Split: Yes
FPS:25.000
*******************
Son décalé
Filesize.....: 686 MB (or 703,448 KB or 720,330,752 bytes)
Runtime......: 01:18:22 (112,733 fr)
Video Codec..: DivX 3 Low-Motion
Video Bitrate: 1124 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 96 kb/s (48/ch, stereo) CBR
Frame Size...: 640x384 (1.67:1) [=5:3]
I/L:1 vid frame (42 ms) Split: Yes
FPS:23.976
*******************
Je continue les tests, @+[/u][/b]

[Scirocco]

Patrice21: C'est effectivement la manip la plus simple (c'est celle que je conseille, et que j'ai prévu de mettre dans la partie pratique de mon tutorial). Le fait que la taille du fichier augmente est parce que par défaut VDM met un I/L de 1 vid frame, ce qui est beaucoup et qui génère un overhead plus important que dans ton fichier initial.

Entre 2 et 3 méga sur un fichier de 700Mo est justement l'overhead habituel généré avec un I/L de 1. Si tu fais la même manip entre forçant un I/L à 10 video frames, l'augmentation de la taille sera beaucoup plus faible.

Attention: Le version 1.5.4.1 de VDM est buggée sur la modification du facteur I/L. La toute nouvelle 1.5.10.1 (sortie le 02/12/03) corrige ce bug. J'ai pas encore testé, mais c'est marqué dans la "release changes".
Sinon, VD marche bien sur ce point.

---

Segamaniac: Merci pour tes infos GSpot. Effectivement, la LifeTec est assez souple dans ce qu'elle est capable d'avaler. As-tu des fichiers avec un I/L fractionnaire ou un I/L "not defined" pour voir le comportement ?

Pour le fichier qui fige la platine, as-tu vérifié avec VD qu'il n'y a pas de "bad frames" ?

Pour le fichier avec désynchro, est-ce que c'est une désynchro progressive ? As-tu essayé de le lire en forçant le mode NTSC sur la platine?

[Segamaniac]

De rien Scirocco, on a tous a y gagner.

Alors:
Avec celui ci, ça passe sans désyncro (plusieurs avances rapides jusqu'à fin du film , a chaque fois, son syncro)
Filesize.....: 694 MB (or 711,369 KB or 728,442,854 bytes)
Runtime......: 01:42:43 (154,075 fr)
Video Codec..: XviD
Video Bitrate: 841 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 96 kb/s (48/ch, stereo) CBR
Frame Size...: 720x416 (1.73:1) [=45:26]
I/L:86 ms (2.1 v.frames) Split: Yes
FPS:25.000

Avec celui là, uniquement le son, pas d'image !
Filesize.....: 644 MB (or 659,890 KB or 675,727,360 bytes)
Runtime......: 01:13:52 (110,804 fr)
Video Codec..: DivX 5.0
Video Bitrate: 1086 kb/s
Audio Codec..: 0x0055(MP3) ID'd as MPEG-1 Layer 3
Audio Bitrate: 128 kb/s (64/ch, stereo) CBR
Frame Size...: 720x416 (1.73:1) [=45:26]
I/L:None or Not Determined Split: No
FPS:25.000

Pour celui qui fige la platine je vais voir si BFrames

Je continue l'enquete demain matin.

Bonne nuit

[ahdiddum]

Salut ! Pour Patrice21 ou Scirocco : pouvez-vous expliquer la manip avec VirtualDubMod (Video Stream Copy et Audio Stream Copy) pour remédier à la désynchro ??
ca m'intéresse !
merci !

[Segamaniac]

Y a vraiment de koi s'arracher les poils....
Bon sang, 25 fps I/L 40ms Yes , Divx5,Mp3 128k...
Et c'est décalé !!!! Son qui prend de l'avance durant le film (7 s = 1h)
Test avec + de VFrames (10), sans chgt
Test avec baisse des FPS (24.95) sans chgt son qui grésille ?!
Test avec 64 k mp3 sans chgt...
PAr contre ce brave VDub est + précis dans les infos. fichier, on a la durée preload et le nombre de chunk audio , qu'est ce que le chunk et qu'elle influence a t'il ???
Je continue mes recherches.
@+

[patrice21]

File
Open video file
toto.avi (par exemple)

Video
sélectionner "direct stream copy"
(normalement le stream audio doit etre par défaut en dirtect stream copy)

file
save as
toto2.avi

cela a réglé mes problèmes de coupure audio et décalages sur plusieurs divx

[ahdiddum]

Ca ne marche pô...
disons que le fichier final est exactement le même
Il me semblait avoir lu plus haut que le second fichier devait faire quelques megas de plus, or ici il n'en est rien, la taille (et le décalage!)=IDEM
J'ai pourtant appliqué la manip ci-dessus, et j'ai même rajouté l'option "Change so video and audio durations match"
Qq a une idée ?

[f@bek]

[Segamaniac]

Pareil, essentiellement sur mes propres DivX...
On doit être des tanches de l'encodage
Je continue mes essais.
=> Pour Scirocco, je vais voir ce que je peux faire.
@+

[Scirocco]

Ca y est ! J'ai trouvé le pb qu'il y avait sur les deux derniers fichiers AVI qui continuaient à planter : dans les deux cas un pb d'encodage dans le stream audio :
- Un stream MP3 VBR : 2 frames audio cassés
- Un stream AC3 avec beaucoup de "CRC errors"
Donc tout va bien

Par contre, j'aimerai bien comprendre pourquoi ça plante chez vous (Segamaniac, Ahdiddum et F@bek). On peut passer en revue les logiciels qu'utilise chacun de nous pour encoder ses DVD. Je commence:

----------------------------------------------------------------------------
* Création d'un divx 5.X avec stream MP3 (1 CD par film)

- Divx4Bitrate 2.4.2 :
Estimation du bitrate video nécessaire pour un CD à 702Mo. Je place le bitrate audio à 128kbps pour un film <100mn et à 112kpbs pour un film <120mn et 96kpbs au-delà.

- FlaskMPEG 0.7.8 :
Pour la vidéo: Crop, Resize en fonction du bitrate video calculé ci-dessus pour avoir QF autour de 0.175), Encodage divx 1 pass quality-based (règlé entre 95% et 98% selon la longueur du film, pour ne pas manger trop de place sur le disque) + écriture du fichier LOG
Pour l'audio: Encodage MP3 CBR 96 ou 128 selon la longueur du film, Compression de dynamique selon les variations de la bande-son

- EKG :
Analyse de la taille des frames, Réduction du taux pour le générique et les scènes considérées comme "faciles" (textures simples, notamment), Sauvegarde du fichier LOG modifié

- VirtualDubMod 1.5.10.1 (attention je répète le 1.5.4.1 est buggé) :
Pour la vidéo: Fast recompress, Encodage divx Nth pass avec utilisation du fichier LOG précédent, Bitrate fourni par Divx4Bitrate + 1.5% (généralement ça tient, grâce à la réduction de l'overhead), Psycho light, Keyframes 300, Threshold 50%, Bframes et GMC
Pour l'audio: Direct stream copy, Preload correspondant à 10 frames (400ms en 25fps, 417 en 23.976fps), Interlacing 10 frames

En trois manips, c'est plié avec une qualité hyper-nickel. Personnellement, je trouve ma technique beaucoup plus simple (et beaucoup plus rapide) que celles expliquées dans la plupart des tutoriaux. Surtout celles avec des usines à gaz comme GordianKnot.

----------------------------------------------------------------------------
* Création d'un divx 5.X avec stream AC3 (2 CD par film)

- Divx4Bitrate 2.4.2 :
Estimation du bitrate video nécessaire pour deux CD à 702Mo avec un bitrate audio à 320 ou 384kbps (cf. ci-dessous)

- FlaskMPEG 0.7.8 :
Idem sauf que le resize est fait pour avoir un QF autour de 0.250 et que l'audio est demuxé en fichier AC3.

- Besweet 1.4 :
Si le bitrate initial est à 384, réduction à 320. Si le bitrate initial est à plus de 384, réduire à 384 (la différence est ABSOLUMENT inaudible). Pas de compression de dynamique (on peut le faire sur le lecteur et/ou l'ampli)

- EKG :
Idem que plus haut

- VirtualDubMod 1.5.10.1 (attention je répète le 1.5.4.1 est buggé) :
Pour la vidéo: Idem sauf bitrate fourni par Divx4Bitrate - 2% (l'idée est d'avoir un fichier légèrement inférieur à 2 CD afin d'avoir un peu de marge pour pouvoir couper à la fin d'une scène et pas au milieu)
Pour l'audio: Sélection du fichier AC3, Direct stream copy, Preload correspondant à 10 frames (400ms en 25fps, 417 en 23.976fps), Interlacing 1 frame (attention avec AC3, un autre I/L que 1 génère une désynchro presque systématique)
----------------------------------------------------------------------------

[f@bek]

[Scirocco]

J'ai oublié: j'ai fait un certain nombre de tests ce week-end avec des fichiers avec un split=no. Je confirme d'ailleurs que la manip que j'ai proposé pour obtenir des split=no ne marche pas à tous les coups Par contre, en coupant 1ms en début de flux (avec MP3TrimPro ou MP3DirectCut) et en remultiplexant avec VDM avec I/L à NO, ça marche... parfois

En tout cas, j'ai écouté la tête de lecture pour les fichiers avec split=no (en coupant le son de la télé ça marche mieux) et il s'avère que tous ne sont pas traités de la même manière: pour certains on entend clairement la tête qui bouge de manière régulière, pour les autres, c'est comme pour les split=yes, on n'entend rien.

REM: Contrairement à ce que j'ai dit dans mon tuto, VDM met le stream audio en DEBUT de fichier pas à la fin, donc c'est surtout vers la fin du film que la tête fait du hip-hop.

Et c'est là qu'intervient Segamaniac ! Glorifié soit ton nom, jusqu'à la 777e génération !

Dans un post précédent, il disait que VDM était plus précis que Gspot, car il donnait le nombre de chunks audio (dans File Information). J'avais complètement oublié ce détail. Effectivement, pour les fichiers identifiés comme I/L=none par Gspot, VDM trouve 1 chunk (ce qui est logique). Pour les fichier identifiés Split=Yes, VDM trouve pleins de chunks (ce qui est logique aussi). Et... roulement de tambour... pour les fichiers qui sont identifiés comme Split=No, VDM trouve parfois 1 chunk et parfois plein de chunks. Et comme prévu, ceux dont on entend bouger la tête de lecture ont bien 1 chunk, comme les I/L=none.

Bref, que Gspot se planterait parfois dans son analyse ça ne m'étonnerai pas J'ai fait un mail à l'auteur...

On avance, on avance...

[f@bek]

[Segamaniac]

[f@bek]

[Scirocco]

F@bek: Excellente ton idée d'ouvrir le capot du lecteur pour voir la tête Si la tête ne bouge pas dans tous tes exemples avec Split=No, il n'y a que deux raisons possibles:

- Soit les chunks audio sont bien physiquement intercalés entre les chunks video. Mais dans ce cas, pourquoi Gspot dit-il Split=No ? Est-ce un bug de Gspot ? Possible car VDM identifie plusieurs chunks pour certains fichiers avec Split=No.

- Soit tout l'audio est bien en début du fichier AVI mais la platine possède un buffer audio suffisant pour mémoriser tout le stream et ne plus avoir besoin d'y accéder, ou alors très rarement. C'est une hypothèse plausible, car un stream audio MP3 sur un CD dépasse rarement 100Mo. Donc même avec un buffer aussi petit que 32Mo, on n'a que 3 accès à faire pour lire la totalité de l'audio.

Test pour F@bek: Essaye de créer un fichier AVI avec un gros stream audio (par exemple, encodé en PCM au lieu de MP3 pour avoir un audio à 300 ou 400Mo) toujours avec Split=No. Si la tête ne danse toujours pas, ça veut bien dire qu'il y a entrelacement audio/video car je n'imagine un buffer de 512Mo sur une platine à ce prix.

-----

Résumons où on en est. Je fais une série d'affirmations, que je n'ai pas encore toutes vérifiées mais que je vais tester rapidement. Je mets des "???" sur les affirmations qui sont encore des hypothèses (plus ou moins plausibles). Si quelqu'un a un exemple qui met en doute une des affirmations, qu'il se manifeste pour qu'on converge plus vite.

a - Tous les fichiers avec I/L=none plantent ???
b - Tous les fichiers avec I/L=... (nombre entier) et Split=No marchent
c - Certains fichiers avec I/L=... (nombre entier) et Split=Yes marchent, d'autres plantent
d - Tous les fichiers avec I/L=... (nombre fractionnaire) et Split=No marchent ???
e - Tous les fichiers avec I/L=... (nombre fractionnaire) et Split=Yes plantent ???

Toutes ces affirmations sont pour un codec audio MP3 en CBR (on verra pour le VBR plus tard).

[f@bek]

[Scirocco]

Je sens qu'on brûle

Il y a effectivement quelque choses de bizarre avec les chunks audio. Sur un même fichier AVI de 19 secondes, j'ai réussi à faire varier le nombre de chunk entre 1 et 292, simplement en modifiant l'entrelacement, ou en demuxant/remuxant l'audio avec différents logiciels. Evidemment sur un film aussi court, la désynchro est difficile à constater, mais c'est clair que le temps d'initialisation avant la lecture est différent.

De même, j'ai repris mes anciens CD que j'avais réussi à faire marcher en modifiant le facteur I/L avec VDM. Avant la modif, le nombre de chunks tournait régulièrement à plus de 200000, après la modif, ce nombre était compris entre 1 et 250 maximum.

Conclusion (provisoire) : quand il y a trop de chunks audio, la lecture plante sur les platines de salon.

Question 1 : Est-ce que tout le monde a bien un faible nombre de chunk sur les CD qui marchent et un grand nombre sur ceux qui plantent ?

Question 2 : Quelle est la manip dans les logiciels qui fait modifier le nombre de chunks ?

Si la réponse à la question 1 est "oui" pour tout le monde, et si on trouve une manip systématique pour la question 2, je crois qu'on aura le Graal.

[Scirocco]

Bon ben après quelques tests supplémentaires, je ne suis pas sûr que ce soit la bonne piste...

Le nombre de chunks audio fournit par VDM a l'air d'être une belle pagaille. Exemple, sur le MEME fichier AVI de 9mn30:

VDM 1.5.10.1 donne : 15883 chunks
VDM 1.5.4.1 donne : 27602 chunks
VD 1.5.9 donne : 119 chunks

?????

[Segamaniac]

Pas simple en effet, ce dont je suis presque sur, c'est que lenombre de chunk est lié au bitrate audio et au I/L.
En résumé j'ai 17 chunk 128 K I/L =10 et 33 chunk 64 K I/L =10 et 319 chunk en 64 k I/L =1
Dans ce cas là c'est 1I/L=40 ms.
Bien sur je parle du même fichier.
Ce que j'ai remarqué c'est que quand en divise le nombre de sample par le bitrate par le nombre d'image on obtient un nombre qui correspond (à priori) à 2 fois le fps/10.
Quand c'est pas vrai, le son est décalé.
J'ai testé 10 divx I/L 1=40 ms fps 25.
Ces 10 fonctionnent sans décalage et donne 5
Dès qu'on se décale à 4.98 le son est décalé...( j'en ai un à 4.995 qui marche).
1 s d'audio = 16000 sample, ça permet de savoir à priori le nombre de secondes à rajouter au flux audio.
Attentio, c'est basé sur mes tests d'hier, peut etre pas parole d'évangile.
Mais...C'est une piste.
@+

[Scirocco]

Bon, ça bouge plus trop ici. Quelqu'un d'autre a fait des tests ?

[Segamaniac]

C clair
Par contre , peux tu voir si tu constates la même chose que moi?
Apparemment, le birate vidéo a une influence aussi...
@+

[Scirocco]

Mon problème est que je n'ai plus de fichier qui foire sans que je puisse le corriger (soit c'est un I/L pourri qui vire avec VDM, soit c'est des bad frames dans l'audio que je corrige avec CoolEdit). Je suis donc preneur d'un sample résistant à tous les antibiotiques connus.

[Scirocco]

Mon problème est que je n'ai plus de fichier qui foire sans que je puisse le corriger (soit c'est un I/L pourri qui vire avec VDM, soit c'est des bad frames dans l'audio que je corrige avec CoolEdit). Je suis donc preneur d'un sample résistant à tous les antibiotiques connus.

[Segamaniac]

[Scirocco]

[Segamaniac]

[Scirocco]

A priori, encoder un MP3 avec un bitrate défini à priori n'est pas possible. MP3 ne permet d'utiliser qu'une série limitée pour les tailles des frames (correspondant aux bitrates multiples de 16, sauf qu'il y a certain multiples de 16 qui manquent, j'ai jamais compris pourquoi). Dans le cas d'un VBR, chaque frame peut avoir son propre bitrate mais toujours choisi dans la série des bitrates prédéfinis. Ce n'est qu'en faisant la moyenne sur l'ensemble du stream, qu'on obtient au final des bitrates non multiples de 16.

Donc si tu veux un bitrate moyen donné (disons 123 à titre d'exemple), la seule solution est prendre les deux bitrates autorisés qui encadrent ta valeur, en l'occurence 112 et 128 et d'exprimer le bitrate voulu en coordonnées barycentriques par rapport aux deux voisins. En clair,

123 = x*112 + (1-x)*128 avec x compris entre 0 et 1

Dans ce cas précis, on trouve : x = 5/16

Donc tu prends ton stream audio et tu le split au 5/16e de sa longueur.
Tu encodes la partie 1 avec un VBR à 112 (on imposant min=112 et max=112), la partie 2 avec un VBR à 128 (idem) et enfin tu fusionnes les deux fichiers pour générer un stream complet avec un VBR moyen de 123. Le résultat est évidemment moins bon qu'un VBR classique à 123 puisque le bitrate ne dépend plus de la complexité du flux audio comme dans un VBR normal. Mais c'est le résultat qui compte. Avec mp3DirectCut, tu peux tout faire en restant en format natif MP3 tout au long des manips.

Attention, tu ne peux pas encoder les 2 parties en CBR car la fusion de deux CBR à bitrates différents n'est pas autorisée (à vérifier tout de même, car entre la norme et la réalité il y a souvent de la souplesse)
---
Sinon, toi qui as une LifeTec, as-tu testé le remède du radiateur pour corriger la désynchro audio/video ?

[calim27]

Salut à vous,

[camomille]

[Segamaniac]

Boaf...
J'ai un peu laché l'affaire, je désespère.
En fait, j'ai un peu les boules après ma Lifetec, j'ai un son pourri quelque soit la soirtie utilisée (comme si le son saturait, grésillait)...
platines ont été achetées autour de moi, et il n'y a que la mienne qui pose pb...

Mais bon.

[Segamaniac]

J'ai réussi !!!!!!
En fait, les fichiers "type" à pb ETAIENT mes divx wma passés en divx mp3.
En fait vdub n'encode pas pile poil au bitrate attendu d'où taille de donnée non approprié d'où stream de mauvaise taille d'où décalage son progressif !!!!!!!!!!
Alors, pour faire simple, je sépare l'avi d'un coté la vidéo de l'autre le wav que je réencode (j'ai utilisé dbPowerAmp, il doit y en avoir un tas d'autre) au bitrate et échantillonage prévu (via lame Mp3).
Soit je réassemble le tout avec Nandub et j'obtiens un split NO et si je veux un split yes, je le reconverti avec Vdub (qui au passage repasse le flux audio en CBR et non plus VBR).
Attention, un petit recalage est parfois nécessaire pour bien caler le démarrage de la vidéo par rapport à l'audio (delay audio track... dans vdub).
Bref, je continue avec mes 40 divx concernés et je vous tiens au jus si ça se confirme.

Rappel: Pour savoir si on aura un décalage avec un divx je divise le stream par le débit et par le nombre d'images.
Si fps = 25 on obtient 5
Donc à priori.
Enlever 0.25 par fps en + (donc 20 fps = 6.25 et 30 fps = 3.75)
@+

[ahdiddum]

Bien intéressant, segamaniac. Tu as du nouveau ?

[Segamaniac]

Et bien jusqu'à présent (4 divx) , ça marche tjrs.

Mais par contre je conseille vivement le passage en split yes via vdub, sinon, ça saccade grave par moment en split no (Scirocco nous avait prévenu).
Voilà, je continue mes conversions.
@+

[Scirocco]

Excellent, Segamaniac ! Dis-moi si j'ai bien compris :

AVANT : Pour un fichier avi avec un stream audio divx (ou hack wma, puisque c'est la même chose), tu faisais la chose suivante:
* Video -> Direct Stream Copy
* Audio -> Full Processing + Compression MP3 CBR

et tu avais le décalage

MAINTENANT : Tu fais la manip suivante:
* Audio -> Demux ou Save Wav
* Recompression avec dbpowerAmp en MP3 CBR
* Remux avec VD

et il n'y a plus de décalage C'est bien ça ?

Ca expliquerait pourquoi je n'ai jamais eu le problème, car je fais systématiquement mes conversion MP3 en demuxé, pour pouvoir le passer à MP3Gain afin d'analyser la dynamique.

Néanmoins, j'ai plusieurs questions :

- Quel est le codec ACM que tu utilisais avec VD : Radium ou ACM Lame?
- Y a-t-il une modif importante du nombre de chunks audio entre le réencodage fait directement avec VD et celui fait par remux depuis le fichier ?
- J'ai toujours pas compris le calcul exact que tu fais. D'après ce que je lis c'est le nombre de bits *AUDIO* total (est-ce que tu le calcules ou tu le récupère par un soft ?) divisé par le bitrate *AUDIO* divisé par le nombre de frames *VIDEO* ? Ca me semble pas cohérent...

[Segamaniac]

[cferiau]

Soit je suis bouchée ou je suis mal réveillée , mais je ne comprends pas ton calcul.
Pourrais-tu donner un exemple plus détaillé?
Merci pour ta réponse.

[Segamaniac]

NP
Alors quand tu ouvres un avi avec vdub, si tu regard ds File Information tu obtiens plusieurs données interressantes.
Dont la longueur audio ("length") exprimée en stream qui correspondà la durée audio, juste en dessous, il y a le débit (128 kbps...)
Et tout en haut la résolution, le framerate (25 fps...)et juste en dessous le nombres de frame.
Par exemple:
12800000 streams à 128 kbps et 20000 frames à 25 fps.
ça donne 12800000/128/20000 = 5.
Si fps est à 25.
Voilà.
@+

[cferiau]

Salut.
Merveilleux, j'ai compris .
J'obtiens (mais sous VirtualdubMod) 4,988... sur un divx dont le son se décale.
Je vais maintenant appliquer ta méthode pour résoudre ce problème de décalage du son: j'espère que cela fonctionnera .
Edit: je viens de faire un essai, il ya toujours un décalage .
Ca m'agace, il faut que j'y arrive . A+.

[CHFR972]

[Segamaniac]

[cferiau]

J'ai réessayé 2 fois et j'ai enfin obtenu 4,99: est-ce correct?
Par contre, j'ai fais un essai avec ce même film, je l'ai sauvegardé sur un DVD+RW avec 2 versions différentes: la 1ère version est celle qui a été faite sous Nandub (donc Mp3 VBR) et la 2ème, c'est le film réencodé en "directstream" sous virtualdub (donc avec un MP3 CBR).
Sur mon lecteur (Philips 737), le 1er fichier passe nickel alors que le 2ème plante la machine, et lorsqu'il passe je n'ai pas d'avance rapide. Je croyais que les divx avec le son en MP3 VBR passaient mal (lu sur ce forum): pourrais-tu m'éclairer? Merci.

[sounou]

Eh!! les copains vous êtes fabuleux !!!! Quel talent !!!!

mais alors pour vous suivre quand on débute il faut faire polytechnique !!

Pensez-vous dans vos instants perdus que dès que tout ceci vous semblera au point, mettre un tutorial pour nous permettre à nous, vulgaires incultes de nous dépatouiller ??

Merci à tous et à la prochaine