Synch Issue with Frame Rate Variation

[bsmith1593]

I previously posted a thread (quite sometime ago), asking for help with decimation of duplicate frames in a video that had no decimation pattern. I thought it unnecessary to bump the thread since it is quite old. But, after many suggestions, I decided to go through the video frame-by-frame and manually decimate every duplicate frame in an overrides file. I achieved this, and the video came out quite smooth. The only problem is that the audio is not synched with certain sections of the video. I am thinking this is due to the fact that some sections of the video are 26 fps, 24 fps, and other variants. Am I right? If so, or if not, could someone try to help me with this? I have spent a long time trying to figure this out, but haven't yet. You might wonder why I'd spend so much time on just one music video, but I guess I'm a perfectionist :rolleyes:. I would really appreciate it if someone could help me. I will provide the video and the scripts I am using on it.

Video:
http://eva.adriels.com/miscellaneous/VTS_01_1.VOB

AVS Script:
mpeg2source("C:\PROGRA~1\GORDIA~1\D2Vs\Behind These Hazel Eyes.d2v")

AssumeTFF()
Telecide(post=0)
TFM(slow=2,cthresh=255,ovr="bthei.txt")
TDecimate(cycle=1393,cycleR=206,ovr="bthed.txt")

De-interlacing Text File:
41,44 +
182 +
192 +
315 +
322 +
362 +
370,372 +
687 +
759,761 +
768,769 +

Decimation Text File:
1 -
9 -
16 -
24 -
31 -
33 -
52 -
60 -
67 -
75 -
82 -
90 -
97 -
105 -
112 -
119 -
127 -
131 -
139 -
146 -
153 -
161 -
168 -
176 -
180 -
196 -
203 -
208 -
218 -
225 -
233 -
239 -
246 -
254 -
261 -
268 -
273 -
280 -
288 -
297 -
302 -
307 -
311 -
333 -
341 -
348 -
354 -
360 -
370 -
381 -
388 -
396 -
403 -
411 -
419 -
426 -
434 -
441 -
449 -
456 -
464 -
471 -
479 -
486 -
494 -
501 -
508 -
516 -
523 -
527 -
534 -
542 -
550 -
557 -
563 -
572 -
579 -
587 -
594 -
597 -
605 -
612 -
620 -
627 -
635 -
643 -
650 -
655 -
663 -
671 -
677 -
687 -
691 -
698 -
706 -
709 -
713 -
717 -
725 -
732 -
740 -
747 -
755 -
759 -
768 -
771 -
779 -
786 -
794 -
800 -
809 -
816 -
821 -
827 -
835 -
842 -
850 -
856 -
858 -
865 -
873 -
881 -
888 -
896 -
903 -
908 -
912 -
920 -
927 -
935 -
942 -
950 -
957 -
964 -
972 -
979 -
984 -
987 -
995 -
1002 -
1010 -
1017 -
1025 -
1031 -
1036 -
1041 -
1046 -
1050 -
1058 -
1065 -
1072 -
1080 -
1085 -
1087 -
1095 -
1102 -
1107 -
1113 -
1120 -
1128 -
1134 -
1140 -
1147 -
1155 -
1162 -
1170 -
1175 -
1182 -
1190 -
1197 -
1204 -
1209 -
1214 -
1219 -
1224 -
1229 -
1234 -
1239 -
1244 -
1249 -
1254 -
1259 -
1264 -
1269 -
1274 -
1279 -
1284 -
1289 -
1294 -
1299 -
1303 -
1308 -
1313 -
1318 -
1323 -
1328 -
1333 -
1343 -
1350 -
1358 -
1365 -
1370 -
1374 -
1379 -
1384 -
1389 -

NOTE: The reason that the cycle is set to 1393 is because I've only de-interlaced and decimated frames up to frame 1393.

[Guest]

Performing irregular decimation is the cause of your desync. To explain I first describe a simple but extreme case.

Consider a clip with 300 frames played at 30fps. If you decimate every 5th frame (i.e., 60 frames) and play it at 24fps, it will remain in perfect sync. Now consider decimating the first 60 frames and leaving the rest and playing at 24fps. It will start 2 seconds out of sync and gradually regain sync as the movie plays and reach correct sync only at the end.

Yes, it's an extreme example, but it illustrates how irregular decimation can cause desync. If you set a large cycle and then decimate irregularly in the cycle, you will get desync.

Every time you decimate a frame before one is due for decimation according to the regular cycle, you create ~33ms desync. Every time you neglect to decimate one you create ~33ms desync the other way. You will have a random walk of total desync and the longer the cycle the bigger the desync can become.

The problem is that the audio was synced to this clip with irregular duplicates. You understandably want to get rid of all the duplicates. But you can't, because you cannot avoid the resulting desync.

Also, you will get an oddball framerate by decimating like that.

I recommend choosing some reasonable cycle size so that the desync cannot accumulate too much and then just accept some remaining dups. You cannot get a perfect result.

Finally, you don't need two field matchers.

[bsmith1593]

Performing irregular decimation is the cause of your desync. To explain I first describe a simple but extreme case.

Consider a clip with 300 frames played at 30fps. If you decimate every 5th frame (i.e., 60 frames) and play it at 24fps, it will remain in perfect sync. Now consider decimating the first 60 frames and leaving the rest and playing at 24fps. It will start 2 seconds out of sync and gradually regain sync as the movie plays and reach correct sync only at the end.

Yes, it's an extreme example, but it illustrates how irregular decimation can cause desync. If you set a large cycle and then decimate irregularly in the cycle, you will get desync.

Every time you decimate a frame before one is due for decimation according to the regular cycle, you create ~33ms desync. Every time you neglect to decimate one you create ~33ms desync the other way. You will have a random walk of total desync and the longer the cycle the bigger the desync can become.

The problem is that the audio was synced to this clip with irregular duplicates. You understandably want to get rid of all the duplicates. But you can't, because you cannot avoid the resulting desync.

Also, you will get an oddball framerate by decimating like that.

I recommend choosing some reasonable cycle size so that the desync cannot accumulate too much and then just accept some remaining dups. You cannot get a perfect result.

Finally, you don't need two field matchers.
Thank you for your post. It was very informative and helpful. I guess I will just have to go with my previous recommendation for this video, and decimate 2 frames in every 15, and have some leftovers. I just didn't like the jerks caused by the duplicates every now and then. They seemed very noticeable to me at least. 2 in 15 will give me 26 fps, but that's the closest I can get. Also, I just thought that Telecide(post=0) corrected shifted fields. Some frames that were still interlaced weren't when I added TFM. Plus, I like how the de-interlaced image looks better than Telecide (whole image looks less deformed from the interpolation). Thanks for your help, I'll do a test up to frame 1393 now :).

Also, I'm not entirely educated on the many AviSynth filters out there, but is there a filter that effectively gets rid of residual combing? Right now I just add blend in vdub, but it takes away sharpness. As long as it's not too slow, I'm good. My computer currently had 256 MB of RAM, and about 5 GB of hard disk space left (this computer is AT LEAST 5 years old).

[thewebchat]

Vinverse is meant to remove residual combing (I think it uses a localised blur). There is a script version VinverseD in the MCBob script and a plugin version somewhere on tritical's site.