Invert Field Order in Filename Option in DIF4U and Top Field First Option in BatchCCE

[stanjr]

All,

After working through most of the BatchCCEWS/TFF-BFF posts and finally understanding the CCE FAQ concerning the offsetline option in CCE 2.67 and up, it seems that there are two cases for using the DIF4U/BatchCCEWS 0.9.1.3/CCE 2.67-and-above combo (knowing that BatchCCEWS, per Doom9 news on 1/21/04, DOES correctly transfer the offsetline command to CCE).

CASE A (DIF4U "Invert Field Order in Filenames" NOT checked)
--------------------------------------------------------------
If the content to be re-encoded is TFF and the "Invert Field Order in Filenames" in DIF4U is NOT checked, then DIF4U places "TFF" in the filename, which causes BatchCCEWS 0.9.1.3 to NOT CHECK "Top Field First," and therefore correctly set the CCE 2.67-and-above offsetline option to "0."

If the content to be re-encoded is BFF and the "Invert Field Order in Filenames" in DIF4U is still NOT checked, then DIF4U places "BFF" in the filename, which causes BatchCCEWS 0.9.1.3 to CHECK "Top Field First," and therefore correctly set the CCE 2.67-and-above offsetline option to "1."

CASE B (DIF4U "Invert Field Order in Filenames" CHECKED)
------------------------------------------------------------
If the content to be re-encoded is TFF and the "Invert Field Order in Filenames" in DIF4U is CHECKED, then DIF4U places "BFF" in the filename, which causes BatchCCEWS 0.9.1.3 to CHECK "Top Field First," and therefore incorrectly set the CCE 2.67-and-above offsetline option to "1."

If the content to be re-encoded is BFF and the "Invert Field Order in Filenames" in DIF4U is CHECKED, then DIF4U places "TFF" in the filename, which causes BatchCCEWS 0.9.1.3 to NOT CHECK "Top Field First," and therefore incorrectly set the CCE 2.67-and-above offsetline option to "0."

The new Big3 guide states that with this combo (actually, there is no specific version of CCE stated, maybe it is to be used with CCE 2.66-and-below) to take CASE B, which would be wrong for CCE 2.67-and-above; however, the picture in the guide shows CASE A:

-------------------------------------------------------------------
Check Invert Field Order in Filenames and uncheck Suppress Aspect Ratio in Subtitle Filenames. The former option takes care of BatchCCEWS setting the field order inversely to what DIF4U normally reports, so that the parameters are set correctly and ReAuthorist cannot handle the aspect ratio information in subtitle files (doesn't apply here as we're using ScenAid rather than ReAuthorist).
--------------------------------------------------------------

Quoting one of Trahald's posts on 4/6/04 concerning BatchCCEWS passing along settings to CCE:

--------------------------------------------------------------------
actually batchccews does honor the top field first setting with cce 2.67... but what happens is.. if you have top frame first on it sets offsetline to 0... which works fine.. and if you dont check top frame first it does set it to 1 (bff) .. so basically its the opposite of when you use batchccews with say 2.66.. so what im doing now with batchcce/cce2.67 is.. i have dif4u set to inverse the field order.. when batchccews sees bff in the filename it checks top frame first ... and my resulting output is fine.
-------------------------------------------------------------------

This seems to agree with what I think I have deduced from everyone's posts so far, until you state "so what im doing now with batchcce/cce2.67 is.." Did you mean "with batchcce/cce2.66-and-below?"

It seems like if one wanted to encode INTERLACED material as INTERLACED with the combo of BatchCCEWS/CCE 2.67-and-above, they would NOT want to check "Invert Field Order in Filenames."

However, it also seems that the default AVISynth scripts in DIF4U de-interlace interlaced material, so it wouldn't matter if "Invert Field Order in Filenames" was checked or not (and hence "Progressive" typically always being checked in BatchCCEWS).

Does anybody else have any thoughts on this? Have I misunderstood or incorrectly deduced anything? Any input would be helpful for us all, I think.

[idbirch2]

It seems like if one wanted to encode INTERLACED material as INTERLACED with the combo of BatchCCEWS/CCE 2.67-and-above, they would NOT want to check "Invert Field Order in Filenames."

However, it also seems that the default AVISynth scripts in DIF4U de-interlace interlaced material, so it wouldn't matter if "Invert Field Order in Filenames" was checked or not (and hence "Progressive" typically always being checked in BatchCCEWS).


I'm pretty sure both your conclusions are incorrect.

I keep my interlaced material interlaced with BatchCCEws/CCE 2.67.00.23 but I do have "Invert Field Order in Filenames" checked and this results in the correct field order being applied. The only problem is that DoItFast4U outputs a version of CCEData.txt that does not contain info about whether the material is interlaced or progressive so I have to manually uncheck the 'Progressive' box in BatchCCEws for all interlaced jobs.

I'm not aware of the default AVISynth scripts de-interlacing cos I don't edit them and my material is not de-interlaced. I think de-interlacing only occurs if you check the "Interlaced" box in DoItFast4U.

[A-Jigga]

My own findings agree with Trahald's post you quoted. With CCE 2.67, checking "Top Field First" in BatchCCEWS sets Offset Line = 0. Therefore, I think you SHOULD check "Invert Field Order" in DIF4U. That way, TFF sources get labeled BFF, causing BatchCCE to check "Top Field First" and set Offset Line to 0. This is how I've encoded interlaced sources lately and it's played properly.

You are correct though about deinterlacing. The default AVS script in DIF4U for material detected as being interlaced (when you have "Autodetect NTSC video type" activated) is to perform a FieldDeinterlace().

If BBWoof does indeed update BatchCCE again, it would be great if all these invert field order and other workarounds (such as VafFix in ECLcce 1.81) could be ironed out and done away with once and for all. It's way more confusing now than it really needs to be.

[influenza]

Well I never get batchccews to work properly. Either checking invert field order or not. I spoke to BBwoof and he also thinks that invert field order needs to be on. But please post all suggestion on batcchccews in the topic about it (too much bad switches). if we are lucky bbwoof will take care of it

[stanjr]

After having said all of the above, I know that BatchCCEWS checks the "Top Field First" based off of the opposite of what the DIF4U filename is, however it is arrived at (a combination of the true nature of the video and the status of the "Invert Field Order in Filenames" switch in DIF4U).

I am not convinced, though, that BatchCCEWS transfers the "Top Field First" status to the "Offset Line" parameter of CCE 2.67. This is how I tried checking it:

1) Opened the ecl file that BatchCCEWS uses when "Top Field First" is checked and noticed that the "offset_line" parameter was 0.

2) Opened that ecl file in EclCCE v1.8b and looked at the Offset Line parameter of the Standard template and it was 1!

3) Opened the ecl file that BatchCCEWS uses when "Top Field First" is NOT checked and noticed that the "offset_line" parameter was 1.

4) Opened that ecl file in EclCCE v1.8b and looked at the Offset Line of the Standard template and it was still 1!

Am I not checking this correctly? Is there even a way to check it?

[influenza]

Maybe RB can clarify this about the correct settings for eclcce

[A-Jigga]

stanjr,

I find that it does transfer as expected into CCE. If I open BatchCCE's ecl (with offset line = 0) in CCE, it does actually set offset line to 0, and vice versa. Make sure you're actually checking the settings for the individual .avs that was loaded (double-click the job listed and look in "Video" settings) and not the Standard Template, as thats not altered by the ecl and doesnt apply.

[stanjr]

A-Jigga, you're right! So this is the synopsis (CASE A and CASE B in my original post revised):

CASE A
--------------------------------------------------------
Content = TFF/BFF
Filename w/o invert = TFF/BFF
BatchCCEWS 0.9.1.3 "Top Field First" = unchecked/checked
CCE 2.67 via EclCCE 1.8b "Offset Line" = 1/0

If you are not de-interlacing and are encoding as interlaced, this would produce INCORRECT results.

CASE B
--------------------------------
Content = TFF/BFF
Filename w/invert = BFF/TFF
BatchCCEWS 0.9.1.3 "Top Field First" = checked/unchecked
CCE 2.67 via EclCCE 1.8b "Offset Line" = 0/1

If you are not de-interlacing and are encoding as interlaced, this would produce CORRECT results.

Of course, if de-interlacing, it doesn't matter what is checked, except that "Progressive" is in BatchCCEWS.

And, yes, the default AVS script in DIF4U does de-interlace. It seems that to be able to encode as interlaced (without de-interlacing), one would have to do some editing of that script.

[RB]

Originally posted by stanjr
1) Opened the ecl file that BatchCCEWS uses when "Top Field First" is checked and noticed that the "offset_line" parameter was 0.

2) Opened that ecl file in EclCCE v1.8b and looked at the Offset Line parameter of the Standard template and it was 1!

3) Opened the ecl file that BatchCCEWS uses when "Top Field First" is NOT checked and noticed that the "offset_line" parameter was 1.

4) Opened that ecl file in EclCCE v1.8b and looked at the Offset Line of the Standard template and it was still 1!

The options in the ECL file have nothing to do with the standard template. The ECL doesn't modify any template. I think you just looked in the wrong place. After loading the ECL, double click on each list item in CCE and click the "Video..." button. The Offset Line parameter should be set correctly.

[influenza]

I noticed that with the latest CCE and batchccews TFF needs to be checked if the source if TFF. Yes this is contradictionary to every guide written :scared:

[Trahald]

Originally posted by influenza
I noticed that with the latest CCE and batchccews TFF needs to be checked if the source if TFF. Yes this is contradictionary to every guide written :scared:

thats because batchcce sends the correct command for 2.67.
for 2.66 you do have to set uncheck tff for tff material

what im thinking is when you check tff in batch cce. batchcce sets a tff_flag = 0 internally. unchecked tff_flag = 1. so when it makes the script it either sets offsetline=tff_flag (for 2.67) or upperfieldfirst=tff_flag (for 2.66) *sortof a oversimplification but will do for this example*

problem is upperfieldfirst=0 is not correct to send to cce for top field first material. so the word got out just to not check top field first, batchcce would then set tff_flag to 1 so upperfieldfirst = 1 would be sent to cce, and all is well

now cce 2.67 comes along and then, voila! the paramater actually is correct. offsetline=0 is proper for top frame first. so now checking tff is the right thing to do in this case