Thanks d&c!

I didn't try the 2.08 legacy version yet, I downloaded it only yesterday night.
I'm working now and don't have the scripts here.
I'll try to encode with the avisinth 2.08 legacy installed, and will post the scripts if not solved.

Anyway, thanks a lot folks!!

LaBomba

Ok, I got the error for the first time, on this movie, but I tried 4 different times, and the error keeps coming back at about 30%. Movie is Toy Story 2 :wink: ... I used AviSynth 2.08 Legacy and TMPGEnc 2.58...
this is really annyoing. Here's my script:
:cry:

Hi all...

I just can't seem to get over this problem. Tried 4 more times. Same results.. any other ideas of how to get rid of this? :x

Hi Jellygoose,

Try commenting the DctFilter line.

-kwag

I encountered this error recently on an anime at CQ79 and 704x576. Simple script like :
LoadPlugin("F:\VIDEO\MOVIESTACKER\Filters\MPEG2Dec 2.dll")
LoadPlugin("F:\VIDEO\MOVIESTACKER\Filters\GripFit_ preview.dll")
LoadPlugin("f:\video\avisynth\unfilter.dll")
LoadPlugin("F:\VIDEO\MOVIESTACKER\Filters\LegalCli p.dll")
Mpeg2Source("D:\dvdump\xxxxx.d2v")
LegalClip()
GripCrop(704, 576, overscan=2)
GripSize(resizer="BicubicResize")
unfilter(50,50)
temporalsmoother(1,2)
mergechroma(blur(1.58))
mergeluma(blur(0.2))
GripBorders()
LegalClip()

In the past i remember solving the issue by switching back to MPEG2Dec.dll.In some forums I read about disabling the ReadAVS.dll in TMPGENC (!). I have launched an new encoding changing only this. I should see what happen <=== EDIT : stop the crap. This kills colors. Don't try it.

Reading here (TMPGEnc BBS!!) : http://www.pegasys-inc.co.jp/bbscgi/...ost_10806.html
It gives other ideas (likeun-check the "use floating piont DCT" box). It seems this problem is linked with error in the video source.

Further reading says it can be linked with overclocking... Maybe lowering my ReadAVS prio to 1 instead of 3 now??

Hi everybody!

:lol: I finally cured the problem. After trying every trick recommended, and still having the problem, I tried to encode with TMPGEnc 2.54a.
This worked. No errors, no problems. I won't stick with that version, but I'll use it whenever I come across this prob again!
So everybody, who still gets that error, try this version.

HF

Thanx for the tip Jellygoose.
I have a TMPGEnc Version 2.54.37.135 in my archive, is this the one you've used?

None of the tricks I have used worked by the way...

Yes that's the version. The tricks didn't work for me either. This version cured it! :wink:

Thanx for this swift reply man! :lol:

I am going to try right away, because I had this &$#!! error a second time today. Never happend before. I guess it's because now with last scripts I do MPEG1 544x576 Q>70, which was not the case before...

I haven't had this error in a long time but I did today :cry: I've been using Tmpg ver 2.54.36.134 and Avisynth 2.52

ren

Hi rendalunit..

I'm having trouble of my own (which I"ll be posting a thread on shortly)...

But, I think I may have some form of crazy idea or theory of why U's people
are having this sort of RANDOM crash.

But, let me ask ya..
:?: When you have these crashes, are these from DVD rips ??
:?: and, do they happen w/ the sampe project and/or place in scene ??

I'm theorizing because I am experiencing something that I believe I may
have the answers to (ironically, thanks in part to my VFAPI issues (above
note))

Just trying ta help you narrow down the cultprit :x
Hope ta hear from ya soon.
-vhelp

Hi vhelp,

This particular instance, the source was a dvd rip but it has happened with other type sources before too.

I have a possible theory too- I don't remember this ever happening to me when I was using a CQ value that was a whole number instead of a decimal :idea: The CQ was 73.219 - I'm going to try again with 73 and see if it makes a difference.

Thanks,
ren

>> I'm going to try again with 73 and see if it makes a difference.

Didn't make a difference- crashed again with cq 68 :roll:

Just let TMPGEnc decide on its own, what VBV buffer size it needs.
This has to be done by putting 0 instead of 40 in the VBV field.

In my case, it completely fixed the 'floating point' problems i had.

I haven't seen this problem since I started using Avisynth 2.5x - problem solved (i hope) :D Anyone getting this crash with Avisynth 2.5x :?:

ren

:lol: You just posted above that you had the problem with AviSynth 2.52... :lol:

me looky and me no so no error wit 2.52 :!: Me thinks da bad ting done gone away- yay :lol:

Dudes, this error sux, even with v2.52 :(

//Wolfi

Go and get 2.53 :wink:

Is there a 2.53 version which not includes ffvfw? Had to reinstalled my comp two times in a row cause of that thing :?

//Wolfi

None of the officials release of 2.5.3 included ffvfw. It was removed.

Thank god :P

*edit* So, nomo error with 2.53?

//Wolfi

I used to always load the beta version of 2.5.3 that sh0dan provided to us before the official release and I didn't have any error since a long time.

I'm having the same error as you point out: "illegal floating..."
I have TMPGEnc plus 2.513.53.162 (core 1.96.149). I was using avisynth 2.52. Encoding from a DVD, 528x576, CQ 72.43. MA new script.
After having twice this error, I changed to avisynth 2.53 (build Nov 11 2003). But still have the same error.
I tried to lower CQ to 69.9, but the same error.
What else can I do?. Do I have to change the TMPGEnc Plus version?.
Do you advise me to uncheck SSE and SSE2 in enviromental settings in TMPGEnc?. I tried this, but after half an hour, to encode 1000 frames, and still 8 hours to go, I decided to ask for help first...
Please, help (once again :roll: )

Hi digitall.doc,

Whenever I get one of these "Illegal Float..." errors, the first thing I usually try is bumping up the VBV Buffer in TMPG to 42 or 44, running a new prediction, and re-encoding (many times, this very small VBV boost solves the Illegal Float problems for me). If that still doesn't work, then as a last resort I will set the VBV Buffer to zero (0) and allow TMPG to find its own value (and this last method of using VBV Zero has never failed to fix an Illegal Float problem for me yet).

However, when using a VBV Buffer of zero, there are often numerous video overflow/underflow errors reported by bbmpeg later on during muxing (this is why 0 is not the default setting for KVCDs and why I use it as a last resort). BBmpeg reports that these kinds of muxing errors might make the file play incorrectly in some dvd players (but they have always still played fine in my player, so I don't worry about it).

Good luck, (and thanks again to Cheronaph who was the first person I saw mention this VBV fix way way back! :) )

-d&c

Hi dazed&confused:
BINGO!!. As I expected, you were right, and changing VBV to 44 made the miracle. No problem with my DVD standalone.
Thanx to you, Cheronaph,... everybody.
Maybe, you could ask Kwag to put this solution in the questions section/thread, as it can be of help to other people.

Hi digitall.doc,

You can do that too ;)

-kwag

Hi kwag,
...well, you're right. I suppose I have done it now :lol: . Don't you think it's a good idea?.
I just didn't suggest that because it wasn't my original idea but somebody's else. But no problem with this, if I mention them.
Thanx to take me in such consideration, maestro

Merry Xmas to everybody!