Telecine pattern corrupt

[Pojken Purken]

Ok, this is a tricky one:

Televison series "Cosmos", R1 DVD. One episode is 4 VOBs.

If I make a DVD2AVI project of only ONE of the VOBs and then use SeparateFields() in Avisynth the telecine pattern is a smooth 3-2-3-2-3-2-3-2... when I step field by field.

If I make one DVD2AVI project of all FOUR of the VOBs and use the same Avisynth script the pattern is smooth in some parts but in other parts, that were fine in the first experiment, the video suddenly jumps back and forth like crazy.

Does DVD2AVI screw up the field dominance or the field order for some reason? Any ideas of what's going on here and what I can do to prevent it?

Regards
PP

[manono]

Hi-

Does DVD2AVI screw up the field dominance or the field order for some reason?

Not exactly. You changed it by taking a single vob (I assume not the first one), instead of the whole movie's worth of vobs.

So, if you're going to IVTC with Decomb, and you have Telecide(Order=1), then change to Telecide(Order=0) and you should be OK. Read the Decomb Tutorial that came with Decomb where it says:

Step 1. Determine and Set the Field Order
It is essential to set the field order properly for correct rendering. The field order is set using the mandatory parameter order. Set order=1 for top field first; set order=0 for bottom field first. Because setting it correctly is so important, you are strongly encouraged not to make assumptions about the field order of a clip, but rather to verify the field order using the following procedure.

To determine the field order, make an Avisynth script that serves the raw clip without any processing. If it were an AVI, then just AviSource() would be used. For our examples, we'll use AviSource(). Add a script line to separate the fields using top field first, as follows:

AviSource("your_clip.avi")
AssumeTFF().SeparateFields()
Now serve the script into VirtualDub and find an area with motion. Single step forward through the motion. Note whether the motion progresses always forward as it should, or whether it jumps back and forth as it proceeds. For example, if the field order is wrong, an object moving steadily from left to right would move right, then jump back left a little, then move right again, etc. If the field order is correct, it moves steadily to the right.

If the motion is correct with AssumeTFF().SeparateFields(), then your field order is top field first and you must set order=1. If the motion is incorrect, then your field order is bottom field first and you must set order=0. If you are want to double check things, you can use AssumeBFF.SeparateFields() to check correct operation for bottom field first.

Let's assume we have a top field first clip in the following steps. You would of course use the correct field order for your clip. So far, then, our script is as follows:

AviSource("your_clip.avi")
Telecide(order=1)

[Pojken Purken]

You assumed correctly, it was the third VOB-file of episode 2 I first saw this behaviour with. However, I may not have been clear enough in my first post:

If I take the VOB-files one by one and make a separate DVD2AVI-project for each of them the field order appears to be BFF throughout each of them (this is my workaround for now)

But - if I add ALL VOB-files to DVD2AVI and make ONE project of them, the field order changes during the course of the episode. It even changes during a single scene making the video go forward and backward randomly (it looks to me at least). Decomb seems to be able to match the fields correctly anyhow but a simple Fielddeinterlace() wont work with this project.

I was simply curious if anybody has stumbled upon this behaviour before?

Regards
PP

[manono]

Hi-

If I had read the whole first post of yours carefully, I would have noticed that you mentioned the field order changing in the middle of the movie. So, sorry. I just ran into the problem myself. I don't think that DVD2AVI is responsible for it. I believe the movie was telecined badly. My problem when IVTCing was that VDubMod would crash when hitting the first place where the field order changes (using Decomb 500b13). My solution was to go back to Decomb 410b4 which figures out the field order automatically. But I don't know for sure if this solution will work for you or not.

[Pojken Purken]

Switching to an older version of decomb will work but I still believe the problem lies within DVD2AVI since I get different results depending on if I use one VOB at the time or all VOBs together. Again, I was just curious if someone had experienced the same thing.
If you have the time I would be interested in what your results would be if you only process the VOB where you experienced your field order change.

Regards
PP

[manono]

Hi-

Well, I can confirm what you're experiencing. With the .d2v (made by using Ver. 1.76 of DVD2AVI) made from the vobs for the whole movie, I get crashes in at least 2 places when scrolling the .avs in VDubMod, and in the first place when encoding. I attribute this to a field order change. Interestingly, the field order change, if that's what's causing the crash, isn't at the beginning of the vob in question. But if I make .d2v's from the individual vobs, there's no problem. I'm not sure what that proves, if anything, but there you have it.

[Guest]

Originally posted by Pojken Purken
If I make a DVD2AVI project of only ONE of the VOBs and then use SeparateFields() in Avisynth the telecine pattern is a smooth 3-2-3-2-3-2-3-2... when I step field by field.

If I make one DVD2AVI project of all FOUR of the VOBs and use the same Avisynth script the pattern is smooth in some parts but in other parts, that were fine in the first experiment, the video suddenly jumps back and forth like crazy.

Does DVD2AVI screw up the field dominance or the field order for some reason? Any ideas of what's going on here and what I can do to prevent it? Would it be possible for you to make available for inspection 5 D2V files: 1 each for the 4 VOBs treated separately, and one for the VOBs treated together? That would be the first step towards understanding for me.

BTW, a field order change within a clip would be unplayable, but it should not cause Decomb5 to crash. There must be a bug in Decomb5.

[Pojken Purken]

A 60kb zip-file with the requested d2v-files is available for download here:

http://pp.dyndns.biz/cosmos_e02.zip

I first noticed the problem in a scene in VOB #3 - frames 185-425 (~60120-60360 in the combined d2v) but the same problem occurs in several places in almost every episode (I didn't notice it in episode #1 though).

I'm really appreciating you looking into this problem, Donald. I know you're a busy man...
As stated earlier I can work around the problem by treating each VOB separately but if we can hunt down a bug in DVD2AVI, it might be helpful for others.

Kind regards
PP

[Guest]

The D2Vs are strange and possibly illegal. For example, 1, 2, and 4 are BFF, while 3 is TFF.

At one point in D2V 2, there is a transition from 0->2, which is a really big no-no.

To take this further I need to get these VOBs, to see what is happening to the content at these points of interest. Is it possible for you to burn them to a DVD and mail them to me?

[Pojken Purken]

I think I can manage that. I have a friend who owns a DVD-burner. The VOBs are ripped with DVDDecrypter on my Pioneer 106. Would it be a good idea to first rip the VOBs with another ripper and perhaps on a completely different machine to rule out any hardware or software glitches?
/PP

[Guest]

Originally posted by Pojken Purken
I think I can manage that. I have a friend who owns a DVD-burner. The VOBs are ripped with DVDDecrypter on my Pioneer 106. Would it be a good idea to first rip the VOBs with another ripper and perhaps on a completely different machine to rule out any hardware or software glitches?
/PP Thank you, see your PM for the address. No need to re-rip. Just send the VOBs that you used to make those D2Vs.

[Pojken Purken]

Got your address. Just realized I *need* to buy myself a DVD burner so I'm tracking down a DVR-106 but it will take a few days. Will get back to you as soon as I have it up and running.

Regards
PP

[cheap-red-wine]

See neuron2's new utility Fixd2v:

http://neuron2.net/misc/fixd2v110.zip