Disabling pre-rendering on Placebo settings runs the risk of out-of-memory issues and crashes. Really there's no good reason for memory issues on SD material, but unfortunately another problem with AviSynth is that it's caching algorithm is not smart enough. Caches too much, runs out of memory, crashes. Very much affects multi-threaded ripping.
Best solution would be to rewrite AviSynth's caching (and threading) code. No-one wants that job.
Second best solution is to make a 64-bit MeguIVit. It's on my to do list.
Edit1 @Astrayred: I'll up the threading hack-fix code & dlls on D9, but I don't think it will kickstart any development work. The authors already know that Avisynth needs to be re-architected, and have had some discussions about it. They failed to agree and didn't appear eager to do the work in any case.
Edit2 @Astrayred:
Using progressive mode on interlaced material will give you near duplicate frames - something much like 30fps. Is that your intent?
@IceManz: I meant that I get random crashes very rarely to none at all. I'm using 64-bit Avisynth if that helps. Yup, I'm not using MeguVit, but vanilla MeGUI.
@Vitreous, nope I meant that I'm using progressive mode on progressive material. Those DVDISOs were flagged as interlaced in DGIndex but are actually progressive. I verified this via 3 methods:
1) Using QTGMC non-progressive. That is, it outputs 59.94 fps. The motion is different, it's jerky and not smooth at all.
2) Load the video into DGIndex and scan for those interlace lines.
3) Use MeGUI's source detector. It's usually pretty accurate.
A few studios are guilty of these shenanigans. For Gravure, it's usually the studio using product code prefix ENTO. I was going through my collection and to my horror found that all my ENTO DVDs are encoded that way, fake interlaced.
If I had interlaced material I will just use standard processing, so I don't really understand what you are saying. uzzled: