AVI import filter very slow for >2Gb corrupted file

[JasonFly]

I have a problem with a corrupted AVI file created by VirtualDubMod 1.5.4.1. The job was almost finished when Vdub crashed(I don't know the reason about this but that's not the main problem because I think my system was behind this, PC was on for a long time, and I have used many programs during the encodiong process)
I suspect the encoding job to be almost finished since my file was a bit larger that the requeted one, and maybe Vdub crashed druing the creation of the avi index.

It was a long job(more than 24hrs of encoding for the 2nd pass of an XviD encode) and requested filesize was 4 120 000 kb. The file after the crash is 4 145 152 kb. I would like to avoid restart this job. So, I tried to open the corrupted file with VdubMod and the beginning was fine. But from 2 077 719 kb, the import process began to be extremely slow(so slow that this would be much slower than restarting the job). I suppose that this is a 2 Gb limitation of the AVI import filter, but I would like to have the professionals' opinion.

I also tried to restore the file using divfix but it seems that it has the same limitation(I saw a >2Gb support in the TODO list)

I must precise that I have already opened some >4Gb files and there weren't any problem but these were not corrupted.

[lamapoo]

Try unsing avisynth. Create a script that loading the video and drag and drop it into vdub. Save in direct streamcopy. That should take care of it if the filesize is the problem.

[stephanV]

but that would save it as uncompressed everything...

whats the problem with starting a new encode (which is preferable)? leave your computer on for the night and it should be finished when you wake up no?

i personally would rather do a new encode then trying to salvage a broken file...

[JasonFly]

Thanks for reply but I don't think this will work(in fact, i'm sure that this won't work). Avisynth gives the clip to VirtualDub as if it was an uncompressed YV12/YUY2/RGB clip. If I do what you said, i'll get an uncompressed YV12 avi file and not my 4 GB XviD encode.
Anyway, avisynth didn't managed to open the file using the avisource() command.
Considering the lack of sucess of my post I have restarted the job this morning.I hope I wouln't get any memory error this time.

[JasonFly]

It seems that 'm cursed...

The job aborted at exactly the same frame. That seems more related with XviD than with VduB but I'm not sure.The error was a dialog saying "Microsoft VC++ runtime error in VirtualDubMod.exe". This wasn't the same message than the first one wihch was due to a memory leak(I don't remember precisely).

But I've just noticed that my .avs source file is 844 221 frames long and my XviD .pass file is 844219 frames long. The thing is that Vdub didn't crash. I was before my screen when the problem occured and Vdub/XviD seemed to have problems to encode frmae 844 220. Vdub seemed to be waiting a frame or something. So I just clicked on the abort button to finish this endless thing.

I don't know why my .pass file had less frames than my source. If you guys have any idea, you're welcome.

[lamapoo]

Avisynth gives the clip to VirtualDub as if it was an uncompressed YV12/YUY2/RGB clip. If I do what you said, i'll get an uncompressed YV12 avi file and not my 4 GB XviD encode.

ok..

#fetch the videoclip with directshowsource not avisource.

directshowsource("path and avi file")

#You can convert it to whatever colorspace you want.
#yuy2, rgb24, yv12..

converttorgb24

Now drag and drop your file into virtual dub and save using full processing with the xvid settings you used or even better, save as uncompressed avi and use this video file to create your xvix encode. You shouldn't encounter the same problem.