Re-Encoding Vob File?

[manono]

The end results are multiple vob files.

The end result is supposed to be multiple VOB files, just as on the DVD. As I already mentioned, you join the VOBs when making the D2V project file using DGIndex.

Then use DGIndex to join the VOBs and to create a D2V project file so you can use MPEG2Source in an AviSynth script.

[Okiba]

Sorry, I wasn't clear. This part is already done. I already extracted the Vob files and loaded them up with MPEG2Source for editing. So now I have an Mp4 file after IVTC and some color corrections. I will use this copy for viewing, but I also want to save the original source in case I will want to do more modifications in the future. So I wonder who yous store, or rather archive those. You just leave it as multiple vob files?

Besides that, I'm all ready to start ripping all the DVDs. The only missing piece of information, is what is the "right" frame output. Should It be 2-2-2-2? That's the correct way of frames to show? if that's the case, I will prefer IVTC when I can reach that 2-2-2-2, and if not - I'm fine with SRestore (which give me steadt 2-2-2-2), as I wasn't able to detect the differences when actually playing the video. At least on this specific video.

[manono]

...but I also want to save the original source in case I will want to do more modifications in the future. So I wonder who yous store, or rather archive those. You just leave it as multiple vob files?

I'd leave them as DVD. However, if you want to join them with no reencoding, then something like VOB2MPEG will do the job.

...what is the "right" frame output.

There is no 'right frameoutput'. Animations are drawn to be displayed at all kinds of framerates, even within the same episode. These include, among others, 8, 12, 16, and 24fps. There are even sometimes 29.97fps parts, most often in anime intros, which throws a real monkey wrench into attempts to IVTC them.

[Okiba]

There is no 'right frameoutput'. Animations are drawn to be displayed at all kinds of framerates, even within the same episode. These include, among others, 8, 12, 16, and 24fps. There are even sometimes 29.97fps parts, most often in anime intros, which throws a real monkey wrench into attempts to IVTC them.

Thank you. So how can I tell IVTC worked properly? as long as I don't see blended frames I'm good? I see differences in the frame order when using the default TDecimate mode and mode 1, but non are blended. So I'm OK either mode? and if I also don't see any blended mode with SRestore - it doesn't matter if I use SRestore/TDecimate?

[manono]

So how can I tell IVTC worked properly?

You find a stretch at the same framerate (1-1-1-1-1, 2-2-2-2-2, etc.) and count along for awhile. It's not all that hard and anime is jerky anyway.

...as long as I don't see blended frames I'm good?

Field-blending should never be IVTC'd as it was never telecined to begin with. You attack field-blending differently (Bobber/Srestore). Only telecined content gets the IVTC treatment. I can't give specific advice without seeing samples. One size definitely does not fit all.

[jagabo]

Field-blending should never be IVTC'd as it was never telecined to begin with.

This is somewhat pedantic but... Actually, it was telecined to begin with, that's why it's field blended not frame blended. But after the blending it's too far divorced from the original for a simple IVTC to work.

[manono]

Then your definition of telecining is somewhat 'looser' than mine. Ordinarily, as you know, it's the process of adding clean fields to go from 23.976fps to 29.97fps. I loosen it somewhat to include adding clean fields to go from a lower framerate to a higher one (19.98->29.97fps, 25fps->29.97fps, 24fps->25fps and others). I've seen or created myself examples of each of those. But I don't consider adding blended fields to output a higher framerate as a telecine. As far as I know, blended fields are created by hardware standards conversion boxes. They are exponentially worse than any other method of raising framerates for DVD or television broadcast.

The Wikipedia definition does back you up, though:

Telecine is the process of transferring motion picture film into video and is performed in a color suite.

https://en.wikipedia.org/wiki/Telecine

I consider field-blending so godawful horrible because of the damage it does to the source video, that I don't include it as a legitimate way to increase framerates. And, as you mention, it can't be properly IVTC'd. But pedantic point taken.

[jagabo]

Then your definition of telecining is somewhat 'looser' than mine. Ordinarily, as you know, it's the process of adding clean fields to go from 23.976fps to 29.97fps.

Almost all field blended videos I've seen have come from NTSC/PAL conversions that were obviously from analog video tapes. The film was literally telecined (using your restrictive definition) with 3:2 or 2:2 pulldown into analog video before they were NTSC/PAL converted with blending.

[manono]

Another reason field-blending might be considered an 'illegitimate' form of telecine is because telecine adds duplicate fields We've all seen those diagrams of how 4 frames are turned into 10 fields. With field-blending it isn't duplicates that are added. I have yet to see one of those diagrams or any telecine discussion show or mention field-blending, even though it's extremely common.

Almost all field blended videos I've seen have come from NTSC/PAL conversions that were obviously from analog video tapes.

Maybe 'almost all', but not all are from standards conversions. I've seen field-blending done to go from 23.976->29.97fps, even though a standard telecine would have been vastly preferable. Even your last point, while it might describe pulldown along the way to the final result, that final step of adding in the blending just ruins the whole process. After all, there are easy ways to do the PAL<->NTSC conversions that don't require field-blending. But I guess those standards conversion boxes made the process cheap and easy (or easier).

[Okiba]

You find a stretch at the same framerate (1-1-1-1-1, 2-2-2-2-2, etc.) and count along for awhile. It's not all that hard and anime is jerky anyway.

On the specific DVD I'm playing, I'm seeing Steady 2-3 pulldowns. After TDecimate (with either the default Mode or Mode=1), I see mostly 2-2-2-2-2-2-2-2. But once in a while, something like that will occur: 2-2-2-2-2-2-1-3-2-2-2-2 etc). Does it mean IVTC wen't wrong? or as long as the 1 is being compensated by 3 it's still good?

With QTGMC().Srestore() I get a constant 2-2 by the way.

[manono]

Does it mean IVTC wen't wrong? or as long as the 1 is being compensated by 3 it's still good?

Well, good in the sense that the length won't change. But bad in the sense that it'll play even more jerky than it should. There might be ways to tweak the decimation to make it come out right. Or to fix it using override files. But that's all a huge hassle. No, I'd say after checking the results of TFM/TDecimate(Mode=1) you get 2-1-3 where it should be 2-2-2, to go the Bob/Srestore route. By default SRestore might give you 25fps when you want 23.976fps. Make sure you set the framerate. SRestore(Frate=23.976)

Edit: Or fieldmatch like usual and let SRestore do the decimation:

TFM().Srestore(Frate=23.976)

[Okiba]

Yea, It's probably doesn't really matter. As I mentioned - this is just couple of kids DVDs. Nothing to worth the extra care. But I'm interested though - What's the difference in QTGMC and what TFM does (fieldmathcing you said?). I know QTGMC does much more (noise processing, sharpening etc etc). But if you turn all those extra feature, QTGMC and TFM does the same thing?

[manono]

No, not the same. QTGMC creates frames out of fields. TFM creates frames from field partners - from fields that belong together to begin with.

TFM returns the original untouched frames, QTGMC doesn't.

[Okiba]

Thank you. When I'm home I'll compare TFM().SRestore() vs QTGMC.SRestore() out of curiosity to see if I can notice the differences.
EDIT: Tried TFM().Srestore(), Still suffering from 2-2-2-1-3-2-2. QTGMC().Srestore() is the only steady 2-2-2 solution for this specific video.

That was super educational thread for me, thanks you all attenders. Up until now, I only used QTGMC, now I know IVTC exists. So If I'm summing what we talked about previously for my sake and the sake perhaps of future readers:

- If the video has movement every frame (1-1-1-1) it's a true interlaced video, and using QTGMC() is enough.
- If there's pull-downs (where the most common are 3:2/2:3), the video need to be IVTCed:

TFM(clip2=QTGMC(FPSDivisor=2)).TDecimate()

The results should be a video with a steady movement (2-2-2-2 for example). The clip2 parameter tells FTM to use QTGMC as de-interlacer instead of the default one - if it can't find a matching field to complete a frame.

- If steady frame rate isn't achieved - another option to try it to us TDecimate(mode=1), which work better on cartoons.
- If even that doesn't work, it's mostly easier to just use SRestore, with TFM first, and if not - with QTGMC

 TFM(clip2=QTGMC(FPSDivisor=2)).Srestore(Frate=23.976) # or 25 for PAL 
# or
QTGMC().Srestore(Frate=23.976)

- If one still want to use the QTGMC cleanup features (sharpening, noise processing etc), it's possible to run QTGMC without the de-interlacing part after TFM:

QTGMC(InputType=2)

Sounds about right?

[jagabo]

Sometimes you'll find a pulldown pattern that requires a longer period than the default 1 out of 5 that TDecimate() uses by default. For example, using a letter for each original film frame, A B B C D E F F G H can be decimated properly with TDecimate() because one of the Bs in the first group of 5 will be thrown out, then one of the Fs in the second group of 5 will be tossed. But in a pattern like A B C D E F F G H H there's no duplicate in the first group of 5 so a unique frame will be discarded. Then in the second group of 5 either an F or an H will be discard but the other duplicate will be retained. If you use a longer cycle, TDecimate(Cycle=10, CycleR=2) (remove 2 of every 10), one of the Fs and one of the Hs in the group of 10 will be discarded leaving all 8 of the original film frames. Both decimate a 29.97 fps video to 23.976 fps but the latter will play more smoothly in the second case.

Cartoons have lots of duplicate frames so you only expect to see all unique frames in panning shots. Most shots with only character motion will only change every other frame (because they were animated at 12 fps) or even less.

Also note that QTGMC(InputType=2) can sometimes damage a video. So use it only when the benefits outweighs the detriments.

You should stop worrying about all the possible theoretical issues and start working on some real videos. Then when you run across a problem you don't understand come back and upload a sample that shows the problem.

[Okiba]

You should stop worrying about all the possible theoretical issues and start working on some real videos. Then when you run across a problem you don't understand come back and upload a sample that shows the problem.

Yes, your right. I just want to get the general gist so I can solve most of the problems myself and only post the really complicated videos.

Thanks again everyone! appreciate your help.

[Okiba]

Hi again everyone!

So I have been converting couple of DVDs, and was able to apply everything you guys said. However, I encountered this attached video - and I'm not sure what to do with it. On some classic, there's a classic 3-2 pulldown. To TFM().TDecimate() sounds like a good options. But on some section (like the fly flying around, there' much faster movement, and it's not panning. Is it still OK to with the default Tdeimate mode even if the frames pulldown change often?

[jagabo]

The only unusual thing I saw in that clip was the "clock" transition near the end. It was animated at 60 fps. Most of the character animation is at 12 fps, some of the fly animation is at 24 fps.

[Okiba]

So even with multiple FPS count on different sections - TFM(clip2=QTGMC(FPSDivisor=2)).TDecimate() should still be the proper way doing so? so for this example I should use it? here's a more specific video I can actually tell the difference between results (attached).

At around 8 second the platform to the left is heading down with the word "Stop". After SeparateFields(), I can easily count 2-3 pulldown. With TDecimate, before the drop, I see movement every 2 frame. During the drop, I see frame every single move. When the platform is at the bottom (from 212) I can count 3 frames until the next movement where it back to 2 frame per movement. I assumed - that's not right, because it's changing too often. So I used QTGMC().SRestore(frate=23.976) instead. With that, I can see the platform movement starts with movement per single frame, but then it goes to steady 2 frame per movement mid way. So again - assumed that better, because the movement is more consistent - but when playing them one by one - I can easily see the platform drop jitter on the SRestore video.

So I guess what I'm missing is how do I measure if the IVTCed worked - because I'm obviously doing it wrong
Thanks!

[Okiba]

I ended up just searching the fastest section of the video I can find (like the one I shared in in the post above), and test it post SRestore and TDecimate to see which is more jerky. Probably not the best way to determine which worked better, but I guess it's good enough until I can do more research about it. Thank you!

[jagabo]

I ended up just searching the fastest section of the video I can find (like the one I shared in in the post above), and test it post SRestore and TDecimate to see which is more jerky.

Doing it that way is fine -- if that's what you want. But it can be a matter of compromise. The vast majority of test.m2v is animated at 24p. Is it worth encoding the whole video at 60p just because of that one transition?

Generally, I only use SRestore() when there are blended fields/frames.

[Okiba]

Is it worth encoding the whole video at 60p just because of that one transition?

I guess your right, and it's not. It just as I mentioned above - I'm running TDecimate - and I'm not sure yet how to know it's worked? all I have to do is to take a part of steady 3-2 pulldown, and make sure it translate into movement every 2 frames?

Also - `test2.demuxed.m2v`, you can clearly tell something wrong with SRestore - as it's ending very choppy.

[jagabo]

Is it worth encoding the whole video at 60p just because of that one transition?

I guess your right, and it's not. It just as I mentioned above - I'm running TDecimate - and I'm not sure yet how to know it's worked? all I have to do is to take a part of steady 3-2 pulldown, and make sure it translate into movement every 2 frames?

After TFM and TDecimate just look at frames. In panning shots you usually see smooth motion at 24p. Character animation is usually at slower frame rates so you expect to see duplicates. If you see jerky motion during panning shots something may not be right. You'll have to do further analysis.

Also - `test2.demuxed.m2v`, you can clearly tell something wrong with SRestore - as it's ending very choppy.

Only use SRestore when you have field/frame blending.

[Okiba]

Thank you. That's exactly what I was missing. An indication to know IVTC worked properly. There's a lot of panning shots, and I can confirm they are all "smooth". (one frame = one movement).

Only use SRestore when you have field/frame blending.

I think I understand what field/frame blending means based on the example manono shared and after some googling. It's almost like there the pictures is out of focus.

Intresting enough in the test2.demuxed.m2v, the panning at 04:775 seems to be OK with either TDecimate or SRestore. But where It goes wrong is the lowering of that platform at 08:008. SRestore looks jerky, and closer inspection - shows there's missing frames. There's still frame per movement, but it skips a frame. If using TDecimate - you can see there still 1 frame per movement, but extra frame Srestore doesn't show. And what's more interesting, is that the original video length is 44:711. The length with Srestore is also 44:711 - but the length after TDeimcate is 44.670.

[Okiba]

Hi again everyone!

Here's another video I have a question about. DGMPGDec report the frame type to be progressive. Now based on what was said earlier here, those tools not always correct. I found a panning shot (attached), and the pattern seems to be 2-2-2-4 (which based on some searching from the forum, normal Tdeimate() without extra parameters is fine to use). But what bothered me is two things:

- Black bar on top/bottom (didn't see this happening yet). I cropped it with Crop(2, 6, -2, -6). I'm not sure what the SAR for it would be, as I'm not sure if ITU cap has anything to do with upper padding.
- The frames are not sharp. Is that frame-blending?

After TDecimate() I'm getting good 1 movement per frame on this panning shot.

Thanks for sticking up with me :P

[jagabo]

Yes, that video is progressive with a duplicate frame every 5th frame. Just TDecimate() will remove the duplicate.

SAR, Sampling Aspect Ratio, doesn't change when you crop. If the SAR is 8:9 before cropping it's still 8:9 after cropping.

[manono]

DGMPGDec report the frame type to be progressive. Now based on what was said earlier here, those tools not always correct.

DGIndex (I assume that's what you meant to write) is always correct when it says how a video is encoded. However, it says nothing as to what the actual frames are like. Sometimes (rarely, and always by mistake) interlaced frames are encoded as progressive and it's fairly common for progressive frames to be encoded as interlaced, particularly in PAL land.

[Okiba]

Sometimes (rarely, and always by mistake) interlaced frames are encoded as progressive and it's fairly common for progressive frames to be encoded as interlaced, particularly in PAL land.

So I will have to always verify that using bob() and counting the pull-down pattern?

Yes, that video is progressive with a duplicate frame every 5th frame.

Oh. OK. What I did so far is to use bob() or SeparateFields(), find a panning shot - and only then try to figure the pull-down pattern. Seems like you just checked the original video framed (without bob() or SepreateFields()). Is that because it's progressive? I counted 2-2-2-4 that way - and assumed Just TDecimate() is good for 2-2-2-4.

SAR, Sampling Aspect Ratio, doesn't change when you crop. If the SAR is 8:9 before cropping it's still 8:9 after cropping.

Oh, I see. So the only reason we change SAR to 10/11 when there was 8 pixel padding each side, was because it hinted us it's a ITU cap.

By the way, the last video I worked with has delay according to the DGIndex ac3 file name (14ms). What I did is to use DelayAudio(0.014). Was that correct?

Thank you jagabo and manano!

[manono]

So I will have to always verify that using bob() and counting the pull-down pattern?

Verify one way or another, yes. For example, I've seen DVDs converted from a PAL source with 5 unique progressive frames followed by a duplicate frame. One duplicate in every 6 frames. That will also show as progressive in DGIndex.

But you don't always have to bob it or separate the fields to figure out what's going on. Just opening the film you asked about with no filters on would have shown you the all-progressive source with one duplicate frame in every 5 frames. Standard hard-telecine will show as 3 progressive and 2 interlaced frames in every 5-frame pattern.

By the way, the last video I worked with has delay according to the DGIndex ac3 file name (14ms). What I did is to use DelayAudio(0.014). Was that correct?

Well, it can't hurt but I doubt it did anything at all. For one thing 14ms is way too little to notice it's out of synch. In addition AC3 audio can only be delayed in multiples of 32ms (I think). If you converted it to WAV audio, perhaps intending to work on the audio, then the delay would take effect. But yes, the 0.014 figure is correct.

[Okiba]

But you don't always have to bob it or separate the fields to figure out what's going on. Just opening the film you asked about with no filters on would have shown you the all-progressive source with one duplicate frame in every 5 frames. Standard hard-telecine will show as 3 progressive and 2 interlaced frames in every 5-frame pattern.

Oh. I was sure that was the way of doing it (bob or separate first). It makes sense, because some video that were 2-2-2-4 after bob/separate were 2-3 without it any filter. So when DO you want to use bob/separate if you can tell by just checking the video without filters?

Well, it can't hurt but I doubt it did anything at all. For one thing 14ms is way too little to notice it's out of synch. In addition AC3 audio can only be delayed in multiples of 32ms (I think). If you converted it to WAV audio, perhaps intending to work on the audio, then the delay would take effect. But yes, the 0.014 figure is correct.

Oh really, good to know. Quick google search hinting your right, AC3 can only be delayed in multiples of 32ms. I wonder what will happen if delay is 69ms. Will AviSynth create 64ms delay, or It has to be a rounded number for it to actually do anything.

Thank you!