Log in

View Full Version : Trial-Error to sync weird videos.


alexwrc
20th August 2007, 23:53
Tools and target:

Vobs analyzed in DGindex > Megui encoding H264 (Avisynth scripts) + Belight encoding AAC > Megui muxing all in mp4 container

This must work, I used a dozend of programs after reading I don't know how many Faqs, guides, forums and the whole Google and search engine. I did it, but anything worked with these car DVDs wich are like a nightmare or simply i'm too confused now.

I know with most of them all goes right, but I have a few of strange ones waiting to be fixed, so this thread is my last chance to do it. I'm going to try to be as clear as possible.


The main problem is audio get out of sync sometimes (As a million of threads opened before), with no logical reason. In example:

- Demuxed audio in DGindex with no delay > After muxing: delay.

- Demuxed audio in DGindex with delay value > After muxing with correction: delay

- Audio and video tracks with different length > After muxing: Many of them with NO delay (Even talking about 20 seconds WTF!!)

- Audio and video tracks with different length > After muxing with correction delay and no value added: delay in both

So the only solution I found is trial-error method to set the correct delay value manually. But Megui need 5 minutes average to mux the whole video, just to know if delay happens at the end. If you need 10 trials, you need an hour of wasted time to "fix" the sucking delay issue.

Before this change to H264, I always used Xvid and VirtualDub, encoding video and audio all together. I was able to select a part of the whole video at the end to encode it in just 30 seconds, or just previsualize it in real time to see if there was any delay. Now in Megui, or in any kind of compatible H264 GUI I can't select anything, transforming an usual correction in a pain.

Well, I think every DVD is different, I know it, so I'm not expecting miracles or the ultimate solution.

Hope someone can help me now. I can't believe a simple and common delay issue won't be supported to be fixed in so powerful programs. I've checked the main download page at Doom9, and no one helped me as well.

Any advice will be really appreciated. If you need any log please let me know it. Thanks in advance.

Atak_Snajpera
28th August 2007, 11:01
wait for RipBot264 v1.4.0 :) In new version you will be able to preview script and check if audio delay value is set correctly. It's working well in my beta so far. I understand your pain because sometime ago I was trying to rip Kung-Fu Hustle and DGindex returned to high delay value (80ms more than it should). All kicks ,punches and so on were slightly out of sync.

alexwrc
28th August 2007, 12:57
Thanks a lot for your reply. I thought this would be died. That's what I need, an adjustment in real time when usual methods fail. I'd like to suggest a muxer as well with the same feature, because I have a few files ready to be muxed when the delay issue will be fixed with a tool like yours. I tried your program and it's very simple and quick, and I was pleased with the stylish design as well.

I don't know if this is normal, but all weird videos I have, has a delay wich is being added proportionaly. In other words, at the start all is right and the audio is being lagged to the finish.

I also used the alignedsplice script, and each vob get out of sync in the whole video like it were sliced. So I think this (my) delay is different of the normal delay wich "move" the audio track.

Regards

Atak_Snajpera
28th August 2007, 13:15
I don't know if this is normal, but all weird videos I have, has a delay wich is being added proportionaly. In other words, at the start all is right and the audio is being lagged to the finish.

It occurs when you set wrong FPS value. For instance 24fps instead of 23.976fps and so on

alexwrc
28th August 2007, 14:27
Megui and VirtualDub select the framerate automatically, unless you change it. I don't usually add the fps value in my avs files, and I think it's not wrong.

I read something about changing the audio tracks framerate, but it's the same problem of adding a random delay value.