DoItFast4U/BatchCCEws not setting interlaced flag correctly

[idbirch2]

I don't know which program is the problem but I'm finding that DoItFast4U correctly distinguishes between progressive and interlaced but when the encoding jobs appear in BatchCCEws all jobs are set to progressive. For interlaced material I'm having to manually uncheck 'Progressive' in BatchCCEws. Can anyone tell me where BatchCCEws gets its settings from for each job?

If it makes any difference I'm using the DoItFast4U/ReAuthorist/BatchCCEws combination. Because I use ReAuthorist but also want to use BatchCCEws I have used the trick of installing DoCCE4U but then copying the BatchCCEws program into the DoCCE4U folder and renaming BatchCCEws.exe to DoCCE4U.exe. Is this part of my problem?

I don't mind having to manually set Interlaced/Progressive but having just downloaded the new 1.4.7.0 beta of DoItFast4U I wanted to try the new DoCCE4U/SceneAid combo but there was no pause when BatchCCEws was launched for me to change some of the jobs to interlaced.

Basically, what I want to know is: what do I need to do so that BatchCCEws automatically sets progressive/interlaced check boxes correctly?

Thanks for any help.

[Angelus]

I think they're always set to progressive b/c in the Avisynth Script, interlaced materials are deinterlaced. Thus when the material is encoded, it *is* progressive.

[idbirch2]

No, nothing is being deinterlaced. If I leave Progressive checked I end up with the 'shakey' affect. I just want to know if its possible to make BatchCCEws deselect 'Progressive' for interlaced stuff (PAL extras & episodes)

[n1ck0s]

(I think) The distinction is made by the filenames... Are the filenames correct? I always get an I-BFF...

[TuRiSOft]

There's a bug when DIF4U writes down CCEData.txt file.
If you take a look at the documentation that comes with BCCE4U you'll find that there's a flag that has to be set to 0 for Interlaced encoding, to 1 for Progressive and to -1 for Autoset (probably based on Filename).

The bug is that DIF4U ever sets it to 1 then all you can do is :
1.change the flag manually after BCCE4U loaded the job list;
2.change the flag manually into CCEData.txt file.

Due to this bug , I suggest you to spend a bit more time and take a look at your assets with Bitrate viewer , just to make sure the flags that you'll set will be right , and , furthermore , if the original (interlaced) material uses Alternate or Zig Zag scanning order to make the final file just as like as the original.

(I don't know what changes between Alternate and Zig Zag , but I prefer to set this flag as the original one , I think "If they've done so , there must be a (good?!?) reason)

@n1ck0

I hope you're using DOCCE4U instead of BCCE4U or (BY your I-BFF result) I think you'll get your movies flickering in the few last bottom lines.
This because the most number of movies in PAL region are I-TFF and DIF4U reverts this only if you are using DOCCE4U and if you set the radio button "Flip TFF for use with DOCCE4u" in "Other Options" dialog.
Take care with those settings.
They can make you waste your time with unusable final results!!!!!

Goodbye!!!!

[idbirch2]

I think) The distinction is made by the filenames... Are the filenames correct? I always get an I-BFF...

Yes, I think I might have suggested the 'I' meaning interlaced in another thread to you but I've since read that the I just means that the file name has been inverted for DoCCE4U's benefit.

Due to this bug , I suggest you to spend a bit more time and take a look at your assets with Bitrate viewer , just to make sure the flags that you'll set will be right , and , furthermore , if the original (interlaced) material uses Alternate or Zig Zag scanning order to make the final file just as like as the original

Yes, I already know that I need to manually check for interlaced material but its much quicker and easier to just open the demuxed *.M2V file in Media Player as the combing lines on interlaced are as plain as day. BitrateViewer, I've found, is full of crap when it comes to analysing PAL, interlaced material.

Also, I don't know if your a PAL man but its very simple with PAL (UK) DVDs - main movie is always progressive, extras or episodes are always interlaced (and usually 4:3), so most of the time you can set the right flags without even checking. Please don't anyone reply saying "Yes but I did a PAL DVD once and the main movie was interlaced". I'm sure it was its just I've never, ever, ever seen one in the last 3 years of ripping.

Is this really a DoItFast4U bug? The way you describe it (and I mean absolutely no offence when I say this) makes it sound like a bug that could be fixed in minutes - a flag being set to 0 instead of 1 - is it really that simple? I'm no programmer so maybe it is complicated - it just sounds easy.

Hopefully Eyes will step in and clear this up for us :D

I don't know what changes between Alternate and Zig Zag , but I prefer to set this flag as the original one , I think "If they've done so , there must be a (good?!?) reason

I've never use the 'Alternate Scan' box before and can't see any difference when I've tested it - looks identical.

[Trahald]

alternate is not a requirement for interlace at all.. just that due to the nature of how interlace is stored, alternate scan provides a better usage of bitrate.. zig zag is better for progressive.. at least thats what 'the book' says. as i always say.. 'the book' doesnt watch your backups.. you do so.. feel free to stick with what works for you.

as per the progressive flag. well.. doitfast4u saves a cce_data.txt 1.0.0.0 format.. that does not pass interlace flag at all in the cce_data.txt just filename, min/avg/max bitrate , passes, and cce method(bach,vbr,opv,cbr). the rest is actually gotten (well.. suppose to be anyways) from the file name. 'nopull' would mean pulldown is not needed.(the i-bff, etc part) tells it interlaced bottom-frame-first (batchccews will check top frame first in this case).. but for some reason picks progressive. really its a question for bbwoof wherever he is

[idbirch2]

the i-bff, etc part tells it interlaced bottom-frame-first

I've read elsewhere that the 'I' in 'I-BFF' means the filename has been inverted which I think is correct becasue all jobs I put into BatchCCEws, whether they are progressive or interlaced have the 'I' in the file name.

really its a question for bbwoof wherever he is

OK, so one person says its a DoItFast4U issue and another says its BatchCCEws. Like I said, I beleive the 'I' in 'I-BFF' stands for inverted, not interlaced hence BatchCCEws not unchecking 'Progressive' when there's an 'I' in the filename. The CCE_data.txt theory sounds more likely as the DoItFast4U help file states that there is no reliable way of detecting interlaced/progressive in PAL material yet so I think TuRiSOft is right about DoItFast4U simply not specifying Interlaced/Progrssive in the text file.

Eyes? BBWoof? Can you shed any more light on this?

[TuRiSOft]

Originally posted by idbirch2
I've read elsewhere that the 'I' in 'I-BFF' means the filename has been inverted which I think is correct becasue all jobs I put into BatchCCEws, whether they are progressive or interlaced have the 'I' in the file name.

Where?


Originally posted by idbirch2
I believe the 'I' in 'I-BFF' stands for inverted, not interlaced

You're wrong , it means interlaced (and also P stands for Progressive.

I'm sorry , trahald is right , DIF4U writes down a docce.txt ver 1.0.0.0 file.
I wrote so because NEVER real cheked it ,just because my workaround was on BCCE4U after it load the job list , as I described above!


However , we need you , Eyes and bbWoof , to solve this bug for all of us.
thx in advance by TuRiSOft (and all the PAL community as I can think)


@idbirch2

Yes , your way of cheking a stream (MediaPlayer) , is also right , and if you don't see any combing artifact on your video you can encode your video as Progressive , but that just because CCE works in YUY2 colorspace , where the chroma part is stored the same way for both interlaced and progressive material , but if CCE was able to decode YV12 you must distinguish(is this the right word?) them.

[n1ck0s]

Originally posted by TuRiSOft
@n1ck0

I hope you're using DOCCE4U instead of BCCE4U or (BY your I-BFF result) I think you'll get your movies flickering in the few last bottom lines.
This because the most number of movies in PAL region are I-TFF and DIF4U reverts this only if you are using DOCCE4U and if you set the radio button "Flip TFF for use with DOCCE4u" in "Other Options" dialog.
Take care with those settings.
They can make you waste your time with unusable final results!!!!!

Goodbye!!!! I always check those things manually and make appropriate changes within BatceCCEWS. I dont trust DIF4U, BatchCCEWS or BitrateViewer for detection of this attributes because:

-> I always get an I-BFF in the filename.
-> BatchCCEWS sets eveything to Progressive.
-> BitrateViewer... well I'll have to agree w/ idbirch2...

[idbirch2]

@TuRiSOft

I really can't remember where I picked up that Inverted idea!

You're wrong , it means interlaced (and also P stands for Progressive)

OK cool, I just thought that Inverted made more sense seeing as almost all the material I encode is progressive but I never see a 'P' in any of my file names.

I've e-mailed Eyes about this and given him a link to this thread so hopefully he'll step in soon and clear a few things up.

[Trahald]

I talked to flu and he said his 'fix' was to set all the templates to interlaced (HKEY_CURRENT_USER->Software->Woofsoft->BatchCCEWSorDoCCE4U->template

then go through folders 0 through 3 and set the progressive DWORD to 0

at the minimum that would mean you might only have to change the main movie to progressive, instead of all the extras to interlace. and actually if you want you can encode your feature with interlace flag on if you want. (we already know most pal progressive is flagged interlace) thats your choice. flu encodes it all as interlaced. even if youd rather not encode it that way.. its still less work to set the few progressive pgcs to progressive (if any) than having to set most of them to interlaced.

this is a temporary measure for the 'no-deinterlace' crowd until bbwoof can be contacted (i think most people have gotten acustomed to hand setting the parameters especially since many prefer to use their own bff/tff detection techniques)

[influenza]

Trahald is quite right ;)

I have set my template to interlaced and top field first not checked. I live in PAL land and the vast majority of all dvds is encoded the same:

Main movie is progressive, but flagged interlaced (only about 10% of movies is actually flagged as progressive. I noticed a couple of times that when the dvd case said full frame version the flag was progressive, but that not exactly scientific). Almost all extras are interlaced (I only had one dvd once where the extras where progressive) and Top field first.

So the comment I read above that almost all assets are named I-BFF is quite true (that is if you have the invert field order switch on in dif4u). So most video is detected as Interlaced top field first, which is inverted to interlaced bottom field first I-BFF.

So it's absolutely true that even if the video is progressive it's flagged as interlaced. I have tested a future option of dif4u with new detection routines and I can say that the new routines detected it really well, so progressive main movie was actually detected as progressive, even if flagged interlaced. So that's something to look forward to.

An other reason why I've set the template manually is that both docce and batchcce don't pick up on the filenaming for some reason.

So I encode everything as interlaced with TFF switched off as suggested in the CCE faq. Will this affect progressive material? No.

So the advantage is that it won't hurt progressive material and my interlaced material get's encoded correctly as well. So now you wonder what if the video is BFF? Yes in those cases I get it wrong. Since that only happens really rarely I can live with that. I always burn to RW first, so when I have one of those cases I do a pulldown on the video, compile the extra again an reburn. But this happens so rarely I cannot remember it. If you're not sure about the field order you can always use tmpgenc, since this software detects it really well.

Is there also a disadvantage? Yes there is if you encode progressive material as interlaced encoding is slightly slower (about 10-15%). So if I have time to change things manually I set the progressive flag on in docce and if I have no time and let docce start encoding automatically from dif4u I take the speed loss (since this is usually overnight I don't care about that too much).