Sony X70 AVCHD et continuité des rushes longue durée

Un souci que je n'ai pas encore résolu simplement avec les rushes en AVCHD lors de prises de vues de spectacle : de multiples rushes sont générés (tous les 4 Go) et à la dépose sur la timeline d'Edus il existe un trou de 2 à 4 images .
Avec la X70 je pensais résoudre le problème en utilisant le log de Sony : "Content Browser" qui , après capture de la carte SDXC par ce log, analyse bien un seul grand rush au lieu de n .
Mais impossible de glisser ce grand rush dans le chutier d'Edius, comme je le fais avec les rushes XAVC ou XDCAM-ex qui eux assurent bien la continuité.

Si quelqu'un a déjà une solution ...

Marc

 

Là Marc je ne peux t'aider, pas de clips AVCHD de cette durée

Et si tu tentais de les assembler "que" deux par deux, A+B ; B+C ; C+D etc ...

en ne les chargeant que par deux morceaux à la fois ?

 

Et quelles différences aux niveau caractéristiques (Par Mediainfo) entre les rushes élémentaires issus du camescope et ceux assemblés par Content Browser ?

Je n'ai pas non plus de rushes longs pris avec le X70, mais les rushes courts passent bien sur Edius 7.5.

Olivier

 

Salut,

Ca donne quoi avec un copy /b ?

 

En pratique, c'est le cas avec tous les rushes AVCHD quels que soit la cam utilisée.
J'ai lu que la machine met des données "suite" à la fin du 1er enreg et debut du suivant.
Ces data sont mal interprétées par les log de montage (pas tous).
Dans les 2 dernieres images du 1er enreg l'image est OK mais le son absent.
Au debut du 2eme enreg , son et image OK, mais à 2 images d'écart du temps réel si on compare avec un enregistreur autonome en parallèle.
Au total 4 images/sons perdus.

Quand on tourne avec plusieurs cam pas trop de souci (à part la synchro), car une des cam va surement boucher le trou.
Mais le WE dernier j'ai tourné avec une seule cam (en Allemagne) et là je suis un peu coincé pour réinventer les images perdues.

La vue coté "Content browser" me donne bien une seule vignette pour 4 rushes réels, il fait donc bien virtuellement la concaténation.
Pour retrouver un rush parfait d'une heure, sans coupures, il faudrait que j'exporte avec ce log dans un fichier unique , ce qui est possible mais je vais perdre une génération et comme les conditions de lumière étaient difficiles, je me retiens ...

Quand je regarde le dossier de capture de la carte fait par Content Browser, il a généré des XML des .moff, ... en plus des m2ts.
Tout cela devrait l'aider à concaténer, mais je n'arrive pas à les glisser direct dans le chutier d'Edius.

TotalNewbie,
ton "copy /b" , ce ne serait pas du DOS par hasard ?
Si oui , la je crois que ça marche, je l'ai lu quelque part, mais je ne maitrise pas du tout cette langue

Marc

 

Oui c'est un héritage d'un temps où il n'y avait pas de souris et qui peut rendre de très bons services comme concaténer une série de fichiers (je me méfie des logiciels soit-disant intelligents et même pas foutus de réaliser un telle opération ultra basique):

copy /b ficA.mts ficB.mts ficC.mts fic.mts

copiera, octet par octet, les contenus de A+B+C dans le fichier destination sans aucune interprétation. (/b => binary)

 

"ton "copy /b" , ce ne serait pas du DOS par hasard"

Le DOS ça n'existe plus depuis belle lurette, c'est du langage de commande, tout simplement.
Il suffit d'ouvrir une fenêtre de commande (démarrer : executer : CMD)
et de vérifier la syntage de la commande COPY, par copy /?

Pour concaténer 2 fichiers :
copy /B fichiersrc1 + fichiersrc2 fichiercible

Mais la meilleure solution reste la concaténation par le logiciel Content Browser , qui dans ce cas ne devrait pas faire de réencodage.

Olivier

 

Je viens de faire un Export depuis l'image de la carte SD sauvegardée avec Content Browser, il me crée bien un fichier .m2ts en sortie , sans trou, mais réencodé ou pas, là je ne sais pas .

Marc

edit: j'ai regardé l'utilisation des proc pendant l'Export et tous à moins de 1% et les 10 Go sont traités en moins de 2mn.
Donc, à priori, il n'y a pas d'encodage sinon les temps seraient autrement plus longuets.