BatchCCEWS 0.9.1.5 beta

[Trahald]

BBWoof has just released 0.9.1.5 beta

Download at www.WoofSoft.com (http://www.woofsoft.com)

TFF/BFF now read correctly from cce_data.txt
*So Invert Field Order DIF4u option is no longer needed

Top Frame First setting sent correctly to CCE all versions (verified)

Close GOP toggle option added

Change GOP N/M setting option added

various others...

[JuanC]

Good! From the changelog:
0.9.1.5
* Really, really, really, fixed the TFF/BFF issues. The switch in
DIF4U should no longer be required.
* Add "Close All GOPs" to the encoding options.
* Add "GOP (N/M)" to the encoding options. GOP length is based on these two
values, and there is no sanity check yet.
* Added all ecl settings to the debug log information.
* Fixed the incorrect numbering of the quantization matrices.
* Fixed the bug causing the program not to respect an alternate output
directory.
* Fixed the bug causing CCE 2.50 to only do a 1 pass RobShot when multiple
passes were selected. I just noticed the numbering of the quatization matrices was wrong (in BCCE they were ordered in a different way than in CCE: alphabeticaly :(), but there's still something missing:

No matter what matrix you choose for a job, it will always use the one from the selected template, so if you have several jobs in the same batch, using the same tamplate (say for example "Robshot-Back") it will always use the same matrix defined in that template for all those jobs. It won't use the one you chose for each job. I hope BBWoof can figure out a way to enhance this feature.

[DaRtHmAuL]

Hi,
to fix this little problem, you have to open regedit and export the template you often use (HKEY_CURRENT_USER\Software\WoofSoft\BatchCCEWS\template\1 for me). Edit the *.reg file with notepad and change the settings in red with yours:
[HKEY_CURRENT_USER\Software\WoofSoft\BatchCCEWS\template\1]
@="Multipass VBR"

like :
[HKEY_CURRENT_USER\Software\WoofSoft\BatchCCEWS\template\4]
@="Multipass VBR (Bonus)"
After that, just import the new *.reg into your registry.
Finally, you need to modify the (Default) string value in HKEY_CURRENT_USER\Software\WoofSoft\BatchCCEWS\template\.
Put 01234 if your last template is the fifth (numbered 4).
By this way, you can create a template for a video type to encode (at differents bitrates) to avoid the use of the same template for all jobs.
cya

[JuanC]

@DaRtHmAuL:

Thanks, that's an elegant workaround. I will try it.

[stanjr]

Per Eyes' quote:

BBWoof: actually the intent was to have the source's type analyzed, not the output. Which in retrospect seems wrong, as you would need the output type. If it's instead showing the output type, I'm amazed because I don't remember coding that! LOL

....and noticing how the new BatchCCEWS (v0.9.1.5) works, which it uses the file names to check (or not check) switches to send to CCE....the filenames being based on the SOURCE, not the OUTPUT of DoItFast4U (per Eyes)...

...it seems that switches will be set incorrectly if the default avs scripts for DoItFast4U are kept. In particular, the script for interlaced material, because the default in DoItFast4U is to DE-interlace this material. It does do this, I've noticed, after checking it.

So, in the case of interlaced material, it is getting named I-TFF; however, it is getting de-interlaced with the default DoItFast4U script. And then, BatchCCEWS 0.9.1.5 is unchecking Progressive and checking Alternate Scan and also checking Top Field First. All this would be correct, I am assuming, if I delete what is set as the default in DoItFast4U for interlaced material.

Should I remove all that is in the script for interlaced material in DoItFast4U, or will scanning of scripts by BatchCCEWS be added to correctly set the switches to be sent to CCE?

Also, a quickie.... if de-interlacing is not done will that change the bit rate calculations for encoding?

[BBWoof]

Originally posted by JuanC
No matter what matrix you choose for a job, it will always use the one from the selected template, so if you have several jobs in the same batch, using the same tamplate (say for example "Robshot-Back") it will always use the same matrix defined in that template for all those jobs. It won't use the one you chose for each job. I hope BBWoof can figure out a way to enhance this feature.

Rasinfrackin!!!!!!

I'll check out why this is happening. And have it fixed for the 0.9.1.6 version release.

BBWoof

[BBWoof]

Originally posted by JuanC
@DaRtHmAuL:

Thanks, that's an elegant workaround. I will try it.

It is a nice way to add templates to the program. You can add as many as you want.

BBWoof

[BBWoof]

Originally posted by stanjr
So, in the case of interlaced material, it is getting named I-TFF; however, it is getting de-interlaced with the default DoItFast4U script. And then, BatchCCEWS 0.9.1.5 is unchecking Progressive and checking Alternate Scan and also checking Top Field First. All this would be correct, I am assuming, if I delete what is set as the default in DoItFast4U for interlaced material.

I was probably premature in releasing the code with these features since DIF4U only marks marks files that have been telecined and decimated to 23.976 with a P. The quickest way to fix it would be to just check the progressive check box for those files that you know have been deinterlaced.

Also, a quickie.... if de-interlacing is not done will that change the bit rate calculations for encoding?

It won't change the bitrate calculation, a 1 hour file that requires a bitrate of 3500 will still require the same bitrate. The quality just won't be as good since it takes higher bitrates to get the same quality on interlaced material.

BBWoof

[BBWoof]

I'd really like to thank everyone here. Over the past couple of weeks users have helped me squash more bugs and add more features than anytime since Eyes Only asked me to code this.

And also, to whomever it was who recently donated $5 to my paypal account. It brings my total donations up to $15. And actually I really, really do appreciate it.

BBWoof

[Trahald]

Originally posted by stanjr
Per Eyes' quote:



....and noticing how the new BatchCCEWS (v0.9.1.5) works, which it uses the file names to check (or not check) switches to send to CCE....the filenames being based on the SOURCE, not the OUTPUT of DoItFast4U (per Eyes)...

...it seems that switches will be set incorrectly if the default avs scripts for DoItFast4U are kept. In particular, the script for interlaced material, because the default in DoItFast4U is to DE-interlace this material. It does do this, I've noticed, after checking it.

So, in the case of interlaced material, it is getting named I-TFF; however, it is getting de-interlaced with the default DoItFast4U script. And then, BatchCCEWS 0.9.1.5 is unchecking Progressive and checking Alternate Scan and also checking Top Field First. All this would be correct, I am assuming, if I delete what is set as the default in DoItFast4U for interlaced material.

Should I remove all that is in the script for interlaced material in DoItFast4U, or will scanning of scripts by BatchCCEWS be added to correctly set the switches to be sent to CCE?

Also, a quickie.... if de-interlacing is not done will that change the bit rate calculations for encoding?

you are right, but the assumption is if you are doing deinterlace (default) then you have Determine Field Order Off (default)

when determine field order is off you will get default for you template (progressive - top frame first)

eyes and bbwoof are discussing parsing the avs for common deinterlacers to determine if interlace should be overridden back to progressive even if i-tff/i-bff was in the filename.

[Trahald]

Originally posted by BBWoof
I was probably premature in releasing the code with these features since DIF4U only marks marks files that have been telecined and decimated to 23.976 with a P. The quickest way to fix it would be to just check the progressive check box for those files that you know have been deinterlaced.


I deinterlace everything so it came in handy ;) As i mentioned in the other post, parsing the avs file may be the only way to detected it.

[NobbyNobbs]

Originally posted by BBWoof
And also, to whomever it was who recently donated $5 to my paypal account. It brings my total donations up to $15. And actually I really, really do appreciate it.

BBWoof

I donated 15$ to Eyes last week, and forgot you.
So if nobody else have donated since your post, I just doubled your total donations :D :D

[SiliconSoul]

Yes they are both great Programs!

I have donated to both of them!
:)

Thanks for another great update BBWoof!
sent you a donation tonight!

[BBWoof]

Again, thanks for the donations. I've actually received donations in the amount of $40 over the last couple of weeks. I plan on only using them for WoofSoft related stuff. This morning I used it to renew my domain for another two years.

BBWoof

[BBWoof]

I'm working on analyzing the avs files to get the interlaced/progressive setting corrected. I'll be looking for Telecide( and FieldDeinterlace( initially. If you know of any other deinterlacing methods I should be looking for please post them here. They can be added to the program at anytime.

BBWoof

[BBWoof]

Is there any interest in having BatchCCE support CCE Basic?

BBWoof

[Trahald]

@bbwoof

one thing i noticed is.. i think when influenza mentioned he would like autoupdating when making changes. i think he was referring to the parameters for just that file and not the template. he will be back shortly to double check with.

as per cce basic.. i think the problem is chapter placement, i beleive it doesnt support that (which is why dvdRB uses cell level encoding to get the I-frames in the right spots). DIF4U supports cell demux but generally its not used as it will take alot of effort to put the scenario together.

[Trahald]

Support for quenc would be a nice. although its a totally different encoder.

[walkistalki]

Hi,

it might be me, but since the update i got a bit confused with which settings to use. Could someone clarify which steps have to be taken now?

** Really, really, really, fixed the TFF/BFF issues. The switch in DIF4U should no longer be required **

Which switch are we exactly talking about here? (Invert fieldorder on filename?)


* Add "Close All GOPs" to the encoding options.
* Add "GOP (N/M)" to the encoding options. GOP length is based on these two values, and there is no sanity check yet.

Do we need to change anything on these files?

Basically with this new version, can i leave everything as it is set by BatchCCE when importing the script file or are some manually adjustments still required?

thanks for clarifying

[BBWoof]

You still need to set the progressive setting for any jobs that you know have been deinterlaced. Unless you know what you're doing you should probably not mess with close all gops or gop structure.

BBWoof

[influenza]

one thing i noticed is.. i think when influenza mentioned he would like autoupdating when making changes. i think he was referring to the parameters for just that file and not the template

exactly. I think it's easy that the parameters are just updated without pressing replace (for that job). Or is it just me who forgets to press replace evry now and then :D

[lineman]

Hey BBWoof

Curious why in this beta the encoding options, do not reuse a previously made .vaf file. An example is an encode that turns out to large, and I want to re-encode it, BatchCCE remakes the .vaf again. I know that in earlier version this was not the case. Just curious!

Lineman

[BBWoof]

Originally posted by lineman
Hey BBWoof

Curious why in this beta the encoding options, do not reuse a previously made .vaf file. An example is an encode that turns out to large, and I want to re-encode it, BatchCCE remakes the .vaf again. I know that in earlier version this was not the case. Just curious!

Lineman

Hey Lineman,

Long time no hear from :) How the heck are ya?

It's probably because I'm actually using the proper settings in the ecl file. Might not be a bad option to add though.

BBWoof

[influenza]

Bbwoof let me take the oportunity to thank you! It's nice you've taken the time to further develop batchccews. Especially since a lot of people find it very usefull program. :)

[seewen]

It seems that there's some little bugs with 0.9.1.5beta:

1) Create a job in Batchccews (check "Top field first"). Then simply save it as CCEDATA.txt file.
try to open this new CCEDATA.txt, and you'll see that the job is different. Top field first is unchecked, and Aspect Ratio disapeard(beccause it's value = 2 in the *.txt).
The same happend if you open a job list created by DIF4U or any other software, and try to save it.

2)Some template (regedit) values cannot be changed: "Alternate Scan" is always checked (try to change the value from 0 to 1 or whatever), "Progressive" and "Top field first" too.
I didn't try all, but "Close all GOPs", "Quality", "Bias" can be changed.

3) maybe it's a feature, I don't know. But "One pass VBR" template cannot be changed. If you try to change any values (like "Close GOPS"), BatchCCEws reset it to default next time it loads.


EDIT :

4) It's impossible to create a other template which use "One pass VBR". If you try to create one, which is the exact copy of the original "One Pass VBR", and rename it to "One Pass VBR (new)", it doesn't works.
When looking to *.ecl, BatchCCEws doesn't write "opv_q_factor=" nor "vbr_bias".


bye

[atcronin]

for safe dvd compliant mpeg2 use should close all gops be ticked or not?

i havnt been able to find a definate answer yet, apart from the "Unless you know what you're doing you should probably not mess with close all gops or gop structure." but from that im not sure if he means to leave it ticked or not.

thanks.

[iparout]

Hi.

I think I've found a bug in the newest version, which seems to also appear in the previous version of Scenaid (0.9.0.23), but not in the first version of the program (0.9.0.5).

The error log is this :

Procedure Name: Item
Module Name: PG

Error Number: 9
Error Description: Subscript out of range
Error Source: ErrorHandler
Error Line: 1
Call Stack:
Item --> PG
BuildLayout --> IFOFunctions
ProcessIFO --> IFOFunctions
ProcessDIF --> Form1
DIF_Browse_Click --> Form1

More detailed thread about the problem is here (http://forum.doom9.org/showthread.php?s=&threadid=77973)

[MAPE]

Hi, amazing tool. I wonder if you are planning to ad the limit end credit functions as it is in EclCCE, and recalculate bitrate for the main movie. Another thing I believe it would be useful is the possibility to activate CCE internal filters and to set them manually.
Tks.for your work.

[Steel]

..

[Steel]

Should I also uncheck alternate scan?

[69Mws]

Strange things are happening when saving a file-list:

You can give it a name, but it's saved as "CCEdata.txt" nevertheless. Well, no big problem since you can rename it afterwards. Don't know if that's a bug or a feature.... ;)

Bigger problem is, that not all parameters seem to be written when saving a file-list. When loading a saved file-list, no aspect ratio is set and "Top Field First" is checked, although I didn't check it and however it's also set again to "1" in the registry, although I set it to "0" (Roba-Template in my case).

Greetz & happy testing :D
69Mws

[69Mws]

Originally posted by atcronin
for safe dvd compliant mpeg2 use should close all gops be ticked or not?

i havnt been able to find a definate answer yet, apart from the "Unless you know what you're doing you should probably not mess with close all gops or gop structure." but from that im not sure if he means to leave it ticked or not.

thanks.

Closing all gops is needed for things like multi-angle, as far as I know . So if you're not dealing with multi-angle streams, you don't need that.

Maybe run a search here for "close all gops" and you should find some more answers for that :)

Greetz
69Mws

[69Mws]

Originally posted by Steel
Should I also uncheck alternate scan?

Alternate Scan is for interlaced streams, so if you're dealing with progressive or you are deinterlacing an interlaced stream, don't check Alternate Scan.

And just in case you should wonder about "Top Field First: Yes or No", check the CCE FAQ (http://forum.doom9.org/showthread.php?s=&threadid=53770) (Question 10) :D

Greetz
69Mws

[69Mws]

Originally posted by Trahald
Top Frame First setting sent correctly to CCE all versions (verified)

Gave it a shot today with ECLCCE 1.81 and CCE SP 2.67.00.27, but it doesn't work out.

I unchecked "Top Field First" but when taking a look at the ecl-file during encoding it states "Offset_Line=1" (that's how it's called CCE SP 2.67.xx.xx).

I tried again by configuring EclCCE to use CCE SP 2.66.01.07 and there it's also not set correct, ecl states "Upper_Field_First=1" or so :(

Switched back to BatchCCEWS 0.9.1.3 and there it works at least with CCE SP 2.66.01.07 correctly.

Greetz
69Mws

[JuanC]

Originally posted by 69Mws
... I unchecked "Top Field First" but when taking a look at the ecl-file during encoding it states "Offset_Line=1" (that's how it's called CCE SP 2.67.xx.xx).

I tried again by configuring EclCCE to use CCE SP 2.66.01.07 and there it's also not set correct, ecl states "Upper_Field_First=1" or so :(

Switched back to BatchCCEWS 0.9.1.3 and there it works at least with CCE SP 2.66.01.07 correctly. 0.9.1.5 is more intuitive: If your video clip is Top Field First, you'll need to ckeck "Top Field First", and if it's BottomFF you'll need to uncheck it. (Not the other way around).

Also, remember that previous versions were using the wrong quantization matrix (in BCCE they were numbered in a different way than in CCE). So you should better use 0.9.1.5

[69Mws]

Originally posted by JuanC
0.9.1.5 is more intuitive: If your video clip is Top Field First, you'll need to ckeck "Top Field First", and if it's BottomFF you'll need to uncheck it. (Not the other way around).

Thx for the reply, but you're confusing me a bit, because that's what I do, I don't need Top Field First for my encoding job, so I uncheck it, but it will be activated in the ecl-file nevertheless :confused:

Greetz
69Mws

[Trahald]

Originally posted by 69Mws
Gave it a shot today with ECLCCE 1.81 and CCE SP 2.67.00.27, but it doesn't work out.

I unchecked "Top Field First" but when taking a look at the ecl-file during encoding it states "Offset_Line=1" (that's how it's called CCE SP 2.67.xx.xx).

I tried again by configuring EclCCE to use CCE SP 2.66.01.07 and there it's also not set correct, ecl states "Upper_Field_First=1" or so :(

Switched back to BatchCCEWS 0.9.1.3 and there it works at least with CCE SP 2.66.01.07 correctly.

Greetz
69Mws

from rb's cce faq --


Q11: Where is the "Upper Field First" option in CCE-SP 2.67 and CCE-Basic?

In CCE-SP 2.67 and CCE-Basic, this option has been replaced by "Offset Line" (a text input control in Video Settings you can type a line number into). It works exactly like "Upper Field First" in that it tells CCE by how many lines to shift up the video.

Again here is the rule of thumb: Always set "Offset Line" to 0 unless your video is interlaced AND bottom field first in which case you set it to 1. Progressive material is always top field first.[QUOTE]

so what does that mean? bottom field first should have offset_line set to 1... which is what batchcce does

[69Mws]

Originally posted by Trahald
from rb's cce faq --

[QUOTE]

so what does that mean? bottom field first should have offset_line set to 1... which is what batchcce does

Thx Trahald, I know that, my problem is not the meaning of this option and when to use it.

I want to encode a progressive stream, so I uncheck Top Field First in BatchCCE, but when I take a look in the ecl it states Offset_Line=1, but it should be Offset_Line=0 in the ecl when Top Field First has been unchecked in BatchCCE.

Greetz
69Mws

[JuanC]

Originally posted by 69Mws
Thx Trahald, I know that, my problem is not the meaning of this option and when to use it.

I want to encode a progressive stream, so I uncheck Top Field First in BatchCCE, but when I take a look in the ecl it states Offset_Line=1, but it should be Offset_Line=0 in the ecl when Top Field First has been unchecked in BatchCCE.

Greetz
69Mws As I said before. The TFF/BFF behavior of BCCE changed in the last version (it is more intuitive now). If you want your progressive video to be encoded by CCE as TFF, you *must* check "Top Field First" in BCCE.

Give it a try and please post your findings... I have done so, but I'm not at home where I have my stuff.

[69Mws]

Originally posted by JuanC
If you want your progressive video to be encoded by CCE as TFF, you *must* check "Top Field First" in BCCE.

Yeah, but that's exactly the issue, I DON'T want my progressive video to be encoded as TFF, so what do I do? Right, I don't check the option in BCCEWS. But when I take a look into the ecl during encoding I can see that it encodes with TFF turned on (Offset_Line=1 is set in the ecl). Now is that it what you like to call "intuitive"? :D ;)

Of course I tried it, that's why I'm posting here like a maniac :D

Maybe try it on your machine. Load up an avs-scipt in BCCE, check "Progressive" and deactivate TFF, start the job and then take a look into the ecl with a text-editor whether it encodes with TFF turned on or not.

As I said, my problem is not about when to use TFF, I'm quite aware of that. What I'm saying is, that this parameter is not written right to the ecl by BCCEWS.

Greetz
69Mws

[JuanC]

Originally posted by 69Mws
... I DON'T want my progressive video to be encoded as TFF ... Why? Is there any reason? I thought it was unimportant for a progressive video to be encoded/flagged as TFF or BFF. But, here, from de CCE FAQ: ... (Q10) ... So here is the rule of thumb: Always uncheck "Upper Field First" unless your video is interlaced AND bottom field first. Progressive material is always top field first. ... But remember, in this last version of BCCE the TFF/BFF behavior is inverted: If you check "Top Field First" it will instruct CCE to not change the field dominance. And Viceversa: If you uncheck it, it will reverse the field dominance, so our rule of thumb for this version (0.9.1.5) of BCCE would be something like:

Always check "Top Field First" unless your video is interlaced, AND you want to reverse the field dominance of your video, whatever it was originally. (The resulting encode would always be flagged as BFF).

We could also check in the resulting mpeg2 video to see how it is being marked: TFF/BFF?

[69Mws]

Originally posted by JuanC
Why? Is there any reason? I thought it was unimportant for a progressive video to be encoded/flagged as TFF or BFF. But, here, from de CCE FAQ: In this last version of BCCE we would have something like:

Always check "Top Field First" unless your video is interlaced, AND you want to reverse the field dominance of your video, whatever it was originally. (The resulting encode would be flagged as BFF)[b]Progressive material is always top field first.

We could also check in the resulting mpeg2 video to see how it is being marked: TFF/BFF?

That's the point, it makes no sense encoding progressive with Top Field First "on" (I also read the CCE FAQ :D ), that's why I always deactivate "Top Field First" in BCCEWS when encoding progressive streams (as also stated in the CCE FAQ), but it sets nevertheless "Offset_Line=1" in the ecl which means it is encoded with Top Field First.

Maybe BBWoof changed the code, because in older BCCE versions (like 0.9.1.3) Top Field First has not been activated in the ecl when you didn't check the option in BCCE. If that's the case, I didn't see that pointed out in a changelog or so :(

Couldn't test that though, 'cause I have encoding jobs running and as we all know, you can't have more than one active instance of EclCCE .... ;)

Greetz
69Mws

[69Mws]

After a short testing, so here's the deal:

BBWoof seems to have changed the code. I tried again with BCCE 0.9.1.5 and CCE 2.67.00.27.

I checked "Progressive" and "Top Field First", the resulting ecl shows "Offset_Line=0", which means it doesn't encode it as TFF, which again means a different behaviour to previous BCCE versions, as stated before.

That's what my confusion was all about.

Greetz
69Mws

[SiliconSoul]

Originally posted by 69Mws
Yeah, but that's exactly the issue, I DON'T want my progressive video to be encoded as TFF,

i think before you go any further you should read this

Q10 CCE FAQ

So how do we set it right? First, you have to know that CCE (SP as well as Basic) always outputs video that is flagged "top field first" (there is a flag in the MPEG header that tells the player which field of the decoded frame to display first on a TV screen). There is no way in CCE to change this. According to Custom Technology, this is not a bug but a feature of CCE... Actually what happens if you check "Upper Field First" is that CCE assumes that source is bff and converts it to tff so it complies with the always set tff flag. It does so by shifting each frame up by one line, ensuring that the previously bottom fields are now top fields and the video is played back correctly. This is not the most sophisticated way to handle the situation, but it works and you won't notice the missing line at the top.



i do not understand how you got so confused with this problem! :)

its rather easy follow the CCE faq and for this version of Batchcce Reverse the tff option.

the reason it was done because it makes more sense this way because thats how cce outputs it if you like it or not.

[69Mws]

Originally posted by SiliconSoul
i think before you go any further you should read this



i do not understand how you got so confused with this problem! :)

its rather easy follow the CCE faq and for this version of Batchcce Reverse the tff option.

the reason it was done because it makes more sense this way because thats how cce outputs it if you like it or not.

Hi SiliconSoul,

I know the CCE FAQ quite well, but don't forget that it's written for setting up CCE manually, not through BCCE (and until now turning on the tff-option in BCCE caused turning on the tff-option inside CCE) ;)

Like I said before, my problem was not about "when do I need tff and when not" and stuff like that.

Maybe this clears out my "confusion" a little bit:

The confusing thing about this was simply that I used BCCE for quite some time and in previous versions checking TFF-Option in BCCE meant that in CCE TFF/Offset_Line option has been activated (e.g. for encoding interlaced bff stuff) and now it's the other way round. By checking the TFF option BCCE it won't get activated in CCE and if you don't check it, tff-option will be activated inside CCE.

Sure it's no big deal and it's even more logical imho, cause now the setting in BCCE is based on your source material, but if you don't know that and are used to "TFF-handling" of previous BCCE versions, well, it's confusing and I assumed kinda bug or so. Of course I read in the changelog that there were made changes to the TFF stuff (I guess in order to conform with the file-names generated by DIF4U) but it didn't say clearly what has been changed.

And now when a function that behaved until now in a certain manner, does something different, well, you get confused... :D

That was the behaviour in previous BCCE versions:
TFF-checkbox in BCCE: 1
-> TFF-checkbox in CCE: 1

TFF-checkbox in BCCE: 0
-> TFF-checkbox in CCE: 0

and now:
TFF-checkbox in BCCE: 1
-> TFF-checkbox in CCE: 0

TFF-checkbox in BCCE: 0
-> TFF-checkbox in CCE: 1

Maybe it's because I also use BCCE quite often "standalone" for several jobs and not only in the process of the "big3", where all settings in BCCE are done automatically through a generated file-list.

Now let's forget about all that stuff, I know how to use now the tff-paramter compared to the older BCCE versions and everything's fine again :D

Greetz
69Mws

P.S.: BCCE rocks :D

[Trahald]

@69Mws

ahhhh.. i guess as long as your happy ;)

[Jim66]

how can i use a costum matrix with batchccews ?

[MicroMij]

I found out that when using CCE 2.67.00.27 (and batchccews 1.9.5.0), it does the first/single pass twice before starting reencoding. Anyone else noticed this?

Guess CCE automaticly does a single pass when starting a multipass encode?

[JuanC]

Originally posted by MicroMij
I found out that when using CCE 2.67.00.27 (and batchccews 1.9.5.0), it does the first/single pass twice before starting reencoding. Anyone else noticed this?... That's not normal: Do you mean the vaf creation? Is it creating the vaf file twice? If so, make sure you are using BatchCCEWS v0.9.1.5 beta & ECLCCE 1.81 and check your ECLCCE.INI file (usually in the woosoft\batchccews folder) for the parameters VafFix and create_new_vaf. They should be =0, or shouldn't exist. Hope that helps.

[MicroMij]

I Use BatchCCEWS 0.9.1.5 beta (sorry about the mixup) and ECLCCE 1.81 but VafFix was set to 1 in my ini. Changed it now. Hope it works.

btw, the guide on doom9:
If you're using EclCCE 1.81, make sure you set VafFix=1 in the [EclCCE] section of the EclCCE.ini file or you could experience quality degradation.this isn't true?