how to rallenty video and generate "audio-slowmo" (effect) using avisynth?

[poisondeathray]

I recommend you use newer versions . R1576 was released in 2014 . Many bugfixes since then

https://github.com/pinterf/AviSynthPlus/releases

[Groucho]

I recommend you use newer versions . R1576 was released in 2014 . Many bugfixes since then

https://github.com/pinterf/AviSynthPlus/releases

Not to mention that r1576 does not support multi-threading.

[marcorocchini]

I recommend you use newer versions . R1576 was released in 2014 . Many bugfixes since then

https://github.com/pinterf/AviSynthPlus/releases

Not to mention that r1576 does not support multi-threading.

[Attachment 48631 - Click to enlarge]

really ???!???

How is possible? I don't want change avisynth version


From some tests that I had made over certain types of video files I had problems with lost frames or with sync or many other issues, I cannot absolutly change this basement I don't want to have any nasty surprises or having to re-do all the tests again

[poisondeathray]

From some tests that I had made over certain types of video files I had problems with lost frames or with sync or many other issues, I cannot absolutly change this basement I don't want to have any nasty surprises or having to re-do all the tests again

Lost frames, sync issues - those are probably source filter issues

I would upgrade everything, including prerequisites such as mvtools2, masktools, etc... all from the pinterf branch . Lots of improvements, speedups . rgtools, nnedi3 , etc... all have newer versions with improvements, speedups . Some are able to use newer CPU SIMD instructions . AVX2, AVX 512 , etc...

You can still run it in single threaded mode . You can still run this in avs classic tool. But avisynth+ x64 MT is much better, faster and more stable than avs classic MT. If you're running in single threaded mode, then don't complain about speed. If you're using ancient .dll's which do not use modern CPU SIMD like AVX2 etc..., then don't complain about speed....

[marcorocchini]

From some tests that I had made over certain types of video files I had problems with lost frames or with sync or many other issues, I cannot absolutly change this basement I don't want to have any nasty surprises or having to re-do all the tests again

Lost frames, sync issues - those are probably source filter issues

I would upgrade everything, including prerequisites such as mvtools2, masktools, etc... all from the pinterf branch . Lots of improvements, speedups . rgtools, nnedi3 , etc... all have newer versions with improvements, speedups . Some are able to use newer CPU SIMD instructions . AVX2, AVX 512 , etc...

You can still run it in single threaded mode . You can still run this in avs classic tool. But avisynth+ x64 MT is much better, faster and more stable than avs classic MT. If you're running in single threaded mode, then don't complain about speed. If you're using ancient .dll's which do not use modern CPU SIMD like AVX2 etc..., then don't complain about speed....

oh my pooooorr


[Attachment 48632 - Click to enlarge]

is a mission impossible


[Attachment 48633 - Click to enlarge]

[poisondeathray]

It should still work, just slower . (But there might be other bugs if you're using older .dll's and scripts. Many, many bugfixes in various plugins since 2015...)

Just comment out the prefetch line, and SetFilterMTMode lines .

If it's not using all the CPU% resources, you can run multiple simultaneous scripts and encodes

[marcorocchini]

but is there a way to keep 2 versions of avisynth in the same system? or is there a way to recall a different version of avisynth.dll only when request by the script? or simply run a script with a separate version of avisynth?

[poisondeathray]

but is there a way to keep 2 versions of avisynth in the same system? or is there a way to recall a different version of avisynth.dll only when request by the script? or simply run a script with a separate version of avisynth?

You can have x86 , x64 versions on same system . But only one of each

You cannot load an avisynth.dll version within a script, because that avisynth.dll is already loaded at runtime once script is executed

But you can swap version pretty easily . e.g for avisynth+ mt x64 , you just replace the dll in windows/system32 directory if avisynth had already been installed. That's actually how some versions are distributed (the "files only" version) , and that's how I updated the last few versions

I think groucho might have a version changer utility, it might be easier some people



But there are multiple .dll versions for various plugins. You might get errors for mismatched plugins (e.g. older plugin, with newer script), because of different syntax.

And especially the source filter you might need several versions handy. I have dozens ffms2 and lsmash versions readily available - because each one has certain pros/cons and various quirks . e.g. one might have buggy mpeg2 decoding, one might not support png , only newer versions support AV1, one might have wrong framerate, or buggy seeking, or interlace bug , etc...

[Cornucopia]

Use alternate, dedicated VMs. With some format definition branching script for calling one, all of which look to the same watch folder.

Scott

[marcorocchini]

ok but if a script or a batch is using c:\Windows\System32\AviSynth.dll in the same time I think I cannot replace that avisynth.dll with another version because avisynth is in use. The possibility of an "underground temporary replace" of c:\Windows\System32\AviSynth.dll exists only when it is not in use, but I cannot predict it. In my system it is likely that avisynth is in used by the pismo file mount to virtualize some clip. In this case the .dll is locked and a possible dll replacement request would fail.

However please consider this script:

LoadPlugin("V:\automazioneclip\AviSynth\plugins64\ffms2.dll")

LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\mvtools2.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\masktools2.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\RgTools.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\nnedi3.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\DePanEstimate.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\DePan.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\PlanarTools.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\dfttest.dll")
LoadPlugin("V:\automazioneclip\AviSynth\forNewSlowmo64bit\AddGrainC.dll")

Import("v:\automazioneclip\avisynth\plugins\IResize.avsi")

Import("V:\automazioneclip\AviSynth\plugins\smoothFPS2.avsi")
Import("v:\automazioneclip\AviSynth\plugins\FrostyBorders.avsi")
Import("v:\automazioneclip\AviSynth\plugins\CropResizedic2017.avsi")
LoadPlugin("v:\automazioneclip\AviSynth\Lsmash64perVirtualDub64\LSMASHSource.dll")

Import("V:\automazioneclip\AviSynth\forNewSlowmo64bit\AnimeIVTC.avsi")
Import("V:\automazioneclip\AviSynth\forNewSlowmo64bit\SMDegrain.avsi")
Import("V:\automazioneclip\AviSynth\forNewSlowmo64bit\QTGMC.avsi")

LoadCPlugin("v:\automazioneclip\avisynth\plugins64\yadif.dll")  

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)

LWLibavVideoSource("v:\tuttiFormati\testNTSC_PAL_X_SmoothFPS2\PAL\C0001.MXF")
AssumeTFF()
#yadif(1,1)
AssumeTFF()
QTGMC()
q=last

super = q.MSuper(pel=2)
backward_vec = MAnalyse(super, overlap=4, isb = true, search=3)
forward_vec = MAnalyse(super, overlap=4, isb = false, search=3)
q.MFlowFps(super, backward_vec, forward_vec, blend=false, num=65789, den=1000)
AssumeFPS(50)
q2=last

AssumeFPS(50)

AssumeTFF().SeparateFields().SelectEvery(4, 0, 3).Weave()
Prefetch(4)

where C0001.MXF it this:

https://www.dropbox.com/s/2bq7k6oywt78xa3/C0001.MXF?dl=0

I get this result:

https://www.dropbox.com/s/2cqxy9f5ovhftd0/result.avi?dl=0

it's the usual problem that occour using the SmoothFPS2.

Is there a way to avoid the artifacts?

[poisondeathray]

ok but if a script or a batch is using c:\Windows\System32\AviSynth.dll in the same time I think I cannot replace that avisynth.dll with another version because avisynth is in use. The possibility of an "underground temporary replace" of c:\Windows\System32\AviSynth.dll exists only when it is not in use, but I cannot predict it. In my system it is likely that avisynth is in used by the pismo file mount to virtualize some clip. In this case the .dll is locked and a possible dll replacement request would fail.

But I can think of no reason why one would prefer R1576 (2014) over a modern version . None. It's all bug fixes and speedups .

The other things you refer to are more likely from plugins and source filters , not the avisynth version

it's the usual problem that occour using the SmoothFPS2.

Is there a way to avoid the artifacts?

Don't use interpolation (use duplicates or blends instead) for 100% foolproof.

Or try different settings, or different scripts (e.g. framerateconverter) . Some have better artifact masking

As you should already know, you will always get some artifacts to some extent, depending on the source . Some scenes might be unusable, some might only have minor artifacts

[jagabo]

it's the usual problem that occour using the SmoothFPS2.

Interframe lets you tune for distortions vs. blending.

[Groucho]

but is there a way to keep 2 versions of avisynth in the same system? or is there a way to recall a different version of avisynth.dll only when request by the script? or simply run a script with a separate version of avisynth?

There's a nice universal Avisynth installer with which you can switch Avisynth versions in seconds:
https://forum.doom9.org/showthread.php?t=172124

[marcorocchini]

but is there a way to keep 2 versions of avisynth in the same system? or is there a way to recall a different version of avisynth.dll only when request by the script? or simply run a script with a separate version of avisynth?

There's a nice universal Avisynth installer with which you can switch Avisynth versions in seconds:
https://forum.doom9.org/showthread.php?t=172124

ok, thanks, but it can switch even if avisynth is in use by another process?

[Groucho]

but is there a way to keep 2 versions of avisynth in the same system? or is there a way to recall a different version of avisynth.dll only when request by the script? or simply run a script with a separate version of avisynth?

There's a nice universal Avisynth installer with which you can switch Avisynth versions in seconds:
https://forum.doom9.org/showthread.php?t=172124

ok, thanks, but it can switch even if avisynth is in use by another process?

No.

[marcorocchini]

But I can think of no reason why one would prefer R1576 (2014) over a modern version . None. It's all bug fixes and speedups .

The other things you refer to are more likely from plugins and source filters , not the avisynth version

for example: using this script:

LoadPlugin("v:\automazioneclip\AviSynth\Lsmash64perVirtualDub64\LSMASHSource.dll")
LoadPlugin("V:\automazioneclip\AviSynth\plugins64\ffms2.dll")
LoadCPlugin("v:\automazioneclip\avisynth\plugins64\yadif.dll")  
vid=LWLibavVideoSource("C:\Users\Administrator\Desktop\gerace2\GER ACE_ITA.mpeg")          
aud=LWLibavAudioSource("C:\Users\Administrator\Desktop\gerace2\GER ACE_ITA.mpeg",stream_index=0)
left=GetChannel(aud, 1)
right=GetChannel(aud, 2)
both=mergechannels(left, right)
audiodub(vid, both)
ConvertAudioTo16Bit()
ConvertToYUY2(interlaced=false)
colorMatrix(mode="Rec.601->Rec.709")
LanczosResize(1920,1080)
AssumeFPS(25)

where this is the source: https://www.dropbox.com/s/0t87vopan7qxjaa/GER%20ACE_ITA.mpeg?dl=0
this is the loaded 64bit LSMASHSource.dll: https://www.dropbox.com/s/pnto0hit2sssoji/LSMASHSource.dll?dl=0
and this is loded (and not used) 64bit ffms2.dll: https://www.dropbox.com/s/4kiliidyaod7zcq/ffms2.dll?dl=0

Using Avisynth R1576 encoding is ok, using Avisynth R2772 I get a very strange problem where at 99% of the encoding the encoding suddenly becomes very slow and employ 10/12 minutes to complete encoding. The only difference is the avisynth version, not the plugins or filters loaded. This problem occurs on different machines.

I've done a lot of tests for 2 days and lost a lot of time but in the end I think I found that the "problem" is the use of

aud=LWLibavAudioSource("C:\Users\Administrator\Desktop\gerace2\GER ACE_ITA.mpeg",stream_index=0)

instead of FFAudioSource with R2772. So you'll wonder why I don't use it FFAudioSource instead of LWLibavAudioSource.
Because based on some tests I have done in the past I have found that the use of FFAudioSource was problematic on some types of sources as it produced unexpected noises. I produced a folder containing about 100 types of example-sources like the one of the script only to verify that the batches correctly transcode all the possible types of sources. The fact of that version more recent, give a encoding problem weighed catastrophically on the trust to use a system that does not transcode source clips as well. In many journalistic situations it is fundamental to do soon and transcode the clips once and well: there is no time to evaluate or change. If the system fails transcoding there is the risk of panic in many situations where it is necessary to edit quickly and in which the journalist does not admit "losses" of time.

Now that I have identified what is the problem for this specifical script I could - theoretically - change the version of avisynth but first I would have to redo all the tests to verify that all the sources are treated correctly, check them frame-to-frame if there is correspondence and not out of sync, verify also the audio part, verify that there are no crashes (since at least one source seems to crash when using R2772 meanwhile using R1576 seems does not happen). And overall I should also change all the batches they use "LWLibavAudioSource" or change LSMASHSource.dll but i remember that with different version of LSMASHSource.dll I get some frame problems strangely repeated at the beginning of the encoding. It is an extremely long and complex job that risks highlighting results that are sometimes not good even if the encoding speed would be better. This is my "reasons": the fear of a pandemonium caused by the change of avisynth-version. The old version is slower, but at least on the sources I use, produces guaranteed and verified results.
I do not exclude that I will have to change version, but first I need to do all the tests and probably change all the batch (a hellish job) that are anything but simple, and then I am a cat with a limited intelligence-factor so for me it's all even more difficult

[poisondeathray]

for example: using this script:

LoadPlugin("v:\automazioneclip\AviSynth\Lsmash64perVirtualDub64\LSMASHSource.dll")
LoadPlugin("V:\automazioneclip\AviSynth\plugins64\ffms2.dll")
LoadCPlugin("v:\automazioneclip\avisynth\plugins64\yadif.dll")  
vid=LWLibavVideoSource("C:\Users\Administrator\Desktop\gerace2\GER ACE_ITA.mpeg")          
aud=LWLibavAudioSource("C:\Users\Administrator\Desktop\gerace2\GER ACE_ITA.mpeg",stream_index=0)
left=GetChannel(aud, 1)
right=GetChannel(aud, 2)
both=mergechannels(left, right)
audiodub(vid, both)
ConvertAudioTo16Bit()
ConvertToYUY2(interlaced=false)
colorMatrix(mode="Rec.601->Rec.709")
LanczosResize(1920,1080)
AssumeFPS(25)

where this is the source: https://www.dropbox.com/s/0t87vopan7qxjaa/GER%20ACE_ITA.mpeg?dl=0

For that specific source and script, you don't need to mergechannels or ConvertAudioTo16Bit() (it's already 16bit stereo audio )

this is the loaded 64bit LSMASHSource.dll: https://www.dropbox.com/s/pnto0hit2sssoji/LSMASHSource.dll?dl=0

There are missing linked dependencies, probably in the same folder that you didn't upload. The .dll is too small (it's not a static build)

instead of FFAudioSource with R2772. So you'll wonder why I don't use it FFAudioSource instead of LWLibavAudioSource.
Because based on some tests I have done in the past I have found that the use of FFAudioSource was problematic on some types of sources as it produced unexpected noises. I produced a folder containing about 100 types of example-sources like the one of the script only to verify that the batches correctly transcode all the possible types of sources. The fact of that version more recent, give a encoding problem weighed catastrophically on the trust to use a system that does not transcode source clips as well. In many journalistic situations it is fundamental to do soon and transcode the clips once and well: there is no time to evaluate or change. If the system fails transcoding there is the risk of panic in many situations where it is necessary to edit quickly and in which the journalist does not admit "losses" of time.

But which version of ffms2 ? Each version has various quirks, just like lsmash

This is my "reasons": the fear of a pandemonium caused by the change of avisynth-version. The old version is slower, but at least on the sources I use, produces guaranteed and verified results.
I do not exclude that I will have to change version, but first I need to do all the tests and probably change all the batch (a hellish job) that are anything but simple, and then I am a cat with a limited intelligence-factor so for me it's all even more difficult

Yes, it's a good idea to stick to versions and plugins you know work well . Even if they slower , you can run simultaneous encodes

But there might be other problems you didn't "see" yet or didn't realize yet . There are many bugs in the early avisynth+ versions, and plugins. Look at the avisynth+ changelog , and plugin changelogs.

[marcorocchini]

There are missing linked dependencies, probably in the same folder that you didn't upload. The .dll is too small (it's not a static build)

sorry, if you want try unrar this attached package (Lsmash64perVirtualDub64.rar) there is the .dll with other components of dependency in the same folder
I don't know if you can try to reproduce the problem, but even if audio is already 16bit, the use of LWLibavAudioSource instead of FFAudioSource cause a extremely-slow encoding at point 99% of encoding in all version of avisynth afther the R1576 version. I have a lot of batch that have the audio part with "LWLibavAudioSource" and I don't know if the brutal replace with FFaudioSource is a good idea.

From some rapid tests I have use Avisynth R2772, FFMS2 2.23 and LsmashR929: using QTGMC the speed encoding increase from 1,9 fps to 5,2 fps but my problem is the change of all the batch that I have build in 5 years

[poisondeathray]

sorry, if you want try unrar this attached package (Lsmash64perVirtualDub64.rar) there is the .dll with other components of dependency in the same folder
I don't know if you can try to reproduce the problem, but even if audio is already 16bit, the use of LWLibavAudioSource instead of FFAudioSource cause a extremely-slow encoding at point 99% of encoding in all version of avisynth afther the R1576 version. I have a lot of batch that have the audio part with "LWLibavAudioSource" and I don't know if the brutal replace with FFaudioSource is a good idea.

From some rapid tests I have use Avisynth R2772, FFMS2 2.23 and LsmashR929: using QTGMC the speed encoding increase from 1,9 fps to 5,2 fps but my problem is the change of all the batch that I have build in 5 years

I can't reproduce the slowdown in single or multi threaded mode with that lsmash version; with or without the unnecessary getchannels/mergechannels/16 bit audio

[poisondeathray]

How are you encoding it ? what are you feeding the script into ? maybe you have encoder problem ?

Test with avsmeter64 to rule out if it's avisynth or script issue

I can't reproduce your problem with avsmeter64 or ffmpeg encoding libx264/aac

[marcorocchini]

How are you encoding it ? what are you feeding the script into ? maybe you have encoder problem ?

Test with avsmeter64 to rule out if it's avisynth or script issue

I can't reproduce your problem with avsmeter64 or ffmpeg encoding libx264/aac

LoadPlugin("V:\automazioneclip\AviSynth\LSMASH_R929_64bit\LSMASHSource.dll")
vid=LWLibavVideoSource("C:\Users\Administrator\Desktop\gerace\GER ACE_ITA.mpeg")          
aud=LWLibavAudioSource("C:\Users\Administrator\Desktop\gerace\GER ACE_ITA.mpeg",stream_index=0      )
left=GetChannel(aud, 1)
right=GetChannel(aud, 2)
both=mergechannels(left, right)
audiodub(vid, both)
ConvertAudioTo16Bit()
ConvertToYUY2(interlaced=false)
colorMatrix(mode="Rec.601->Rec.709")
LanczosResize(1920,1080)
AssumeFPS(25)

where LSMASHSource.dll is loaded from the attached package LSMASH_R929_64bit.rar (I think is the latest version):

using Avisynth+ R1576 this is the encoding that is ending ok:

https://www.dropbox.com/s/nhe5w4efcbljalf/1576.mp4?dl=0

------------------------------------------------------------------------------------------------------------------------------

but using Avisynth+ R2272 occour the encoding becomes extremely slow at 99% (when too many minutes passed I'm forced to interrupt the encoding):

https://www.dropbox.com/s/9etleu6e6rp380f/2772.mp4?dl=0

------------------------------------------------------------------------------------------------------------------------------

The script is not touched and loaded the same: it change only the version of avisynth+.

From some proof I have noticed that the "guilty" is LWLibavAudioSource

------------------------------------------------------------------------------------------------------------------------------

Independently from this issues I wonder: using LSMASH R929 64bit and FFMS2 2.23 64bit how I need to change the script to use the correct settings to use multi threading?

in the case of ffms2 it's correct to keep:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)

...


Prefetch(4)

but for LSmashSource?

and what happens if this parameters are wrong?

they are depending from processor used or changing machine does not matter?

[poisondeathray]

but using Avisynth+ R2272 occour the encoding becomes extremely slow at 99% (when too many minutes passed I'm forced to interrupt the encoding):

not for me with your lsmash version in post#48

double check with avsmeter64 to see if it's not an encoder problem

Independently from this issues I wonder: using LSMASH R929 64bit and FFMS2 2.23 64bit how I need to change the script to use the correct settings to use multi threading?

in the case of ffms2 it's correct to keep:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)

...


Prefetch(4)

but for LSmashSource?

and what happens if this parameters are wrong?

See the link jagabo posted above for the MT modes.

they are depending from processor used or changing machine does not matter?

So something else with the way you have your system(s) organized. I cannot reproduce the issue



But there can be issues with colormatrix . It's not safe even with MT_NICE_FILTER for some people . But you shouldn't get a slowdown at the end; there will be corrupted frames. But you should set the proper MT mode for it

Also the quality is lower. It's more visible when upscaling, than downscaling . In your case, there is color bleeding , chroma shifting compared to other methods

[marcorocchini]

I get the slowdown problem at the end of encoding using both LSmashSource of post #48 and R929 with avisynth+ R2272, and never using avisynth+ R1576: the issue seems (strangely) depending by the use of "LWLibavAudioSource": if I use FFAudioSource the problem does not occour in all cases.

Exactly I cannot understand why you cannot reproduce the same situation: maybe there is a dependency with others .dll that is not very clear. I try other proof.

However when you say: "Also the quality is lower" are you referring to the use of avisynth MT?

"there can be issues with colormatrix" also in this case for avisynth MT? But if so a script becomes a minefield



[Attachment 48652 - Click to enlarge]

[jagabo]

But there can be issues with colormatrix . It's not safe even with MT_NICE_FILTER for some people.

If you can't get ColorMatrix() working right you can always convert to RGB then back to YUV with the appropriate matrices. It's slower, less accurate, and blurs colors more, but it works.

[poisondeathray]

However when you say: "Also the quality is lower" are you referring to the use of avisynth MT?

"there can be issues with colormatrix" also in this case for avisynth MT? But if so a script becomes a minefield

A) No, colomatrix with MT

A1) causes corrupt frames
A2) seek issues with temporal filters (mixed up frames even with MT_NICE_FILTER)


B) And the quality is lower in ST or MT

B1) texture issues / noise on some sources
B2) color bleeding /shifting on some source - very visible in your case because you're upscaling

But there can be issues with colormatrix . It's not safe even with MT_NICE_FILTER for some people.

If you can't get ColorMatrix() working right you can always convert to RGB then back to YUV with the appropriate matrices. It's slower, less accurate, and blurs colors more, but it works.

Or just don't use it. Use dither tools, or avs shader, or zimg (avsresize in avs+ )



But colormatrix is a separate issue from the encode hanging/slowdown he's describing at 99%

[marcorocchini]

I don't have well understand:

the quality issues is pending on avisynth MT? is MT more problematic of ST or viceversa?

the colormatrix issue affect MT?

because I try to understand if is possible to "automatize" in batch some sources using MT but, if I have well understand, there are a lot variable that affect the realiability of encoding, and a good quality can be get only with manual settings to be made each time on the individual case, or not?

[poisondeathray]

It depends on many factors. For the most part MT is fine . But if you use some filters that are not MT safe, it can cause mixups. There are always "gotcha" scenarios where something fails

Your lsmash version isn't very robust. seeking isn't accurate . If you scrub the timeline (no other filters, just lsmash) , frames are mixed up. Even if you specify threads =1 . So in theory using a temporal filter might have problems with that lsmash version

Other quality issues specific to colormatrix eitherway , MT or ST. It's not as visible when downsizing. More visible when upsizing . Visible in your example as color bleeding/shifting .

Also, if you decide to use colormatrix, you should always use clamp=0 . Otherwise you get disproportionate channel clamping and discolored highlights. (e.g bright white, might become discolored blue or yellow)

[marcorocchini]

https://www.dropbox.com/s/mwt8ke76msera7e/ColorMatrix.dll?dl=0

please poison can you try the same "critical" script that in my machine have the 99% end-encoding problem to try if with this colormatrix.dll can you reproduce the problem? thanks

[poisondeathray]

https://www.dropbox.com/s/mwt8ke76msera7e/ColorMatrix.dll?dl=0

please poison can you try the same "critical" script that in my machine have the 99% end-encoding problem to try if with this colormatrix.dll can you reproduce the problem? thanks

binary compare is the same as the one I'm using. I think there is only 1 x64 version available