Not at all :!:
It means you're very focused on the changes :)

-kwag

Hi kwag:
and thank you. At last, here's the answer to my oooold question: with higher action, and higher nf value, radius=2/nf trend to 0, and that means...
Kwag wrote:With radius 0 the filter has no effect, but iit's still switched "ON".
What about last two parameters?, should we test 1,2, or 15,2, or leave it as it is?.

[ non-sense ]

After all this, is the current posted Optimal MA script the right one?

Was wondering the same thing as NickSteel here... Not too sure but it doesn't look like the MA script has been updated to reflect any of the discussions in this thread. Kwag, have we come to a consensus on what the latest MA should be?

Also, I was wondering about the use of Limiter(). A lot of people have been dropping it because it makes some fade-to-black scenes look more like fade-to-black-with-dancing-grey-squares (at least that's what I observed). Have you given any thought to getting rid of it?

Thanks!

The current MA script, as posted, works just fine ;) I always use limiter in my scripts. Never had a problem :!:

-kwag

I never use it, and never had problems too :!: ;-)

Why continue to use something that has NO benefits (and some problems...) ?

No benefit :?:
What happens if you get a source that has a Y range of 0 to 255 :?:
If your source is 16 to 235, it doesn't hurt to have Limiter(), because it won't clip anything. But if it does have a range of 0 to 255, limiter will clip it to the boundaries of 16 to 235, which is what we need for TV scale.

-kwag

TMPGENC will limit the value itself !
We all have the option "output YUV as basic YCbCr" uncheck (it's the default). And that leads to the same limitation in the output range.

You're right, 16-235 it's what we need. But as told just above, usign tmpgenc, the 0-255 doesn't reach the TV.

Right, but what about if you are using some other encoder :?:
I didn't make the MA script specifically for TMPEG :!:
It was designed with any encoder in mind :cool:

-kwag

That's only "playing on the words" :-).

We give all the time advices that are "TMPGENC only". CQ mode is tmpgenc only. CQ_VBR also. No one will suffer with an other one ;-)

More, CCE for instance can't stand with the optimal script without a "ConvertToYUY2()" at the end. The MA script is not universal :lol:

Yes it can, if you've put xvid.dll or divx.dll as the YV12 decoder in the registry :lol: I believe that Helix has a YV12 decoder too.

I still wouldn't let any of those do the decoding, I trust the Avisynth internal functions a lot more.

Strange thing Boulder and Dialhot, because I've ran a lot of tests with CCE 2.66 and 2.67 and our famous MA script.
But I was never able to encode a full movie even if I used KillAudio() or ConvertToYUY2...
I wounder why but CCE always starts encoding fine but it usually displays something about "illegal memory...performed by Avisynth" after a few minutes of encoding.
Please note that I allways aimed for resolutions of 544/704x576 because I noticed it worked fine with 528x576.
Anyway besides being a lot slower than CCE, TMPG is A LOT better than CCE :D

Reinstall your Avisynth using the newest one avaiable. Second ... be shure all needed codes are onboard of your machine. I never had problems using .avs's which do serve a YV12, RGB32 or YUY2 Stream to CCE
Depends on the Bitrate and your settings in CCE ;-)
In case of OneCD Encodings I shurely use TmpgEnc but if I do encode movies to a KDVD using a avg bitrate of ca. 2000kbit and above I use CCE mpeg2 with a fast manual prediction.

I've also got something a little interesting going on... I use CCE almost exclusively now and NEVER have to add the line ConvertToYUY2() anymore. I'm not too sure how or why, but I think it may have been when I upgraded Avisynth to 2.5.3, or one of the recent betas before that.

Hi, I was using AVS 2.52 and now I have AVS 2.53 but still I have problems with CCE 2.66/2.67.
And then I got lost on the 2nd part of your post.
Could you elaborate a bit more on what you meant by needed codes?
Thnx.

I think what incredible meant to say was make sure you have all the needed CODECS, not codes. Meaning, you need to make sure you have divx/xvid video codecs, or mp3/ac3/ogg audio codecs, etc properly installed.

J-Wo is right! :D

Hmm,
But I only use VOB sources and I encode the audio separatly to MP2 with HeadAC3...
Even stranger than the above:
Since I moved to AVS 2.53 I had to start using ConvertToYUY2 on my scripts, otherwise TMPG won't accept it.

I've often found problems with avs are solved by uninstalling it completely, then reinstalling it. Don't worry, your existing plugins folder will remain intact so you don't have to redownload them over again. Also, make sure you have the latest version of mpeg2dec3.dll, which is v1.1 and availble at http://nic.dnsalias.com/mpeg2dec3.html. Ensure that you don't have any other versions of mpeg2dec lying around in your plugin folder. Also, what version of dvd2avi are you using to handle your VOBs? Could you post a copy of the avs script you're using?

I am using both DVD2AVI and MPEG2DEC3 changed by Donald Graft.
In fact I've been using the new MA script and I only add "monitor filter" just so that in CCE I can see in what scene of the encoding I am.
Thanks for the interest in my prob.
C ya

Hey, guys, just wanted to clarify some things for myself with the new script. So we can remove MergeChroma(blur(MaxTreshold)) and MergeLuma(blur(0.1)) now, right? and why is there two Limiter() statements?
Thanks

At the beginning of this thread you'll find this:
So do it as recommended.

Ok, thanks. Keep MergeChroma(blur(MaxTreshold)), right? and what about the Limiter statements?

There's no Blur using the MaxThreshold Variable anymore!
Watch the latest release of MA and use exactly that one.

No matter if its needed or not .. I don't use limiter() anymore cause it only CUTS!!! the luma range at its beginning and the end ... and Im not shure if TmpgEnc does it also.
So you can decide or better "see" what results if just using TmpgEncs internal Luma TV prevention.