Deinterlacing Problem - QTGMC & NTSC Footage

[hickeyguy]

Just a quick update from me today. Everything is very good with the video. I love how it is looking, and don't think there is anything further to do, to improve more. I created a full render of the entire episode (took approx 2 and an half hours), and it looks great. You can see how EEDI3 was affecting some lines (small areas of close bends in letters) in the text, but it was really minor, so i'm not fussed about that.

I did run into one problem however - and I would like to know the proper way to fix this, as my method this evening has been rather complicated, and i'd like to simplify it if possible. The audio track seems to gradually go out of sync, playing slightly slower than the video. I did some digging into the different MediaInfo documents for each file (and each track in each file as well). The source video and encoded video run at 29.970fps, with a runtime of 21m34s - source has a bitrate of 5764kbps (VBR), and my render has a CBR of 9000kbps. The audio track in the source is 192kbps at 48.0Hz 16bits, 2CH, AC3 with a runtime of 21m34s (MediaInfo also says 31.250 FPS (1536 SPF)). My render's (plural) had a range of different options, as my first render was a Copy/Mux of this track, but it was out of sync.

I tried some delay options, but this made the beginning portion of the video out of sync (thus making the end side IN sync), so I figured it was some kind of speed/framerate problem. So I changed the Sample Rate from 48.0Hz to 44.1hz, which gave a better result - but still slowly became out of sync as the video progressed. So I tried using 'DVBPortal MP4 Multiplexer/Demultiplexer Version 0.9.3' to try and MUX together the audio, hoping it would do it differently (just hoping StaxRip did something wrong). I used different audio OUT options/settings in StaxRip using encoders Eac3to, ffmpeg & qaac, but couldn't figure out how to get the framerate to sync (maybe there is a code that might force a specific speed up). Somewhere in that chaos of a storm, MediaInfo gave me an audio track framerate for one of my renders that said 46.875 FPS (1024 SPF) (the original should be 31.250 FPS (1536 SPF), so one of these altered settings, maybe in Eac3to, changed the audio fps value).

By the way, in that MP4muxer program, it said the video track had a duration of 1294.127 seconds, and the audio track duration was 1294.656 seconds (there's a little difference there).

So what I did was import the video track (with troubled audio), and separately the AC3 source track - into Premiere Pro, and put it all into a sequence. I could immediately see that the rendered video track (21:32:25 in length), in comparison to the original audio (21:33:10 in length), had 15 frames of difference (at 29.97fps). After much trial and error, I found that by increasing the audio track speed up to 100.5%, fixed the sync (by squishing the audio to play faster to fit the video). Both beginning and end sections of video now have synced audio. Premiere Pro wouldn't export as AC3, so I had to stick with AAC (it seemed to "normalize" the track automatically, making it a bit louder as well). I then muxed the H264 file in the StaxRip temp folder and this AAC file together (using that MP4muxer program), and the result seemed pretty good. I think that 100.5% speed increase is the trick!

But as you can see, that is quite a process, and not so ideal either. I would love to know if there is a code/script in AviSynth, to increase the speed of the original AC3 audio track by 100.5% so as to achieve the audio/video sync properly within the first render.
Many thanks!

[manono]

Better would be to figure out how the audio got out of synch to begin with. If the source audio and video were in synch, then one or the other's length got changed. You might check the audio length before and after the sample rate change.

I could immediately see that the rendered video track (21:32:25 in length), in comparison to the original audio (21:33:10 in length), had 15 frames of difference (at 29.97fps).

That can't be true as 15 frames is 0.5 second at 29.97fps. And if the source is film, then it's 15/24=0.625 second. And shouldn't it be 21:32.25 and 21:33.10? That difference is 0.85 second. And taking into account a possible delay or the audio being longer than the video to begin with, those figures might not even be relevant. Again, it might be more useful to figure out which changed between the source and the final output. And to then go back and do it right.

[hickeyguy]

Better would be to figure out how the audio got out of synch to begin with.

Thank you manono - It is so interesting, indeed! As you have pointed out, the information I have accumulated today just doesn't make much sense. The numbers don't add up (from the things I wrote about before). I need to start from square one, as far as investigating goes (rather than walking backwards).

Let's see. The very first render I made with QTGMC (upping the FPS to 59.94fps) had no audio sync problems. The 2nd file I made with the IVTC+decimate code (droping everything to 23.976fps) had no audio sync problems. The 3rd test I made using QTGMC (upping to 59.94fps) and then IVTC straight after creating a 47.95fps video, funnily, had no audio sync issues (even with that atypical end framerate). The 4th file I made using only the TFM code (no decimate, leaving the FPS the same as the source = 29.970fps) ALSO had no audio sync issues.

Only this render using EEDI3 & QTGMC (inputtype=1) at 29.970fps is having audio sync issues. I have tried a copy/mux of the original AC3 audio track, and tried multiple audio encodes (AAC and WAV at different sample rates, delay codes, etc). How strange is this!?! I'm baffled!

I will upload in order of what I have listed above, TXT files of the MediaInfo documents, for each of those renders (starting with the source). Maybe something in there will help direct and point the finger at the problem?

Edit = I don't think the audio is the problem. It has to be the video. Something has made the video "quicker" (couldn't think of another term) than it should be. Here is a screenshot in Premiere of an in-sync audio/video (in grey - top and very bottom bar) versus the out-of-sync video (dark blue - the two middle bars) =

[Attachment 48279 - Click to enlarge]
I have to figure out why the video track is running faster than it should, when all the MediaInfo is saying that the fps and runtime are the same as the videos that are in-sync.

[hickeyguy]

[THREAD] Is the audio off by the same amount all the way through? If so, setting a delay can easily fix it. Or does the delay get worse as the video plays? If so, the audio (or possibly the video) length got changed at some point and you should check the lengths at each stage to figure out where.

After much reading last night, today I wanted to try AssumeFPS Source File AssumeFPS(%media_info_video:FrameRate%) - but it appears to have only changed from 29.970029 to 29.970000 FPS, and still is out of sync slightly. I think InputType=1 for QTGMC might have done something to the video making it quicker/shorter in duration (that is my suspicion for now). But i'm too tired to go back and investigate all of the different avenues i've been through, for figuring this all out. Thank you everyone - Hopefully something will work soon enough.

Edit = Right now, i've got two videos open side by side. 1 is a 29.970029fps TFM video - and 2 is the problematic supposedly 29.970029fps QTGMCinputtype1/EEDI3 video. Currently, as i'm seeing by going through 1 frame at a time on each - ALL frames are there. None are missing to make it shorter (like it shows in the above Premiere screenshot, showing the difference in video track duration, on the end side). What should my next step be, as i'm so stumped where next is best to go.

Edit 2 = I've just completed a render with EEDI3 & TFM (instead of QTGMC) - and the audio out-of-sync happens with this combo as well, meaning QTGMC isn't to blame here, nor IVTC/TFM. Now i'm wondering why or how EEDI3 would cause this... EEDI3 is the causing factor here, from what i've learned so far. Hope we can figure it out, as I love what EEDI3 did to those jaggies!

Edit 3 = Just tried an EEDI3 & QTGMC again, but with the EEDI3 field value from 1 to -1... but it gave the same result as just 1. There goes another 2 and a half hours. Tomorrow I will try NNEDI3 just an an experiment. And then i'm completely out of idea's..... Should I try EEDI3 with a field value of 2 and/or 3?

[jagabo]

What source filter are you using?

[hickeyguy]

What source filter are you using?

G'day Jagabo!
I've been doing some more reading tonight (so interesting how these edge-based deinterlacers work. The science and maths is mind blowing!) and might give EEDI2 a go tomorrow.

The source filter given by default for my VOB source (in StaxRip) is FFVideoSource, but there is a range in there I could change to (LSMASHVideoSource, etc). Do you think the Filter>Source>FFVideoSource might be causing this problem in conjunction with EEDI3? (meaning maybe EEDI3 isn't the problem that needs fixing, but with EEDI3 being used the source filter needs to be set to something else?).

Here is a quick preview of the script i'd love to be able to use =

FFVideoSource("C:\Users\Doug\Desktop\Wildboyz D1\WBz_S1_D1_EP1_South_Africa_1_RAW.VOB", colorspace = "YV12", \
              cachefile = "C:\Users\Doug\Desktop\Wildboyz D1\WBz_S1_D1_EP1_S..._temp\WBz_S1_D1_EP1_South_Africa_1_RAW.ffindex")
EEDI3(field=1)
QTGMC(inputtype=1, sharpness=0.2, preset="very slow", NoiseProcess=2, NoiseRestore=1.0)
BicubicResize(720, 528, 0, 0.5)

[Attachment 48289 - Click to enlarge]

Hope to gain some more knowledge tomorrow, but gee i'm getting tired. I might need to pace myself a bit better after these past 2 weeks. Thank you, jagabo. Fingers crossed!

Edit = don't mind the fps in that screenshot - I just made it a moment ago using a project I had prepared for tomorrow morning where I was going to try EEDI3(field=3) which would double the fps x2 (59.94fps) using TFF.... probably won't do that, but might give EEDI2 a go, just to see what happens.

[jagabo]

What source filter are you using?

The source filter given by default for my VOB source (in StaxRip) is FFVideoSource, but there is a range in there I could change to (LSMASHVideoSource, etc).

For VOB and MPG sources always use DgIndex to build an index file and Mpeg2Source("filename.d2v") to read the video via that index. This is almost certainly the source of your A/V sync problem.

http://rationalqm.us/dgmpgdec/dgmpgdec.html

[hickeyguy]

That is very interesting indeed, as up until a few days ago, while creating little clips to test different codes on, I have been discarding the D2V files produced by DGIndex! Isn't that crazy... A couple of days ago, I learned that it can be very helpful in identifying hard/soft telecine and/or what kind of interlace is going on. I will upload my D2V which I put through the Analyze/Parse D2V function, just as a matter of record, as I know that I will probably reread this thread again someday, and would find that useful (it also shows how large the Group Of Pictures are - how cool is that!?!).

So, later this evening, I will create a D2V file for EACH VOB file I have. In my script for Source - do you recommend that I replace FFVideoSource with Mpeg2Source? And do you recommend I replace the filepath/name from .VOB to .D2V? (as the D2V file will be sitting in the same location as the VOB's). Thank you, Jagabo.

P.s. I still find it interesting that no sync issues had occurred until EEDI3 was introduced into the script. What do you think EEDI3 does, in relation to the Source filter, to make the video track shorter than it should be? A mystery maybe? That question will sit in the back of my mind for some time....

[manono]

...I will create a D2V file for EACH VOB file I have.

I may be misunderstanding, but if for a movie you open all the VOB files at once and make a single D2V file for the entire film.

do you recommend that I replace FFVideoSource with Mpeg2Source?

Of course. A sample source line might go:

MPEG2Source("Movie.d2v")

You will have already made the D2V file and you also need the DGDecode.dll. If StaxRip doesn't allow for that, then edit the script it makes. Be sure to read the information included in the DGMPGDec package as it's the best source for teaching you how to work with DVDs.

[poisondeathray]

Edit = Right now, i've got two videos open side by side. 1 is a 29.970029fps TFM video - and 2 is the problematic supposedly 29.970029fps QTGMCinputtype1/EEDI3 video. Currently, as i'm seeing by going through 1 frame at a time on each - ALL frames are there. None are missing to make it shorter (like it shows in the above Premiere screenshot, showing the difference in video track duration, on the end side). What should my next step be, as i'm so stumped where next is best to go.

Side by side in what ?

If all the frames are there, it suggests it should be in sync in whatever you are checking it with

Did you check in a media player to see if the encoded video is in sync ? (e.g. mpchc, potplayer, vlc) . ie. is it a premiere importing issue?

Did you check another format, preferrably I-frame format to encode in ? e.g. ut video codec

You can check the framecount in the script (to see what avisynth thinks the framecount is) by adding info() to the bottom of the script . If each script reports the same framecount, it's not an avisynth problem . It's something later downstream , like encoding, muxing, or import issue with PP

[hickeyguy]

I may be misunderstanding, but if for a movie you open all the VOB files at once and make a single D2V file for the entire film.

Thank you, manono! At the very beginning, I was trying to extract RAW MPG files from the 4 or so VTS VOB's on the disc, into respective MPG's for each episode (from which I would then work with). VOB2MPG would only let me create one large gigantic MPG for EVERYTHING on the disc (including the menu), which annoyed me greatly. I think it was 'DVD Decrypter' that allowed me to extract VOB's for each episode (also allowing me to include the main audio track and ignore the commentary track) referring to the IFO on the disc. This produced 8 RAW VOB's for the 8 ep's on the DVD, and didn't have any sync issues with anything until the other day when we introduced EEDI3 - which baffles me.

Today when I find some time to monitor an encode for a few hours, I want to try out this method of MPEG2Source referring to the D2V (instead of my EEDI2 encode idea from earlier). I'm excited about that, as I am just now discovering that DGDecode.dll isn't in my plugin folder (putting that in now!).

Of course. A sample source line might go: MPEG2Source("Movie.d2v")

You will have already made the D2V file and you also need the DGDecode.dll. If StaxRip doesn't allow for that, then edit the script it makes. Be sure to read the information included in the DGMPGDec package as it's the best source for teaching you how to work with DVDs.

I appreciate this information very, very much!

Side by side in what ?

G'day PoisonDeathRay! I had two instances of VLC open, side by side to fill my screen - both videos paused, and I would carefully go back and forth between each window, pressing 'E' to travel through frame by frame. I would do this on every clip, to find that the 24fps IVTC removed frames, and 59.94fps QTGMC interpolated/created new frames. But my comparison between the ordinary 29.97fps TFM encode with normal duration (in-sync) and then this 29.97fps EEDI3/QTGMC encode with abnormal duration according to Premiere (out-of-sync), showed the exact same frames, none skipped/missing or repeated. They were the same, side-by-side all the way (although, I didn't do this frame by frame the entire way, just in large sections, from the beginning right to the end).

When I imported these two tracks into Premiere Pro, there was a clear visual difference (as seen in the screenshot from post #33) between the video tracks. The audio waveformation also aligned between the two tracks (the shorter track was just CUT to fit the video track ending where it ends, it seems). But the video track according to the Premiere timeline, was 15or16 frames short compared to the normal in-sync track, which I guess explains why the audio became out-of-sync as the video went along (as the video track must be squished, or played faster than the audio track).

But you're right, and I love where you are going in your post. I will read further and dig much deeper into the things you write about in your response, a little later this evening. For now, I had a read through one of the log files (in the temp folder) for one of these out-of-sync encodes (EEDI3 & QTGMC), and here are the frame counts =

-------------------------- Script Properties --------------------------

Source Frame Count : 38785
Source Frame Rate  : 29.970030
Source Duration    : 00:21:34.1260000
Target Frame Count : 38785
Target Frame Rate  : 29.970030
Target Duration    : 00:21:34.1260000

----------------- Muxing using MP4Box 0.7.2-DEV-rev79 -----------------

C:\PortableTools\StaxRip-x64-1.7.0.0-stable\Apps\MP4Box\MP4Box.exe -add "C:\Users\Doug\Desktop\Wildboyz D1\WBz_S1_D1_EP1_S..._temp\WBz_S1_D1_EP1_South_Africa_1_RAW_EEandQTGMC528_out.h264#video" -add "C:\Users\Doug\Desktop\Wildboyz D1\WBz_S1_D1_EP1_S..._temp\WBz_S1_D1_EP1_South_Africa_1_RAW T80 2_0ch 192Kbps DELAY 0ms.ac3#audio:lang=eng:name=" -itags encoder="StaxRip 1.7.0.0" -new "C:\Users\Doug\Desktop\Wildboyz D1\WBz_S1_D1_EP1_South_Africa_1_RAW_EEandQTGMC528.mp4"

AVC-H264 import - frame size 720 x 528 at 29.970 FPS
AVC Import results: 38785 samples (116485 NALUs) - Slices: 130 I 9696 P 28959 B - 30507 SEI - 130 IDR
Stream uses forward prediction - stream CTS offset: 2 frames
AC3 import - sample rate 48000 - 2 channels
Saving C:\Users\Doug\Desktop\Wildboyz D1\WBz_S1_D1_EP1_South_Africa_1_RAW_EEandQTGMC528.mp4: 0.500 secs Interleaving

I think the frame count is the same in the output, as the input. Does that sound right?

Thanks so much for the discussion everyone. It feels good, and pretty promising that we might figure this out at some point. I just have to give this new MPEG2Source method a try (after some reading), and report back. I really appreciate it! I wish there was some way I could give back the favor you're giving me, in return!

[poisondeathray]

Side by side in what ?

G'day PoisonDeathRay! I had two instances of VLC open, side by side to fill my screen - both videos paused, and I would carefully go back and forth between each window, pressing 'E' to travel through frame by frame. I would do this on every clip, to find that the 24fps IVTC removed frames, and 59.94fps QTGMC interpolated/created new frames. But my comparison between the ordinary 29.97fps TFM encode with normal duration (in-sync) and then this 29.97fps EEDI3/QTGMC encode with abnormal duration according to Premiere (out-of-sync), showed the exact same frames, none skipped/missing or repeated. They were the same, side-by-side all the way (although, I didn't do this frame by frame the entire way, just in large sections, from the beginning right to the end).

Is it in sync in VLC playing it normally ? Or another video player e.g. MPCHC, potplayer, etc...

When I imported these two tracks into Premiere Pro, there was a clear visual difference (as seen in the screenshot from post #33) between the video tracks. The audio waveformation also aligned between the two tracks (the shorter track was just CUT to fit the video track ending where it ends, it seems). But the video track according to the Premiere timeline, was 15or16 frames short compared to the normal in-sync track, which I guess explains why the audio became out-of-sync as the video went along (as the video track must be squished, or played faster than the audio track).

What does PP interpret the file framerate as for that file?

-------------------------- Script Properties --------------------------

Source Frame Count : 38785
Source Frame Rate  : 29.970030
Source Duration    : 00:21:34.1260000
Target Frame Count : 38785
Target Frame Rate  : 29.970030
Target Duration    : 00:21:34.1260000

I think the frame count is the same in the output, as the input. Does that sound right?

For that version of the encode input matches output framecount - but does that 38785 match the other 29.97 TFM version which is in sync? Do all versions in sync at 29.97 have 38785 frames ?

[hickeyguy]

I haven't done any tests with MPEG2Source just yet (been a busy day!), but want to create a detailed reply to answer your questions, PoisonDeathRay. I am actually shocked with some of the investigating I have done this evening, as I was sure the same amount of frames existed, between the two files. I suppose what i've done is rather silly, assuming using my eyes rather than finding evidence in numbers.... But after using a different MediaInfo GUI program (this time I used one called MediaInfoXP, instead of the usual 18.12 MediaInfo GUI), to calculate the total frame count in my files - I was surprised to see that the IN SYNC TFM MP4 has a different frame count to that of the EEDI3withQTGMC MP4.

Here is some info from the TXT it generated for the source VOB for starters =

Duration                                 : 1294660
Duration                                 : 21 min 34 s
Duration                                 : 21 min 34 s 660 ms
Duration                                 : 21 min 34 s
Duration                                 : 00:21:34.660
Duration                                 : 00:21:34;19
Duration                                 : 00:21:34.660 (00:21:34;19)
Frame rate                               : 29.970
Frame rate                               : 29.970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Frame count                              : 38801

Then the TFM =

Duration                                 : 1294660
Duration                                 : 21 min 34 s
Duration                                 : 21 min 34 s 660 ms
Duration                                 : 21 min 34 s
Duration                                 : 00:21:34.660
Duration                                 : 00:21:34;19
Duration                                 : 00:21:34.660 (00:21:34;19)
Frame rate mode                          : CFR
Frame rate mode                          : Constant
Frame rate                               : 29.970
Frame rate                               : 29.970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Frame count                              : 38801

Then the EEDI3withQTGMC =

Duration                                 : 1294125
Duration                                 : 21 min 34 s
Duration                                 : 21 min 34 s 125 ms
Duration                                 : 21 min 34 s
Duration                                 : 00:21:34.125
Duration                                 : 00:21:34;03
Duration                                 : 00:21:34.125 (00:21:34;03)
Frame rate mode                          : CFR
Frame rate mode                          : Constant
Frame rate                               : 29.970
Frame rate                               : 29.970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Frame count                              : 38785

To answer your first question - VLC media player is the only player I really use. I don't use WindowsMediaPlayer (it won't handle these MP4's), and very rarely open QuickTime player (only for MOV's on occasion - but also won't handle these MP4's either). The TFM (and other encodes with QTGMC, IVTC with decimate, and QTGMC inputtype1) all play in-sync with VLC. So does the source VOB. But ANY encode that involves EEDI3 produces a file that won't play in-sync (the video track being the problem, not the audio track). I could try MPCHC, but I think it's 100% the file, not the player in this case.

Here are some screenshots of the information, for how Premiere Pro interprets the two files... starting with the TFM MP4 =

[Attachment 48300 - Click to enlarge]

[Attachment 48301 - Click to enlarge]

[Attachment 48302 - Click to enlarge]
Then the EEDI3withQTGMC MP4 =

[Attachment 48303 - Click to enlarge]

[Attachment 48304 - Click to enlarge]

[Attachment 48305 - Click to enlarge]
And then both files in a sequence together - the problem file being in the middle (middle 2 bars - outer 2 bars being the TFM tracks - note the waveform is in-line for both files, but the shorter video causes the end of the audio track to be cut) =

[Attachment 48306 - Click to enlarge]

And then in After Effects - starting with the TFM =

[Attachment 48307 - Click to enlarge]
Then the EEDI3withQTGMC =

[Attachment 48308 - Click to enlarge]
And then both together in a comp - you can see that it is 15 or 16 frames short (green on top is TFM - purple on bottom is EEDI3withQTGMC) =

[Attachment 48309 - Click to enlarge]

For that version of the encode input matches output framecount - but does that 38785 match the other 29.97 TFM version which is in sync? Do all versions in sync at 29.97 have 38785 frames ?

My first encode simply with QTGMC (no progressive codes aka inputtype=1, in that one...) which X2'd the FPS to 59.94fps had a total frame count of 77602 and was IN SYNC - duration of 00:21:34.660 (00:21:34;38... notice that last semicolon... almost thought that was a normal colon).

One of my other encodes with the above QTGMC plus IVTC after (TFMwithDecimate - I know, silly to do after QTGMC, but was an experiment) had a framerate of 47.952 (48000/1001) and a total frame count of 62081 and was IN SYNC - duration of 00:21:34.655 (00:21:34;45).

Another encode with the above IVTC (TFMwithDecimate) but no QTGMC, had a framerate of 23.976fps and a total frame count of 31040, and was IN SYNC - duration of 00:21:34.655 (00:21:34;22).

The EEDI3 file has a duration of 00:21:34.125 (00:21:34;03) - and all the other one's have something almost exactly 00:21:34.660 (00:21:34;19) like the source.

Tonight or tomorrow when I have time, I will play with the Source Filter, to see if that will affect the amount of total frames in the end file.... My brain is all over the place right now, but i'm also just thinking how EEDI3 might affect that shorter duration (aka loss of frames). QTGMC hasn't affected the sync or total frames in combo with that - but EEDI3 has. Maybe EEDI3 and that Source Filter (with no D2V reference) is causing the loss of frames. I suppose I just need to experiment more and read into fpsden/num or assumefps or something along those lines to force the fps and force the duration (or something like that, somewhere in the script at some point). Fingers crossed we're getting somewhere!

Edit = After reading my post and my previous post (comparing some numbers) - you can see that StaxRip or AviSynth or the Source Filter thinks that the Source Frame Count is : 38785 (in the EEDI3withQTGMC script referring to the VOB as the source) when IT ISN'T!!!! Why isn't it seeing the source VOB frame count as being 38801? Very interesting, indeed.

[hickeyguy]

DGDecode.dll doesn't seem to be 64bit, and I couldn't find a 64bit version anywhere (one in here still showed as being 32bit), so now i'm looking to find either an x86/32bit StaxRip and/or 32bit/x86 AviSynth just to make that DGDecode.dll work for the source filter (MPEG2Source).

[Attachment 48310 - Click to enlarge]
Hope I find a balance here that's compatible....

Edit = I imported a D2V into StaxRip and for the Source Filter 'MPEG2Source' a plugin called MPEG2DecPlus64.dll was loaded =

[Attachment 48311 - Click to enlarge]
Is that as trusted and as reliable as the 32bit DGDecode.dll? I will give it a go in the morning!
P.s. I managed to get StaxRip_1.2.2.0_x86-32bit - and might see if I can do everything i've been doing in the 64bit version (with EEDI3 & QTGMC) but in this 32bit version with DGDecode - after I try this MPEG2DecPlus64.dll (if it doesn't produce an in-sync result).

[jagabo]

64 bit version of dgdecode here: http://forum.doom9.org/showthread.php?p=1374605

[SaurusX]

64 bit version of dgdecode here: http://forum.doom9.org/showthread.php?p=1374605

That doesn't work too well and is not official. I'd suggest taking MPEG2DecPlus out of the 64-bit StaxRip and using that. It's a fork of some kind from DGDecode and works great.

[hickeyguy]

64 bit version of dgdecode here: http://forum.doom9.org/showthread.php?p=1374605

G'day! Thank you - that is the one I tried last night which gave the same 32bit error as the actual 32bit dgdecode.dll produced (maybe it is 64bit, but just not working so well with StaxRip? That's alright anyhow). Am now just about to start an encode using MPEG2DecPlus with the D2V file. Fingers crossed, and hopefully have something to share in the next few hours.

[hickeyguy]

64 bit version of dgdecode here: http://forum.doom9.org/showthread.php?p=1374605

That doesn't work too well and is not official. I'd suggest taking MPEG2DecPlus out of the 64-bit StaxRip and using that. It's a fork of some kind from DGDecode and works great.

I have fantastic news to report, everyone! MPEG2Source as the source filter referring to the D2V (using MPEG2DecPlus) instead of FFVideoSource which StaxRip selected by default for the VOB - has resulted with an IN SYNC file!!!! It just finished, and I skipped to the end (like I normally do) and it wasn't out of sync, like the previous renders. I'm over the moon right now. When I have a proper moment to sit down at length, I will go through the whole file, and also analyze the file for the duration+frame count, just to see if everything IS all good. Thank you so much everyone! Will edit this post later with those details .

Edit, which I promised =

Here is some info from the TXT it generated for the source VOB for starters =

Duration                                 : 1294660
Duration                                 : 21 min 34 s
Duration                                 : 21 min 34 s 660 ms
Duration                                 : 21 min 34 s
Duration                                 : 00:21:34.660
Duration                                 : 00:21:34;19
Duration                                 : 00:21:34.660 (00:21:34;19)
Frame rate                               : 29.970
Frame rate                               : 29.970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Frame count                              : 38801

Here are the results for this new encode with MPEG2Source as the Source Filter =

Duration                                 : 1294660
Duration                                 : 21 min 34 s
Duration                                 : 21 min 34 s 660 ms
Duration                                 : 21 min 34 s
Duration                                 : 00:21:34.660
Duration                                 : 00:21:34;19
Duration                                 : 00:21:34.660 (00:21:34;19)
Frame rate mode                          : CFR
Frame rate mode                          : Constant
Frame rate                               : 29.970
Frame rate                               : 29.970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Frame count                              : 38801

How cool is that!?! I'm so pleased with it. Every piece of information above matches the source exactly. I even went ahead and compared this new render (that is fantastically in-sync) to the old render (that was not-in-sync) in Premiere, and was happy to see this =

[Attachment 48316 - Click to enlarge]
For now, I am keeping my fingers crossed that we have finally found a process that I can use, that continues to give this great result, as I go forward with all of the other episodes. I hope I don't need to ask for more help, but if I do, I know where to come for the greatest assistance i've received thus far anywhere on the internet. Thank you so much!

[jagabo]

VOB files are inherently variable frame rate. The video can be encoded at any frame rate from 19.98 to 29.97 with pulldown flags, or 29.97 interlaced with hard pulldown, and can switch between them at any time. Most source filters do not deal with that perfectly. Mpeg2Source() is the only source filter I know that always works.

Regarding episodic DVDs, there are basically two types. One where each episode has its own VOB set, and one where all the episodes are in one VOB set. For the former you just load all the VOB files for the episode into DgIndex and produce a single D2V file for that episode, repeat for each episode. For the latter you load all the VOB files into DgIndex then manually locate each episode, mark-in, mark-out, and save a D2V file for each.

[hickeyguy]

VOB files are inherently variable frame rate. The video can be encoded at any frame rate from 19.98 to 29.97 with pulldown flags, or 29.97 interlaced with hard pulldown, and can switch between them at any time. Most source filters do not deal with that perfectly. Mpeg2Source() is the only source filter I know that always works.

Regarding episodic DVDs, there are basically two types. One where each episode has its own VOB set, and one where all the episodes are in one VOB set. For the former you just load all the VOB files for the episode into DgIndex and produce a single D2V file for that episode, repeat for each episode. For the latter you load all the VOB files into DgIndex then manually locate each episode, mark-in, mark-out, and save a D2V file for each.

Thank you very much for this information. I am learning a lot through the creation of this thread, and I can't tell you how much you and others have helped me. I really appreciate it, especially your insight, as i'm sure that you've gone through some challenges yourself, only to learn and then be kind enough to share, and save others from the same pain. I'm actually quite shocked by how wrong I was, working or attempting to work with these files in the past. Boy was I in the wrong! Gee whiz! I didn't mention it before, but I am planning on creating these files specifically for a friend of mine who worked on the show. He doesn't have access to the master footage/s, but will dearly appreciate these episodes processed the way we have figured out together. I actually sent the following link to him as a gift - as tomorrow is a very special day for him (a lot to be proud of today, tomorrow, and the next!). Here is a MEGA.nz link to the full encoded clip using Source Filter MPEG2Source (audio won't play in browser, in the MEGAplayer, but should be fine once downloaded) = /#!Zew1SCBQ!Zh0deSf0JwY1Wt-2wngwt3QhTgUkN4dRFIGa9tgGvfU

I'm not sure how accepted it is here to share that kind of material, but as a token of my appreciation, I have taken the time to upload it, for everyone here to enjoy (as it was a group effort).... but only for a limited time publicly, as I don't want this to be available online for more than 7 days (will switch it to private next weekend).

Thank you everyone! I have created DGIndex D2V's for each episode's VOB file (VOB's compiled by DVD Decrypter from the main IFO/VOB set, from the DVD VTS folder), and will try to continue my encoding using all of the information we've accumulated, in the weeks to come. If I run into problems, I will look into the VOB structure, to see if splitting everything up (as I have) is a problem-causer... We shall see. Fingers crossed!

[jagabo]

64 bit version of dgdecode here: http://forum.doom9.org/showthread.php?p=1374605

That doesn't work too well and is not official. I'd suggest taking MPEG2DecPlus out of the 64-bit StaxRip and using that. It's a fork of some kind from DGDecode and works great.

I was going to write that I haven't had any problems with the version I linked to. But just today I found a VOB source that gave it problems (~every other frame was green). After updating to Mpeg2DecPlus I had no problems. Thanks!