AviSynth 2.5.7 Alpha2 [April 2nd]- DIAG Release!

[IanB]

Special diagnostic build!

AviSynth 2.5.7 Alpha2 (April 2nd):

Warnings
* This installer does not abort on registry error, to aid in debugging
* the current XPsp2 problem with the installer. i.e. it just stumbles
* on after the mesagebox, possibly leaving an invalid install. This will
* be restored after the problem is corrected.
*
* This version has had the automatic output ConvertAudioTo16Bit disabled
* to ease the testing of input of WAVE_FORMAT_IEEE_FLOAT type steams.
* Audio Sample type float will be output as WAVE_FORMAT_IEEE_FLOAT to
* the host application. None of the popular application can currently
* handle this stream type. Add a ConvertAudioTo16Bit() to the end of
* your script. This will be restored for the next release.

Additions
* Explicitly request all the channels available in the audio stream [acm AC3]
* Explicitly try to request float, 32 bit then 24 bit samples from the audio codec.
* Accept raw audio streams of type WAVE_FORMAT_IEEE_FLOAT.
* Added avs_delete_script_environment and avs_subframe_planar to avisynth_c interface.
* Hack to allow Fraunhoffer MP3 codec to work when wBitPerSample==16. (Squid_80)
* Added portugese translation (by RoLon), and partly french translation (by JasonFly)
* Subtitle multi line text, set LSP arg and use \n. (foxyshadis, tateu)
* xxxFPS("preset") string preset FPS values. (Tritical)
* Better avisynth_c cdecl/stdcall mismatch detection and protection (Tritical).

Bugfixes
* Fixed ConvertAudio SSE2 to Float alignment test.
* Fixed (auto)LoadPlugin altname generation. (Tritical)
* Fixed SaveString memory block overrun.
* Fixed $Plugin!Functionname!Param$ bug. (Fizick)
* Fixed registry handle leak on $PluginDir$ lookup. (Dave Brueck)
* Fixed memory leaks avisynth_c.
* Fixed returning locked/protected VBF's to LRU. (Tritical)
* Fixed runtime mixed SEH/C++ exception handling for XPsp2. (Tritical)
* Fixed CAVIStreamSynth::Read audio buffer overrun. (Avery Lee)
* Fixed DLL handle leak in LoadPlugin. (Tritical)
* Fixed Assert("text") no longer parses % args.
* Fixed number parser returning inaccurate float conversions.
* Fixed ConvertFPS() blend mode not processing of chroma planes.
* Fixed resizer resampling pattern attempted use after deletion.
* Fixed resizer subpixel shifting functionality being a noop.
* Fixed Info() auto font selection metric.
* Fixed Conditional error checking of float RHS.
* Corrected colours in YUV ColorBars, Now match BT.801-1.
* TCPDeliver updates: Client: Fixed crash if client gets disconnected.
* TCPDeliver updates: Server: Remember to disconnect clients when shutdown.
* Fixed Turn*() YUY2 mod 2 height test.
* Fixed AVISource() corrupted error messages.
* Fixed AVISource() direct input drop frame handling.

Optimizations
* None.

Changes
* SetMemoryMax() minimum now 4Mb instead of 16. (Tritical)
* Remove 50 plugin auto load limit. (Tritical)
* COM QueryInterface calls now return S_OK instead of NULL.
* Bracketless call of argless function now get a cache. (Tritical)
* Over-range numbers now raise a compile time exception.
* xxxFPS(float) now uses continued fraction to generate a minimal rational pair. (Raymod2)
* ChangeFPS(linear) now raises a compile time exception if the change ratio is > 10.
* ConvertFPS() blend mode works for all pixel formats. (Tritical)
* Info() retrofit of 2.60 updates.
* TCPDeliver.dll upx'ed.
* RGB ColorBars +Q and -I bars, Hue is now correct, Luma is NOT zero to achive this.
* AVISource Audio no longer limited to 2 channels.
* SaveString memory blocks are now 32 bit aligned.
* Default planar chroma planes mod 16 aligned. See SetPlanarLegacyAlignment().

As usual download from Sourceforge (http://prdownloads.sourceforge.net/avisynth2/AviSynth_260402.exe?download).

Seeing the CVS server is down here is a source tarball of the modified source src_060402.tgz (http://avisynth2.sourceforge.net/src_060402.tgz) to keep the GPL happy.

[IanB]

A Note about the XPsp2 installer problem

I have slightly reorganized this installer and broken the problem registry part into 3 sections, each with it's own error handler. I have removed the "abort" calls so the installer will just bumble thru all 3 sections. I have also enabled the installer progress window so we can see what is going on when an error occurs.

Hopefully when an error occurs there will be enough information for someone to make a meaningfull report about this problem so I can fix it.

Note :-

A succesfull install has no error message dialog boxes popup.

A broken install will have error message dialog boxes popup, but the installation will stumble on after you click Ok. Please report the exact text of the Dialog box, with a copy of the status window.

[shpitz]

i just installed it on xp pro sp2, worked flawlessly.
thanks much for all your hard work and great product!

[IanB]

Ahhhg! Well it's good that it works, but apart from shuffling things into a more logical order and adding diagnostic hook, it should be the same as the Alpha 1 apart from telling me why it was failing. I hope the diag hooks aren't making it work.

Does it :-

A) Install cleanly on a virgin setup?
B) Install cleanly over an existing install of 2.5.5/2.5.6?
C) Install cleanly after an uninstall of 2.5.5/2.5.6?
D) Reinstall cleanly over an existing install of 2.5.7?
E) Reinstall cleanly after an uninstall of 2.5.7?

[mgh]

Uninstalled 2.5.6-asking pointer to plugin directory to be left untouched-install halted in the middle
http://img93.imageshack.us/img93/8469/image20wq.jpg
clicked OK and install completed.
Seems to be working OK:)

[squid_80]

Thanks for the tarball, I've been trying to update my copy of HEAD for the past four days (frickin' sourceforge). Now to have a looky at this 2gb wav problem...

[IanB]

@mgh,

Thank you, mark 1 up for the good guys. :D

Firstly, any chance you could repeat the exercise, but this time move the top dialog box out of the way so I can read the status window beneath before you snatch your screen grab.

Secondly, can you please delete the file colors_rgb.avsi from your pluggin directory. Was it flagged READONLY?. Does the install now run cleanly? Belgium! I could really scream sometimes. grrrr!

@Squid,

The rot starts in bool AudioStreamSource::Seek(long samples) in sources\avi\VD_Audio.cpp and spreads like a cancer from there.

I have been meaning to reimport all this vdub code for some time. Avery has made many fixes and changes. It's all about finding the time.

[squid_80]

Apparently virtualdub still can't read beyond 2gb but it is being worked on. (http://forums.virtualdub.org/index.php?act=ST&f=4&t=12017) I remember looking at the WAVE64 specs a while back too, it's more or less odml for wav files.

[shpitz]

honestly i don't know why you even bother with audio...
avisynth should be the king of video, not audio...

i would rather see optimizations for dual processing and multithreading along with sse2/sse3.
i would also like to see optimization and porting of avisynth to x64, i think we could benefit a lot from that.

just my personal wishes ;-)

[mgh]

Uninstalled the alpha-leaving pointer to plugin directory untouched as before-reinstalled-installation completed without a hitch :D

[IanB]

@mgh

To fix this I really need to see the contents of the status window that is hidden by the dialog box in your screen grab.

Sigh! :(

Hopefully somebody else with a still failing install can oblige.

[bagheera1]

I had a similar problem as mgh, it was a lot of files marked read only including C:\WINNT\system32\avisynth.dll. after removing the readonly attrib and restarting the installer, all went smoothly.

[squid_80]

IanB: I think I fell down the rabbit hole a bit too far...
What I found was this call in AVIReadTunnelStream::Read (AVIReadHandler.cpp):

hr = AVIStreamRead(pas, (LONG)lStart, lSamples, lpBuffer, cbBuffer, plBytes, plSamples);
which seems to be an avifile API call, and returns squat (no bytes or discernible error code) once the 2GB boundary is crossed. Not sure where to go from here, but I might see if I can somehow use AudioSourceWAV for wavsource instead of AudioSourceAVI.

[IanB]

And this is at the bottom end of the food chain. There is also a similar problem at the top.

CAVIStreamSynth::Read() in main.cpp is an implementation of AVIStreamRead() so 2 Gbytes of audio is a pretty severe wall on all sides.

[AVIL]

Hi,

After installing avisynth 2.5.7. a1, when I've try to encode with HC 0.17 preview image was scrambled. And, what is worst, encoded video too. After restore avisynt.dll to release 18.11.2005 the problem was solved.

BTW with avisynth 2.5.7 a2 I had the problem too.

AMD Athlon 64, Windows XP Pro, 1Gb RAM

[Mr_Odwin]

Hi,

After installing avisynth 2.5.7. a1, when I've try to encode with HC 0.17 preview image was scrambled. And, what is worst, encoded video too.

I had this exact problem today too. I tried HC 0.16 and the problem remained.

[Mug Funky]

you can (probably) work around this by adding a "turnleft().turnright()" to the end of your script. speed will suffer a little, but barely. think it's a data alignment thing. ffdshow (vfw) sourced video also used to do this.

[IanB]

Dejevu!* Default planar chroma planes mod 16 aligned. See SetPlanarLegacyAlignment().

[squid_80]

CAVIStreamSynth::Read() in main.cpp is an implementation of AVIStreamRead() so 2 Gbytes of audio is a pretty severe wall on all sides.
If I'm understanding correctly what you mean, that problem's not so bad; all virtualdub's ::Read (and ::_Read) functions were changed to use 64 bit values for samples, so updating them is easy enough. The sample number (lStart) isn't the problem anyway, since it's multiplied by bytesPerSample (plus an offset) to get the position in the file. I tried using AudioSourceWav, but it uses mmio routines which are limited just like avifile (probably the same code). It *might* be possible to use mmioDescend to get the offset to the data chunk of the .wav file, then switch to good old direct I/O (which should include _fseeki64 under windows) if the file's big.

[AVIL]

@IanB

I've put SetPlanarLegacyAlignment() as the last function in my script and all is OK now wit HC 0.17

Thanks

[IanB]

@AVIL, (and others),

Plugins and applications requiring SetPlanarLegacyAlignment are broken and need to be fixed before 2.6 hits the streets. Please report such issues to the authors of the software.

Code that needs the Pitch of a video plane must not assume any alignment or relationship, alway use the GetPitch() method.

@Squid,

Yes the internal code for all this seems 2 GB limited everywhere, you're probably right on the money about it being a cut and paste of the same dumb code everywhere.

The quick debug I did shows the code is probably using long everywhere instead of ulong or __int64long lFilePos = lStart * lBytesPerSample + lOffset

Probably should reimport the vdub code before we get carried away putting __int64 everywhere. Perhaps a RIFF aware raw audio file reader could be usefull.

[squid_80]

I've already imported most of the vdub code, for the most part it is equivalent to putting __int64 in all the right places; it just calls it VDPosition or sint64 instead of __int64 (via typedef). Still uses mmio or AVIFile routines, so it is limited like Avery said. I was thinking it might be possible to write a custom I/O procedure to plug in to mmioInstallIOProc, and use mmioSendMessage instead of mmioSeek when the offset is larger than 0x7FFFFFFF.

What I don't understand is why mmio and avifile will quite happily read over the 2gb boundary, but hurk if you seek past it then attempt to read. I even tried setting lDiskOffset manually using mmioGetInfo/SetInfo, but no dice.

[IanB]

What I don't understand is why mmio and avifile will quite happily read over the 2gb boundary, but hurk if you seek past it then attempt to read.There are no special read calls for huge files. All the kernel calls like ReadFile, _lread, _hread just read the next sequential data so they just don't know or care when you cross a 2gb boundary.

However doing a seek on huge files is a pain. All the old calls like _lseek have signed 32 bit args so they "hurk" as you say. Interestingly relative mode seeking seems to work, so I guess the mm/av code must all use absolute mode seeking. Even the modern call SetFilePointer is a pain to drive for huge files access. So a lot of slack code just ignores the high order 32 bit pointer arg and so you are stuck in a 2 gb world still. The avi code is certainly old enough to be using _lseek or a slack implementation of SetFilePointer. And M$ want to disown AVI and do everything in their nasty proprietory ASF format, so I guess they see 2gb as a lever.


If you are serious about doing a reimport of the VDub code please check it into the avisynth_2_6 CVS branch. If it is low fuss enough we can retrofit it to the 2.5.7 base. From what you are saying and from what I am seeing breaking the 2gb barrier is well out of scope for a bug fix release, it's going to be a major step with lots of testing and bugs.

[foxyshadis]

I was going to ask for a way to cache function calls without their internals (sort of a heigharchial cache or something, where different entries have different merits), but now I kind of suspect you're already doing it? I have a script that uses about 70 megs of cache per frame, and it tops out after 10 frames, but the final frame is still in cache and accessible to temporal filters for at least 40 frames! Is this just random chance, or is the cache really that smart?

[IanB]

Yes, this is the intended behaviour.

All cache instances remember there accessed frame numbers. When you start re-hitting pre-loved frame numbers, that particular cache instance starts asking the memory manager to "promote" any vfb's it receives to the front of the LRU chain.

So in your case as the top cache instance is being asked for pre-loved frames it starts promoting it's vfb's. During the first 10 frames (while the LRU is filling) it will be certainly satisfying any requests from cache, thus lower cache instances never see any re-hits. After the cache has filled, the top instance has a head start, and continued success means it will be the only cache instance being asked for pre-loved frames.

[IanB]

Anybody got any installation problems to report?

No forensics, no diagnosis, no resolution!

[ricardo.santos]

altough i get the following error, after i press OK the instalation goes on.

will test it tomorrow and let you know of any problems(if any)

http://img73.imageshack.us/img73/6674/avisynth5mq.jpg (http://imageshack.us)

[IanB]

@ricardo.santos,

Thank you very much, just the data I needed to see, and you repositioned the dialogs to show everything. You are a champ! We need more tester like you :D

It seems the files in your plugin directory are protected somehow (possible Readonly?), so for this install the DirectShowSource.dll, TCPDeliver.dll and colors_rgb.avsi files will not have been updated. Please check the attributes and permissions on these 3 files and report what the status is.

It seems the "if errors ...." statement in the script regards "skipped:" files as an error. DAMN! :devil:

In the Alpha 3 release I changed the install mode from forced to ask, looks like this is going to have some positive benefits in helping with this problem.

Before you fix the attribute/permisions of the 3 plugin files can you download and install the 2.5.7 Alpha 3. It should display the installers conditional file install question. Clicking Yes should force overwrite the problem file if they are simply marked Readonly. Other restrictions will need to be manually corrected, and clicking yes after fixing should give a succesful install.

Your help in resolving this matter is very greatly appreciated.
:D IanB, Avisynth Team

[Adub]

Uh, hi all. I don't know if this is the right thread but I am having trouble with RemoveGrain, RemoveDirt, and RemoveNoiseMC right now.

I get this error message:
CAVIStreamSynth: System Exception - 0xc000001e

Would updating to Alpha 3 help? I am using Alpha 2.

[IanB]

0xC000001E: "An attempt was made to execute an invalid lock sequence"

What Processor are you running?

Typically trying to execute a LOCK MOV ...., etc, sequence on some processors will cause this error. Question is where is it coming from. The compile shouldn't generate this code, I certainly know not to try it ( I hope others do as well). Posssibly it is executing data or spewed upon code and accidently coming across this sequence. (Run some memory diags!)

2.5.7 Alpha 3 should not change this, unless the subtly different code order effects such an insideous bug. An older version without the XPsp2 MSVCRT.DLL workaround code may give better diagnostic information.

[ricardo.santos]

Hi IanB

I completely forgot to get back to you with the reslts of installing the Apha release 3.

when installing it everything went ok, no pop up messages etc.

Thanks

Ricardo

[Adub]

I am running an intel p4 2.4 ghz processor, I can't run memtest yet as I don't have access to the compter but as soon as I can I will tell you if anything comes up.

Would you suggest I go back to 2.56? I don't have a huge need for 2.57 and 2.56 is stable.

[Adub]

Okay I ran memtest 86 today. No errors.

If I change back to 2.56 will it help? I just want to be able to use all of my Avisynth functions and plugins to their full capacity again.

[IanB]

If I change back to 2.56 will it help?It might. Certainly you should test with 2.5.6 and report the result. If the problem still occurs 2.5.6 should at least give the address of the failing instruction. If not then we have a 2.5.7 problem to track down. Exception ...1E's should never happen and most likely is the result of trying to execute crap from a memory scribble or stack corruption.

Also :script:

[Adub]

Okay, the error does not show up with RemoveGrain any more for some reason but it does show up with RemoveNoiseMC.

Here is my script. very basic test.

DgDecode_mpeg2source("C:\Documents and Settings\Merlin\Desktop\Movies\USA Parkour\usa.parkour[1].d2v")
RemoveNoiseMC()

I will test if it works with 2.56

[Adub]

It works!!!
With version 2.56 it works!!! yey!

Although this means a possible bug. Not good.

[IanB]

Okay this may be a plane alignment/pitch thing. Please try these 2 scripts with 2.5.7 and 2.5.6 respectivly.DgDecode_mpeg2source("C:\Documents and Settings\Merlin\Desktop\Movies\USA Parkour\usa.parkour[1].d2v")
RemoveNoiseMC()
SetPlanarLegacyAlignment(True) # For 2.5.7 to work?

DgDecode_mpeg2source("C:\Documents and Settings\Merlin\Desktop\Movies\USA Parkour\usa.parkour[1].d2v")
RemoveNoiseMC()
SetPlanarLegacyAlignment(False) # For 2.5.6 to fail?

[Adub]

Nope. 2.57 fails with both scripts and 2.56 works with both scripts.
Sorry dude.

[IanB]

Okay it's not an alignment/ pitch thing.

First try this, i.e. with BlankClip() substitution...DgDecode_mpeg2source("C:\Documents and Settings\Merlin\Desktop\Movies\USA Parkour\usa.parkour[1].d2v")
BlankClip(Last)
RemoveNoiseMC()Next transcribe a smallish chunk of your mpeg into Huffyuv, DivX or something .AVI file, and try this...AviSource("C:\Documents and Settings\Merlin\Desktop\Movies\USA Parkour\usa.parkour[1].AVI")
RemoveNoiseMC()Also are you currently testing againsts 2.5.7 Alpha 2 and/or Alpha 3?

[Adub]

Well I am using alpha 2 only, not alpha 3, and I just tested the first script/ blank clip function and it didn't work. I am now transcoding the video to avi really quick.

Okay done. Ran the Avisource script and it too shows the error.

[IanB]

@Merlin7777,

If you want me to fix this issue, you are going to have to be a little more precise in your answers.

... and it didn't work and it too shows the error are a little ambiguous. If they all cause the original 0xC000001E error please state this. Every little detail can be significant, like one case crashing on frame 3 and another on frame 5.

Also what OS and service pack are you running on your intel p4 2.4 ghz processor. And is it a Celeron, an M, a HT or a regular.

And please test with the Alpha 3 version as well.

[Adub]

My apologies.
Yes, Both scripts caused the original 0xC000001E error.

I don't think that any frames were loaded, but I cannot be sure as I will not have access to the computer until friday. Then I will also test Alpha 3.

The processor is a regular pentium 4 running at 2.4ghz. No HyperThreading, not a celeron, or a pentium M.

I am running Windows XP, Service Pack 2. So far I believe I have all of the updates put out by microsoft.

This computer is a normal, run of the mill, compact 4600c Dell computer.

[IanB]

Okay to avoid any further confusion I have stripped RemoveNoiseMC() down to a single script with a blank clip source. Please test this to ensure it behaves exactly the same as Your version of the RemoveNoiseMC() scripts.clip = BlankClip(10000, 720, 480, fps=29.97, pixel_type="YV12").KillAudio() # Adjust to match your clip!

bvec2 = clip.MVAnalyse(isb=false, blksize=8, delta=2, pel=2, truemotion=true, pnew=66, idx=1)
bvec1 = clip.MVAnalyse(isb=false, blksize=8, delta=1, pel=2, truemotion=true, pnew=66, idx=1)
fvec1 = clip.MVAnalyse(isb=true, blksize=8, delta=1, pel=2, truemotion=true, pnew=66, idx=1)
fvec2 = clip.MVAnalyse(isb=true, blksize=8, delta=2, pel=2, truemotion=true, pnew=66, idx=1)
backw1 = clip.MVFlow(bvec1)
forw1 = clip.MVFlow(fvec1)
clp = interleave(backw1,clip,forw1)
clp = clp.RemoveDirt(11,2,false)
clp = clp.SelectEvery(3,1)
dnc = clp.MVDenoise(bvec2, bvec1, fvec1, fvec2, thT=8, thSAD=190+15*8, thmv=40, thSCD1=230+5*8)
vid_mo = dnc.VagueDenoiser(threshold=1.4, chromaT=1.4, nsteps=6, percent=75)
vid_mo = vid_mo.RemoveGrain(5)
dnc = dnc.ConditionalFilter(dnc, vid_mo, \
"(YDifferenceFromPrevious()+YDifferenceToNext())/AverageLuma()", "<", "0.3")
clp = clp.SeeSaw(dnc, Sstr=0.28, Szp=12, SdampHi=20, bias=40)
return clpThe next stage will be to cull this script to find the statement that is failing. i.e. Take line X out, it works, put it back, it dies.

[Adub]

Okay, I tried the script above and it still gives the original ...0001e error, as have the other ones. I will download alpha 3 and test with it.

Also, It doesn't stop playing on a certain frame. The script still continues running for the length of the clip. I am guessing this is standard though.

Here is my script. Should be almost the same as yours except for the source.
clip=DgDecode_mpeg2source("C:\Documents and Settings\Merlin\Desktop\Movies\USA Parkour\usa.parkour[1].d2v").KillAudio()

bvec2 = clip.MVAnalyse(isb=false, blksize=8, delta=2, pel=2, truemotion=true, pnew=66, idx=1)
bvec1 = clip.MVAnalyse(isb=false, blksize=8, delta=1, pel=2, truemotion=true, pnew=66, idx=1)
fvec1 = clip.MVAnalyse(isb=true, blksize=8, delta=1, pel=2, truemotion=true, pnew=66, idx=1)
fvec2 = clip.MVAnalyse(isb=true, blksize=8, delta=2, pel=2, truemotion=true, pnew=66, idx=1)
backw1 = clip.MVFlow(bvec1)
forw1 = clip.MVFlow(fvec1)
clp = interleave(backw1,clip,forw1)
clp = clp.RemoveDirt(11,2,false)
clp = clp.SelectEvery(3,1)
dnc = clp.MVDenoise(bvec2, bvec1, fvec1, fvec2, thT=8, thSAD=190+15*8, thmv=40, thSCD1=230+5*8)
vid_mo = dnc.VagueDenoiser(threshold=1.4, chromaT=1.4, nsteps=6, percent=75)
vid_mo = vid_mo.RemoveGrain(5)
dnc = dnc.ConditionalFilter(dnc, vid_mo, \
"(YDifferenceFromPrevious()+YDifferenceToNext())/AverageLuma()", "<", "0.3")
clp = clp.SeeSaw(dnc, Sstr=0.28, Szp=12, SdampHi=20, bias=40)
return clp

I also tried it with your exact script, the BlankClip source, and it showed the 0xc000001e error as well.

[Adub]

Okay, Alpha 3 testing gave the same 0xc000001e error as Alpha 2. Frames kept running, 1ms of jitter, no buffer to speak of.

In case I forgot to mention earlier I am testing with Media Player Classic if it helps at all.

[Adub]

I found the problem!!!

I had several different versions of Repair, Remove Dirt, RemoveGrain in my plugins folder. s, sse, sse2 etc. My guess is that the script found the functions in all of those versions at the same time, thus causing the lock up. I have deleted all of the versions except the sse2 versions, as those work the best for my processor.

It now works without a hitch. Thanks for your help IanB.

[IanB]

Hmmmm, I am glad you got this working, but having multiple versions of plugins should at worst cause confusion never ever a crash. You have stumbled across a very obscure problem with 2.5.7 and it does need to be fixed.

In order for me to reproduce your problem can you, if possible, reinstate your plugin directory to cause the crashing with 2.5.7 versions again, then paste a list of the contents, anote versions if possible.

It would be helpful if you can do some first level reduction by moving out pluggins that don't effect the result. Best would be if you could get down to just a few pluggins and be able to say including this one causes the crash, removing it make things work.

[foxyshadis]

I know for sure that mpeg2dec3 doesn't play nice with cvs, but whether it crashes or just doesn't load I don't remember anymore. I'm pretty sure it caused an access violation though. (At the time I just said who cares, it's just ancient mpeg2dec3, but one of my partners decided to base his YATTA project off it.) If I can find it again I'll tell you what it does.

[Adub]

Okay, I narrowed it down to the RemoveGrainSSE3.dll that was causing the crash in RemoveNoiseMC. I removed all of the RemoveGrain dlls one by one, except the SSE2 dll because I knew that it was not the one causing the crash.

I think because I do not have a proccessor that supports SSE3, the removeGrain optomized for it caused the lock up.

I got this error as well with SeeSaw as well in my testing, let my try and figure out which dll that was.

Edit: Okay, for the SeeSaw error it was the RepairSSE3.dll that was causing the problem.

These dlls should be the latest versions. I downloaded them directly off of the authors site I believe.

[IanB]

Slowly we are getting there. :) I assume you downloaded this http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar

Unfortunatly the matching source http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain-src.zip seems to be of zero length. Can anybody point me to a link for the source with some content.

[foxyshadis]

What you have to do is get the source from the old site, http://www.removegrain.de.tf/ and then copy RemoveGrain.cpp from the new rar over it. Thankfully the important source is included.

[Adub]

Yeah, I did use that version of removeGrain. the august 1st version.

[foxyshadis]

Well, I guess I found one of the culprits: I reinstalled SUPER today, and ended up with an avisynth.dll overwriting my cvs version, with read-only, hidden, and system attributes set, as well as the registry entry pointing to its install reset to the default location. I wonder if any other software installers play fast and loose with recorded playbacks like this.

[Wilbert]

What's SUPER?

[foxyshadis]

A free any-to-any video converter, rather better designed than many commercial packages/rip-offs.
http://www.erightsoft.net/SUPER.html

[Adub]

You know, I used to have super installed, but i got rid of it as it was just taking up harddrive space and I didn't really need it. So did you end up getting an error message at all, or was it just business as usual?