Recenze  |  Aktuality  |  Články
Doporučení  |  Diskuze
Filmy a seriály, streamovací služby
Televize  |  Projektory
Audio a domácí kina
Multimediální centra  |  Ostatní
Svět hardware  |  Digimanie
Svět mobilně

Kontrola synchronizace audio a video

Vikina (4)|9.5.2006 17:53
Kamarádi, už jsem z toho zblblá. Pořád se mi nějak rozchází zvuk s obrazem při nahrávání do MPEG2 na kartě TV@Anywhere Plus. Experimentuju se změnou bitrate pro audio na 48k, ale stejně se to nahraje jen 44k i se změnou bitrate při prvním stříhu programem Honestech VideoEditor Easy.
To zblbnutí je z toho, že si už možná sugeruji, že ten herec otvírá či zavírá pusu dřív než by měl - a to i u českých filmů v délce na 1 hod.
Existuje nějaký free prográmek, který by zobrazil souběh či rozdíly audia a videa aby to mé trápení bylo něčím měřitelné ???
Určitě mi pomůžete, tvz. kamarádi a přítelové teď v květnu tokají jak Mácha tak pro tyto věci jsou úplně blbí a když už nic tak aspoň porno, ale tam zvuk není třeba. Bábi mi vykládala, že když byla mladá mladinká běžel za komunistů před r. 1968 Bergmanův film Mlčení ....
My jsme to už měli jako školní film a byla to černobílá nuda.
Pac, pac a na Petřín.
Whitejoker (616)|11.5.2006 11:12
takže krátce a stručně:
když ten soubor otevřeš ve VirtualDub-u, v menu vybereš informace o souboru (soubor-informace o souboru/file-file information), tak by se tam mělo objevit, jak je dlouhé video a zvuk.
Nejsem si teď úplně jistý jestli to zobrazuje délku v časových jednotkách nebo ve framech/vzorcích - jsem v práci a nemám žádné video na vyzkoušení.
Když se bude délka výrazně lišit - použít postup uvedený v článku - oddělit zvuk ve VD, zvuk zpracovat samostatně v CoolEdit-u (on sice není free, občas otravuje, že není free, ale požadované akce stejně provede) - upravit délku podle videa a pak to zase spojit ve VD.
pozdravuj na Petříně

edit: VD zobrazuje délku i v časových jednotkách
Fantas! (3016)|11.5.2006 12:16
Vegas. Hned to vidis vizualne!
Whitejoker (616)|11.5.2006 12:22
Ale ten většinou není free
Fantas! (3016)|11.5.2006 13:21
Whitejoker
sorry, sem si nevsiml... :-I
Vikina (4)|15.5.2006 23:09
Kluci, děkuji. Zejména spec. Whitejokerovi, který mne nahodil na správnou kolej. Když tu informaci o souboru zobrazím v VirtualDub MPEG2 1.6.11, tak sice mezi frame pro video např. 190000 a frame pro audio 280000 je až tragická propast, ale u audia při 44kHz a 224kLayer je údaj skew =
-0,40 ms, někdy i 0, a to by mohlo být slušné, je-li skew rozdíl na celý film (nebo jen na 1 frame?).
Tak ještě tuto maličkost a už si dám klid a pokoj.
Díky všem.
StD (8612)|16.5.2006 07:17
Vikina: Opatři si PVAStrumento, Womble Mpeg Video Wizard a případně i ProCoder2 a budeš mít po starostech... :-D
vlada (3470)|16.5.2006 12:07
Vikina
Hele já možná budu trapnej, ale jak si představuješ, že ten program pozná, jestli zvuk sedí? Žádnej program neví, kdy herec otevírá pusu a kdy se má ozvat zvuk. Tu synchronizaci musíš zkontrolovat Ty, žádný program Ti s tím nepomůže. Dokonce ani Vegas ne a překvapivě ani Womble.

Na zkontrolování, jestli jsou video a zvuk stejně dlouhý, poslouží ideálně program MediaInfo. Pokud v něm otevřeš to video a zvolíš View -> Tree, můžeš se podívat, kolik ms má video a zvuk. Pokud se to liší, je to špatný. Proč se to může rozcházet a co s tím si můžeš přečíst v mym návodu.
StD (8612)|16.5.2006 12:20
vlada: No vidíš, a právě že "řekne" - stačí si pustit PREVIEW vstupu i výstupu... :-)-
Vikina (4)|16.5.2006 21:00
To: vlada
Konečně, hřebík na hlavičku. Právě po něčem jako je to Mediainfo jsem toužila ... kromě tužeb jiných.
Na závěr jen dodám: prvotní nahrávky přes TV@anywhere plus ve formátu mpeg2 vesměs při filmu 90 min zpožděny při 44kHz audio o -3600 ms.

Když nahrávku proženu (kvůli vystříhání reklam atd) přes EASY VideoEditor od Honestech (smart rendering) je výsledný soubor již bez jakéhokoli rozdílu mezi video a audio. Pak to nechám autom. rozstříhat na několik částí pod 1 GB, aby to mohl číst "stolní" přehrávač Philips.

Tak ještě jednou díky a pěkné vlahé podvečery a večery všem a všady.
pee.tr (1208)|16.5.2006 21:04
Fantas!
sorry, že s tím zase otravuju, ale např. u mě rozdílná délka stop obrazu a zvuku neznamená nutně rozhozenou synchronizaci a naopak stejná délka stop neznamená, že je to nutně OK. Nevím sice jak to je možný ale je to tak.
vlada (3470)|16.5.2006 21:49
pee.tr
No ještě můžou bejt stejně dlouhý stopy posunutý vůči sobě absolutně. Taky se můžou postupně rozbíhat a sbíhat (což je ale poměrně vzácný). Naopak MPEG kontejner je schopný udržet synchronizované video a audio i když je jinak dlouhé. To samé umí i MKV nebo MP4. Jakmile to ale demuxneš, rozjede se to a už to nikdy nedáš dohromady. Netřeba snad dodávat, že takové video je potencionálním zdrojem mnoha problémů. Navíc tu je ta záludnost, že MPEG se tváří, jako že je správně synchronizovaný.
pee.tr (1208)|16.5.2006 22:47
vlada
nevím co přesně myslíš tím absolutně. Na začátku sedí jak vizuálně ve vegasu tak ve skutečnosti jako dabing a nakonci je třeba jedna delší a přesto sedí, nebo naopak stejné na dýlku a synchro nesedí. Mluvím o MJPEG+WAV
vlada (3470)|17.5.2006 06:59
Tím absolutně jsem myslel, že je to třeba celý šouplý o 1 vteřinu. Pokud máš MJPEG AVIs PCM zvukem, který sedí, ale mají jinou dýlku, musí být jedno z toho na konci ořízlé. Jinak to zcela logicky nemůže sedět.
pee.tr (1208)|17.5.2006 17:26
zřejmě to WinFast každý ukončí (video a audio stopu) v nestejným okamžiku. A pak je to tak, že je to rozdílně dlouhý, ale sedí to. Ale mimo to, žo to takhle občsa (ale jen málokdy) kde originál grab, tak dost často s e k těmhle nestejným délkám dostanu právě po synchronizaci. Ale jak už jsem tu jinde zmínil, záleží na tom co to je za nahrávku. Třeba takový Návštěvníci měli zvuk delší než video a sesynchronizování došlo až po zkrácení zvuku na tu míru, že byl naopak kratší než video stopa.
Bullback (352)|25.5.2006 12:15
Záleží na zvukovce a délce pořadu a softu současně, na první pohled řešitelné jenže prakticky s výměnou zvukovky je pak vše jinak.

Mě se teď rozchází zvuk (po výměně zvukovky)do 30 minut u bTV softu, po 1hodině do xxx už je to srovnaný. Tohle se mě zdá logický protože soft se snaží o jakési sesynchronizování na konci muxu.