@ shh: FitCD 1.0.4 have wrong interlaced resizing settings

[Bach]

.

[shh]

bicubicresize(xxx,480,b,c)
for a source which is dvd interlaced at 720x480, [...], because the avs output will be as interlaced as the source
No, because you're using a bicubic-filter. So, you're mixing field-information from top- and bottom-fields (from different time-points) what is no good idea. Seperate the fields before you resize.

...the correct script should be
You're using a CCE-optimizing of the macroblock-usage, therefore the destination-size must be 175 (= 2 pixel smaller).
Note, that this does not mean a field-swap or -shift. The fields are just resized a little bit smaller. The fields are weaved together the right way afterwords.
If you don't want that optimizing, uncheck the option and the destination-size will be 176.

Also, there is no difference if you do padding before weaving, and FitCD does it after weaving. So I don't know, what could be wrong with the 'AddBorders' of FitCD.

Please check, that you have UNchecked the "Upper field first"-option in CCE. This often does some ugly things with the field-order.

HOW do you *proof* the field-order-change of FitCDs scripts? (as you say)
With your discriptions, I must point out that everything is going fine. :confused:

Cheers
shh

p.s.
Hmmm, I actually recognize some difference in VirtualDub when weaving before and after adding the boarders.
But this *cannot* mean a field-order change.
Is this mayme a bug of the Weave-command in YUY2-colorspace??
This may occur because FitCD let's avisynth weave with a odd vertical size...

[shh]

Hmm, I understand now how this could be. :rolleyes:

Field-order changes, when odd number of pixel are added above (e.g. 65). Then prior even lines become odd lines...
I'm correcting this in a future version. (very soon)

> Ps: the behaviour is exactly the same if I use 176 instead of 175 and 64 instead of 65 in your script.

This is [still] not possible to my understanding. :)
If just 64pixel are added above (an even number), top-fields and bottom fields stay at the same line, so a field-change cannot occour.

Cheers :)
shh