Having some sync problems lately, I started wondering whether there might be anything simple and less time-consuming than tearing the mpg apart and putting it together again, either by the demux/remux sequence or by re-encoding by frameserving it to TMPGEnc+. The latter also takes away some of the original 'crispness' which the hardware codec seems able to bring to its recordings.
In fact, what happens is that the original recording usually is perfectly in sync, but that as soon as I start cutting something off at the end with either TMPGenc+ or Womble, the lot goes out of sync. Demuxing/remuxing has the same effect. Which is, in fact, what TMPGEnc+ does when Editing. And what then SVCD2DVD does again, even if the sound already is at 48K.
Suddenly I remembered this fairly new addition to the SVCD2DVD Options menu. Only, it was not that clear what it indicates.
"Audio sync offset for muxing
positive number: audio behind video
negative number: video behind audio"
Now, is this decribing the present situation, or the change you want?
I mean, if a guy or gal is seen to say one word which you hear when the camera/editor has switched to another person's face -audio at present behind video-, should I put in a positive or negative number to get them (back) in sync?
Hope my problem was formulated clearly..
+ Reply to Thread
Results 1 to 11 of 11
These options are for changing the sync, so they are not present
you would add a positive number to advance the audio
In fact, what happens is that the original recording usually is perfectly in sync, but that as soon as I start cutting something off at the end with either TMPGenc+ or Womble, the lot goes out of sync. Demuxing/remuxing has the same effect.
If after demux and remuxing it is still out of sync you need to reencode your audio (or complete mpg) to get a valid audio stream that won't run out of sync. read this guide for help. So the solution would be that SVCD2DVD reencodes the audio first to a complete .mp2 stream and the reencoded it to 48mhz. Cause if you use a flag so move the audio a few ms you got sync probs some where else. Starting the audio later of early then the video only helps if the audio is out of sync for the beginning and not when it gets out of sync. Which is mostly the problem with mpgs which you didn't make yourself.Greatings,
Originally Posted by yf2001usa
Five chunks are okay and in sync and stay that way. The second one of Tape 2 has the sync problems BUT NOT when I burned it as ISO onto an R/W. Then that one plays in sync, too, on my new Yamada DVX-6000.
BUT NOT when I burned it as ISO onto an R/W. Then that one plays in sync, too, on my new Yamada DVX-6000Greatings,
Hmm, I'm having trouble with the synch too, but I may have found a solution that can be implemented in SVCD2DVD to fix the situation automatically. I came to this since the surefire way described here is not a surefire way (synch did not get better even when reencoding completely in TMPEGENC) and after realizing that the synch was quite okay at the beginning and getting worse and worse to the end (off by 5 seconds).
So here it comes:
When I demux audio and video I check the exact times for each stream. Say, the video stream has a length of 42:55.239 (determined by Virtual Dub) and the audio stream a length of 42:50.815.
One can see the big difference of 5 seconds that the video will run behind the audio. The idea is to stretch the audio to match the video length.
This can be done with besweet which offers a parameter to change the framerate (parameter -ota( -r oldframerate*1000 newframerate*1000 ).
The only thing that has to be calculated is the new framerate for the audio and that is quite easy:
given that the length is the number of frames divided by the framerate and that the number of frames stays constant one can build this formula:
newFramerate = length audio * old framerate / length video
So in the example given that is an NTSC Framerate of 29.97 we get:
newFramerate = 2570.815 * 29.970 / 2575.239
newFramerate = 29.918
this used in besweet for audio reencoding with param -ota( -r 29970 29918 ) produces a nice little mp2 that is, when remuxed with tmpegenc, perfectly in synch with the video.
This has worked in all cases I had trouble with synch. So if chrissyboy could determine the length of video and audio he could put in a new feature to automatically fix synch problems during the sampling frequency change with besweet.
Worth a try? What do you think?
Is it really that easy?
I'll give it a try. Thanks for the idea buddy.
Originally Posted by autolycus
And guess what. Both give the same value! I loaded the problematic MPG-1 I talked about: VDub gave 1:03:47.920, CoolEdit 63:47.920. It would seem that there is nothing for BeSweet & Co to do..
Is there a way to measure the duration of an MPA or MP2? CoolEdit does not load the critters.
autolycusGuestHow do you measure the length of the audio part? If I save it out as PCM WAV uncompressed and load the result into CoolEdit, I get it down to thousandth's of a second. Just like VDub does for the video.
Looks like your mpeg does have yet another synch problem.