Can anyone confirm if this is 3:2 Pulldown

[robo731]

I believe that I am dealing with 3:2 pulldown content, but I'm not entirely sure, can anyone confirm whether I'm correct or not? I realize this is asked a lot, but I've been wrong a few times in the past about this. I opened the video with avspmod and identified a pattern of 4 progressive, 1 interlaced, but then the pattern doesn't seem to remain consistent.

[Guest]

It's 89% soft 3:2. The other 11% is likely hard pulled down 3:2 but without a sample we can't be sure. Assuming this is true, make a project with Honor Pulldown and then do IVTC in your script, e.g., with TFM/TDecimate or Telecide/Decimate.

The correct pattern for 3:2 is 3 progressive and 2 interlaced. Since you say you don't see that, you'll need to post a link to an unprocessed source sample if you want us to advise you properly.

[robo731]

Ok, I tried the TFM/TDecimate approach and it was definitely an improvement, but it still seems like there are some frames still affected. How long of a sample do you need?

[Guest]

Big enough for us to see your problem!

50 to 100MB should be fine, but make sure it includes the problem areas and has a lot of movement. You can use DGSplit to cut the VOB. Don't give us any processed or encoded video, it has to be the original stream. Another option is to set a range in DGIndex, then do Save Project and Demux Video, then upload the resulting M2V file.

[robo731]

Okay, here's an example of it: Sample.m2v (https://mega.co.nz/#!nUEXXRSJ!W8UE2mqa0Epk_ETxLGONw1o8TGlmlKeBIYw3vih4efo)

[Guest]

Everything looks fine to me with this script:

mpeg2source("VTS_04_1.demuxed.d2v")
telecide()
decimate()

What is your script and what are the frames that you find to be problematic?

[robo731]

http://i.imgur.com/VuHNJB2.png

Here's an example, I see things like this on almost every frame. Here's the script I'm using:

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\Decomb.dll")
mpeg2source("VTS_04_1.d2v")
telecide()
decimate()

[Guest]

Something's very wrong because my matching frame is clean. Also, your posted image has obvious corruptions. Try opening the script in VirtualDub.

[robo731]

Yeah, I'm not sure what the issue is. I'm getting the same thing in vdub.

[Guest]

The corruptions are unusual. What version of Avisynth are you using?

[robo731]

I believe I'm running 2.6 right now because I was doing multithreading stuff. Should I use 2.5?

[Guest]

You have an MT version of Avisynth? That can cause problems.

Yes, please try a plain vanilla 2.5.8.

[robo731]

Ok I will, do I need to uninstall my current version?

[Guest]

No, just rename the avisynth.dll to (say) avisynth.dll~ and replace it with a 2.5.8 avisynth.dll.

[robo731]

Can't seem to find a dll for 2.5.8, only 2.5.7. Also, should I put in System32? Right now the dll is in SysWOW64.

[Guest]

Leave it where it is. I found 2.5.8 in less than 10 seconds with Google.

[robo731]

Alright, the corruptions are gone, but it seems like there are still interlaced frames (frames 116, 119, and 122 to name a few). Also, I've tried to ascertain teh correct field order, but I can't seem to figure it out. Both tff and bff are appearing to be incorrect. Am I missing something?

[Guest]

Your clip is TFF, so you can add AssumeTFF() to the script:

mpeg2source("VTS_04_1.demuxed.d2v")
assumetff()
telecide(post=0)
decimate()

You have to check it for the proper project and not just the sample, however, because edits can change the field order. There is a FAQ on determining field order at my website.

The bad frames can be due to too aggressive post-processing. You can put post=0 for telecide or reduce the strength of the combed frame detection. Please refer to the documentation.

BTW, there appears some chroma ghosting in your source.

[robo731]

Thanks for the info. post=0 didn't change anything. When I try using dthreshold or threshold, virtualdub reports that there's no named argument for it. I'm giving AnimeIVTC a try since it's title implies that it's optimal to use for my kind of source. It seems to be working better, but I'm still experimenting with some of the parameters.

[Guest]

You can head off in other directions if you like, but as long as we are getting different results when they should be the same, it makes more sense to me to get to the root of that. I'll continue if you want to do that. If you do, use only the sample you gave me, post the exact script, and post a screenshot of your bad frame. Given that, assuming I can duplicate it, I will be able to tell you what is going wrong and how you might mitigate it. However, if you are a one-click kind of guy and don't want to have to understand what you are doing, then by all means try other things. Maybe you will get lucky. :)

Another thing to realize is that no field matcher is perfect, and there can be problematic things in your source, such as orphaned fields and the chroma ghosting that I mentioned. Just because you *want* perfect results, it is not guaranteed that you can get them.

When I try using dthreshold or threshold, virtualdub reports that there's no named argument for it That's because you are not reading and following the documentation, where these things are clearly described. Those are parameters for FieldDeinterlace(), not Telecide().

[robo731]

Okay, let's get a few things straight. I do want to get the source as close to perfect as I can. I understand that it may not be possible to get it absolutely perfect. I do want to understand what I am doing, but I am new to this and don't completely understand everything that I read, but I'm trying my best so I'd appreciate it you could bear with me. Please don't misunderstand, I do appreciate the help you've given me so far, but it seems like you're being a little disrespectful and condescending towards me. On the guide (http://www.doom9.org/index.html?/decomb-params.htm) that I read, dthreshold and threshold were parameters for telecide. I have looked at all of the documentation for Decomb that I could find. I'm not a "one-click" guy. I saw that one thing wasn't working and tried another to see if the issue was with me or with what I was using. AnimeIVTC seems to only have the chroma ghosting issue (a similar frame with AnimeIVTC (http://i.imgur.com/mbrcXm9.png)), but I will carry on with Decomb for now since you're getting different results than I am. On frame 84 while using this script:

assumetff()
telecide(post=0)
decimate()

I see this (http://i.imgur.com/GE0uCv2.png).

[Guest]

That frame is clean for me. Please post a link to your full D2V file (for the sample only). I assume you are using the sample you gave me. That will NOT be the D2V file you gave me in the first post.

To be fully clear: To use the M2V sample, you have to open the M2V file in DGIndex and make a project from that. If you want me to work with your VOB then you have to give a VOB sample cut with DGSplit. You can't use the D2V made from the VOB with an M2V sample. I hope it is clear.

Doom9 guides are ancient and should not be used. They should be deleted or brought up to date, but that is Doom9's responsibility. Many have complained about this.

[robo731]

Doom9 guides are ancient and should not be used. They should be deleted or brought up to date, but that is Doom9's responsibility. Many have complained about this.

I see, I'll be wary of them in the future.

[Guest]

You have given me the D2V for the VOB. That is not usable with the M2V you gave me. Please either give me a VOB sample that we can both use, or make the project with the M2V.

If you are getting a field order transition with the VOB, you may have inadvertently ripped multiple angles. Please make sure your ripper delivers only one angle.

I recommend you to give me a VOB sample cut with DGSplit that we can both work from.

[robo731]

Okay, here's a sample vob (https://mega.co.nz/#!PQsGQbRa!HkxHcVvgoO1WDRs5kAICIjLbI_E5aabfOFVWN5pmJJg)and it's corresponding d2v (https://mega.co.nz/#!mEUjxLyQ!SvUcVgSOKBVtBGxYXEf001VsT18Q2R2FINtONj5pa_g)created with DGSplit.