well, dsgamer submitted not only an improvement on his any percent run of prime hunters, but a new 100% run, as well. on top of that, greenalink did a run of mario 64 ds. when all three runs were accepted by verifiers, i knew it was "time to get serious" (as mega man would say) about processing ds footage.

perl has become my new best friend, and i knew it had integration with imagemagick, gd, etc. a few google searches later, i had decided on using imagemagick ("perlmagick"), since it came with a well-tested autocrop function.

originally i was going to try to determine the z-distortion (i don't know the proper term) of the ds screen(s) and correct for that (basically if the top of the screen is further away from the camera than the bottom), but the only implementation i found of that functionality i couldn't get working with any of my test footage (it never changed anything), so i decided to put that off until next time. i felt like i had enough on my plate with making sure the autocrop threshold was correct all the time.

basically, i set a default threshold and try to autocrop the current frame. if the autocrop succeeds, then i note how much was cropped and move on to the next frame. if it doesn't succeed, then i gradually turn up the threshold until it does succeed. if it never succeeds, i don't save the crop data. if it succeeds but it's cropped off way too much as determined by a sanity check, then i don't save the crop data.

i do this for a certain number of frames (i ended up using two seconds' worth for dsgamer's runs), then go back and crop all of those frames by the means of the values i saved for each side. this is much improved from how i was doing it before using avisynth, which could only look at a single frame to determine values. i also don't think i could get the values that the avisynth plugin was using very easily due to how simple the avisynth language is, but i could be wrong on that.

in other words, the old method was very high maintence - i had to go five seconds at a time and manually adjust the threshold. a lot of times bloom from the screen (if the screen was very bright and you could see the ds's body glowing in the dark, for example) would throw off the threshold. i got around that this time by starting with a rather high threshold and then throwing out crop data that deviated too much from an arbitrary norm. (by "deviated too much" i am talking about how if the screen was very dark the high starting threshold would sometimes cause it to crop off too much, for example the area outside the hud in human form.)

a new feature for next time might be to determine the norm on the fly. i guess that would be means for the whole segment. actually i thought i was going to have to do that this time, but dsgamer's runs came out perfect on the first try. it was a good thing, too, because it took the better part of a week for one of the computers in the lab where i work to process them (i think most of it was i/o though since i had to read twice and write once a .png file for every single frame in the runs). i'd also like to learn how to read and write yv12 and do everything through mplayer/mencoder pipes next time for a big speedup. normally i wouldn't care so much about the speed, but i think this may make it into anri someday (even though only two people have ever submitted ds runs to the site), and it's totally unworkable for most people's computers the way it is now.

i did the audio on dsgamer's runs the same way i did it last time - by putting the over-the-air audio on the left channel and the audacity-recorded audio on the right channel, wearing headphones, and adjusting the audacity audio's offset until i couldn't distinguish the right and left channels. (i then cut the over-the-air audio.)

greenalink's run i did totally differently because he recorded it totally differently. he was able to keep his ds much more still than dsgamer was probably because of how the game is controlled differently, so autocrop was not really needed. i just figured out a set of rotation and cropping values for each individual segment and applied those. he also recorded both screens all the time. he and i talked about this quite a bit and we decided that since mplayerc lets you zoom in on one screen in the video, leaving in both screens would be the best option since some people might want to see what's going on on the bottom screen even when he's controlling a character. it also goes along with the site's general ethos, not throwing out potentially valuable data that could be used by someone to improve the run.

greenalink's run didn't need anything done to the audio (except maybe normalization) since he recorded both the video and the audio using a dvd recorder, so it was already synced.

all three runs will be going up on the site soon, and i hope you enjoy them.

here are the tools i made or used to process them this time:
mplayer/mencoder (to dump to pngs/encode video from pngs)
ds.pl (to process the pngs)
avisynth rotate (to rotate greenalink's segments before cropping)

by the way, getting perlmagick to compile under os x was a total pain in the ass. it took me several hours of googling and experimentation. i ended up manually linking the perlmagick sources against the imagemagick libraries delivered by macports.

enjoy.

#!/usr/bin/perl -w
#nathan jahnke 

my $natename = 'rks';
my $thedir = "/p/${natename}";
my %rehash = ( #old, new
	8=>5,
	5=>6,
	6=>7,
	7=>8,
);
my %files;

opendir(P,$thedir);
my @files = readdir(P);
closedir(P);

for (@files) {
	if (-f "${thedir}/${_}") {
		my $newname = &newname;
		system('mv', '-nv', "${thedir}/${_}", "${thedir}/${newname}");
		$files{$newname} = $_;
	}
}

for (keys %files) {
	my $newname;
	if ($files{$_} =~ m/^${natename}-v-(\d+)\.(.+)$/) {
		my $segnum;
		$segnum = $1;
		$segnum = $rehash{$segnum} if $rehash{$segnum};
		$newname = "${natename}-v-${segnum}.${2}";
	} else {
		$newname = "${files{$_}}";
	}
	system('mv', '-nv', "${thedir}/${_}", "${thedir}/${newname}");
}

exit 0;


sub newname {
	my $retvar = '';
	while (-e "${thedir}/".$retvar) { #try until we get a unused name
		$retvar = &random;
	}
	return $retvar;
}

sub random {
	my $retvar = rand(1);
	$retvar =~ s/^0\.//;
	return $retvar;
}

mencoder -dvd-device /p/mm6 dvd://1 -fps 59.94 -vf-add tfields=0 -vf-add scale=320:240 -ofps 59.94 -ovc lavc -lavcopts vcodec=ffvhuff -oac pcm -o nmf.avi

dgindex, because it doesn't drop video frames to compensate for the bad ac3 ones, will cause randomly progressive desync. though i need to remember to use it for timing in cases when the in-game timer isn't used, such as this mm6 run (the release versions of such runs will actually be several seconds shorter than their official times indicate).

after several hours of playing around, my initial guess turned out nearly correct: the "Skipping frame!" messages i was seeing every few hundred frames from mencoder trying to transcode the file were because the audio was bad, not the video. actually, i should have known this from the start - if it had been the video, then the video would have been leading the audio, not vice versa as i initially observed at points. i had also forgotten that the term "frame" also applies to many audio formats. using mencoder's -noskip option together with the -mc 0 option seemed to restore a semblance of audio sync in an nmf - enough to carefully stretch the audio to correct the progressive desync to an acceptable level.

tiki has been advised of the situation. right now we are guessing it was because he used rf (from his nes). pal nes is known to generate a nonstandard signal (enough to cause massive frame droppage with more sensitive capture devices), so maybe the ntsc nes in combination with rf confused his dvd recorder? i'll post again as i learn more.

nas_dstation_settings.png
nas_dstation_tasks.png
nas_network.png
nas_status.png
nas_terminal.png
nas_volume.png
nas_winmac.png

as you can see, i set up the disks in a raid1. this is the new sda project drive ("p"), replacing an old sata 500 gig in v5 (my hp pc). unfortunately the old 500 started locking up a few months ago and after it did it three times last week i decided i had better not wait any longer. i do daily backups of all the in-progress sda stuff but i didn't want to work off of the backup if i could avoid it, which i did. actually even now i'm not sure whether the lockups were caused by the drive, the cable or the controller (on the hp motherboard) but to be honest i don't have the time to be troubleshooting things like that, especially when the lockups are more or less random. also no matter the outcome i would have had to have spent money anyway so i felt this purchase, subsidized 50% with sda funds (even though i have no reason to buy it except sda), was inevitable.

softwarewise:

BusyBox v1.1.0 (2008.06.20-16:34+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

p> uname -a

Linux p 2.6.15 #639 Sat Jun 21 00:30:16 CST 2008 armv5tejl unknown

p> 

i have to say that the built in torrent client (rtorrent with the web gui) isn't bad. the only thing that seems to be missing is down/up rate caps in the web gui (it may be available in the windoze-only standalone app - i haven't checked) but it's not the end of the world. having the torrent client run on the same machine as the project drive is important and this morning i was able to shut down v5 for the first time in years, which was pretty cool (literally). it's by far the biggest power user out of all the v6 machines (by perhaps an order of magnitude - the other three are two laptops and a mac mini) so having it off when i'm not encoding is a boon.

the nas looks like it has a ~2 gig solid state drive for its software, which comes as an image file which is then flashed to it over the network (it doesn't come with any software preloaded, just a disc with an image on it to get you started). upgrades happen this way as well - of course i updated it to the latest after i got it and it worked great from my mac.

p> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/md0                  2.3G    235.0M      2.1G  10% /
/tmp                     62.0M    108.0k     61.9M   0% /tmp
/dev/md2                684.7G     38.8G    645.9G   6% /volume1
p> 

overall i'm quite pleased with it. it works as advertised.

i'd stayed away from wine previously because i was almost certain nothing as complex as my use of avisynth would run 100% satisfactorily. needless to say, i was quite surprised when it compiled on one of my macs and played an unmodified sda avisynth script in vdub correctly.

that was over a week ago, and i'm still not entirely over the weirdness factor of running the whole anrichan family of tools without running any microsoft code. so i guess i'm not as elated as you might imagine - more like dumbfounded. it's been one of those rare moments when technology catches me off guard.

i've read that wine works even better under linux due to apple's lame x implementation, so i'm now considering what to do with the one remaining machine i own that runs windoze as its primary os ("v5").

it's not perfect by any means - as far as i can tell, pipes aren't supported in batch files, which meant i had to reimplement everything in unix shell language. it hasn't been a big deal except in the case of anri.bat, which will need major reworking, and that's a damn shame, because i thought at first that i had "discovered" a universal anrichan.

i'm also having problems with processes, e.g. avs2wav and bepipe, not being able to close files that are on network volumes. the process will complete successfully, but the close call hangs, meaning i have to hit ctrl-c to continue the encode script - unacceptable. i've actually seen this before under windoze (though not working on sda stuff), so i doubt it's wine's fault per se - just something i'll have to dump more time into.

i also can't seem to figure out how to install codecs that include right-click -> install .inf files. i grabbed the dll call out of a real copy of doze and tried that, and it does run, but doesn't seem to produce any result under wine. i'm lucky the anrichan installer installs lagarith, because i probably wouldn't have access to that codec under wine for doing nmf otherwise.

speaking of nmf, here's my unix nmf command, my v command and my mq commmand as references for how i reimplemented snow's batches in unix shell language. sumichan is essentially unchanged because i'm still using avisynth - the only difference is the batch file writing for calling nmf.bat on each of the slices, which now obviously just writes calls to nmf instead. syntax is like

nmf "P:\\projname\\runname" 1

look for the first runs produced with the help of wine on sda soon.

unfortunately, the high quality deinterlacing filter mvbob() is not multithreaded. this means it can only use one core at a time. in the past i have set up multiple instances of vdub with e.g. one fourth of the total segments in a run to each, then started them all at the same time, but of course not all the segments are identical in length, so there would always be inefficiency as some vdubs would finish their deinterlacing before others.

avisynth is a very useful tool, and it was only a matter of time before i used it to automate a process by which any given input could be split up across a given number of threads, then automatically recombined later. i call this process sumi-chan for lack of a more creative descriptor (if the name were to describe the software properly, it would be something like "avisynth filter virtual multithreading system" - so long! so boring!).

usage is simple - i just run sumichan.sh with the avisynth scripts' basename and the desired number of cpu cores across which to split up the work, then run the resulting batch files on each real machine (one batch file for each cpu core). thus, entering 6 for sumi-chan's second argument results in six sets of avisynth scripts and six batch files.

due to rounding errors, if the number of frames in the source material is not divisible by the number of cpu cores specified, a few frames will be "squeezed" to the final work unit. this is unlikely to result in any significant inefficiency, as mvbob() usually processes between 1 and 2 frames per second even in extremely complex scenes. changes in said complexity throughout each work unit will result in much more significant inefficiency (compared to a true multithreading solution whereby all cpu cores would be simultaneously busy or not busy).

sumi-chan will appear as an optional feature in anri-chan 3 (we're getting close to the release of 2 right now). it ought to make encoding d1 material much more realistic for most people.

incidentally, i'm using quantizer 1 vfw xvid (via vdub) for the nmf. i've been extremely pleased with both the cpu and disk costs associated with this codec (they are much smaller than those associated with lagarith - and it crashes less to boot!).

of course, i have to include the obligatory crap quality picture of my new virtual computer, dubbed "v6". cores 1 and 2 are in the macbook on the left, while cores 3, 4, 5 and 6 are monitored on the mac mini's screen, but are in reality split equally between v5 (my pc) and the mini. (the terminal windows lower down on the mini's screen are left over from working on the prime hunters run as discussed in the previous entry.)

however, the original recordings needed to be cropped in order to get rid of their useless black borders. the catch was that the cropping parameters needed to be dynamic - that is, where and how much i need to crop changed every few seconds.

as i'm sure you've figured out by now, i came up with a way to accomplish this in a semi-automated fashion, and the rest of this blog entry will be devoted to this methodology.

the first step was to locate a simple autocropping plug-in for avisynth. this came in the form of the aptly-named autocrop, found at warpenterprises. thankfully, autocrop() offers a great deal of customization of the autocropping algorithm. the user can set not only the crop/don't crop threshold, but the number of sample frames the plug-in takes into consideration within the video, as well.

the crop threshold is probably 8-bit luma, while the sample frames are, according to the plug-in's author, taken equidistantly from within the source video. however, no matter how many samples the plug-in uses, there will always be only one set of cropping settings per video. thus, whenever dsgamer's tired hands moved ever so slightly, the screen would no longer be contained entirely within the initially-calculated cropping values.

the obvious solution was to make many more, smaller videos out of dsgamer's run - enter acrop.

this bash script takes two arguments: the basename of the video and audio originals and the number of frames in the original video. the script then creates a number of avisynth scripts, each of them including a number of source declarations and autocrop() invocations for bits of the original video.

i call each section of video on which autocrop() operates a "window". the window size is not arbitrary, but is determined by how long a sequence of absolute black will be on screen in the source video. if any window consists entirely of black, then autocrop() will naïvely produce 0x0 video, which is a contradiction in terms - avisynth has no ability, from what i have seen, to resize a 0x0 frame. thus, even though it's all black anyway, windows consisting entirely of black must be avoided. the window size, then, should be perhaps one or two seconds longer than the longest stretch of absolute black in the source video.

i found taking the correct number of samples, too, to be crucial: the process will fail (producing 0x0 video) if either too many or too few are taken.

for convenience and efficiency of processing, i included several windows in each new script file. for this speed run i created scripts 1000 frames long, 5 200-frame windows in each. because the source video was exactly 30 fps, a 10-minute segment would correspond to around 20 individual script files.

it was not possible to include every script file in one master script for two reasons. one was the extremely long startup time associated with stacking multiple instances of autocrop() on top of one another. on my core 2 duo 2 ghz, it took between 10 and 20 seconds just to open one script with 5 windows in it. the other was that each window represents one directshowsource() declaration for the source video - in other words, there was one copy of the entire source video in memory for each window in the currently open script(s). avisynth is extremely ram-inefficient in this way, but you can't blame it, actually, because we're talking about windoze here.

of course, my default autocrop() threshold of 100 was not always optimal. in fact, i had to preview every window in vdub to make sure it was not too high or too low. many times i simply replaced every 100 with e.g. 70 because the game environment in that particular segment was darker and autocrop() was getting fooled and cropping off parts of the game screen. it was also occasionally necessary to increase the threshold when e.g. the screen went totally white, resulting in light reflecting off surrounding objects and back onto the area around the ds lite's screens, in turn resulting in autocrop() leaving in the plastic border around said screens.

after i determined the correct autocrop() parameters for each window of a segment, i aligned the audio (recorded separately in audacity by dsgamer via an 1/8" miniplug cable) by placing the over-the-air audio from the original source video on the left channel and the correct, line-in recorded audio on the right channel. i knew that the "new" audio was lined up when i could not distinguish that sound was coming first in either the left or the right channel. i adjusted the correct audio's delay by using delayaudio() in a master avisynth script file which loaded all of the individual pieces of the segment in question (since saved from the original scripts as lagarith-compressed new master files).

i would like to emphasize my success with this relatively novel method of audio realignment. in sharp contrast to the usual method when it comes to audio realignment, i did not even have to look at the video to know the audio was aligned - i literally did the work with my eyes closed.

and so the world's first high quality downloadable nintendo ds speed run was prepared for distribution on sda. i hope that everyone enjoys dsgamer's hard work and my automation-laced lack thereof when his run is posted on sda soon.

i almost forgot - here's the obligatory screenshot of my initial autocrop() parameters discovery process.

in the above picture each | represents one frame. this drawing depicts one complete cycle and only one complete cycle, so the first frame not shown is the first frame of the next cycle. it would be solid blue like the first frame of this cycle.

oot is d4 f3. from the f1 original i was going to f2 first, then to f3 to avoid odd (deflickered) frames (shown above with a bar through them). otherwise i have to use retard bob which does a marginal job of undoing the deflickering and takes exponentially more cpu. more on deflickering in these two blog entries (incidentally this is the same reason i put up this topic).

the frame marked with blue is fine. the problem as i understand it is that sometimes instead of the motion happening in the green frame it happens in the purple or red frame (and gets lost as you can see on the f3 line). in these cases the pattern of motion in f1 is:

K D D K D D or
K D D D K D respectively, instead of
K D K D D D

where K is a motion frame and D is a duplicate (no motion). when i was testing this i saw only sequences of the last type which are ok. but there are often sequences of the first or second type. and once this starts it apparently continues for some time, thus the long, painful stretches of f6 people are seeing.

so basically the game isn't dropping frames at regular intervals. sometimes it will be ok to go -> f2 -> f3 but usually not.

the good news is that i think i've worked out a solution with the help of donald graft's decimate():

changefps(f1/2)
decimate(cycle=3)

this seems to be picking the correct frame (either green or red) from the f2 constellation, probably because it's checking to see that each frame is unique. this means i probably won't have to go back to the horrid retard bob.

total cost was $1,017.28. cost to sda was $339.09. 1/3 of the machine was paid for with sda funds for the following reasons:

1) the recent increase in the number of d1 f1 runs i need to encode for the site meant less and less idle time for my macbook. i was concerned that i would run out of cpu power to meet demand, especially after the warm reception of metroid prime 3 coupled with its length: the current estimate for an optimal any percent run is around three and half hours - not counting cutscenes. for reference, it takes about a week to encode 5 hours of d1 f1 video (deinterlacing to nmf and encoding all seven qualities) using four processor cores (assuming full speed from them all). i had been counting on most runs being d4, but this appears to be coming to an end.

2) related to 1), i had no quick way to take 10-20 gig of content in to campus to upload while the macbook is locked down encoding.

only 1/3 of the cost was covered by sda because i could have gotten a better machine for the money had it not been a mac (i wanted a desktop mac because using the macbook as one was suboptimal). granted, this will help me do non-encoding work for sda more efficiently, but i feel that is a rather weak reason to take more money from our reserves in this crazy time. also, regarding 2), the other half of the reason i have to have the macbook on campus is school, which has yet to demonstrate decisively that it is beneficial to m2k2sda (though it has been making gains of late: some work on anri-chan was actually done as part of my on-campus job!).

i backed down from saving up for the next beast machine (codenamed V6) because it no longer made sense economically. there are many factors involved, but to summarize:

3) i need more power right now (see 1) and 2)). an eight-core machine costs about $4,000. i wouldn't be able to afford that until may at the earliest.
4) there has been no solution found for multithreaded deinterlacing. therefore i will have to write my own (already discussed as a feature for a future version of anri-chan). once i do this, it will no longer matter how many physical computers are performing the deinterlacing - the load will be divided evenly between the available number of cores.
5) following from 4), continuing to pretend otherwise would mean that the macbook and V5 would be considered useless after the purchase of V6. together they have just under 50% of the theoretical power of V6, so this would be a great waste. by buying a weaker machine now and writing software to tie it together with my existing two, i can have 75% of the power of V6 right now for 1/4 of the price.

therefore, i now think of V5, the macbook and the new mac mini together as V6.

obligatory birth sequence documentation:

unfortunately, the amount of labor grenola, mike, snow, radix and i pour into sda, if paid, would equate to a sum much, much larger than $99 a month. therefore, when i declared sda monetarily self-sufficient two years ago, i was referring only to actual money earned and spent.

now it's time to take care of the rest.

for years, automating my job was a hopeless fantasy. the number of correct decisions required to encode material for the site was simply too high, and i knew of no way to have the computer make them for me. anyone who has seen the knowledge base and the tech support forum knows that asking inexperienced people to do my job as i do it is a losing proposition.

so i tried instead to make sda's revenue grow - to make the site pay us back for our work on it. i learned many things from my adventures trying to sell sda content on dvd, but probably the most significant was that it doesn't work: sda may never generate enough revenue to pay its workers, and sometimes i think it's better that way.

but the fundamental problem remained: sda needs people to add new content, and if i died today, i thought to myself, would someone be there to replace me? i decided that even though i can't control my mortality, i can control how i will be seen after the fact.

little by little i chipped away at the problem, making generic.avs into a highly concentrated, library-driven block of boolean action. generating the scripts for new projects became a matter of enabling or disabling variables. now one script could do it all.

but there still had to be someone there to make decisions based on the content of the source video. i had automated the ntsc/pal distinction, but the rest of them seemed hopeless: how should i tell the computer to check whether every second or every third frame is the same as the previous? and even if this could somehow be done - what about the games with a varying framerate?

therefore, i created the concepts of d (dimensions), f (framerate) and fdp (framerate decimation paradigm) to quantify the differences between games. if a database of every game's d, f and fdp could be created, i reasoned, then surely some sort of script could be written that would take those values and configure generic.avs, reducing my job to reading numbers out of list and typing them in to a window. even if the game in question weren't yet included in the list, it could be added by any tech support staff member after seeing a brief, automatically-generated sample of the game's video. it would be the next best thing to full automation.

as many of you are already aware, i decided to call this script anri-chan after the anime character who (like mickey and goethe before her) used magic to create numerous inferior copies of herself in a failed attempt to automate her job. thus, i am anri-chan, and anri.bat is an inferior copy of me. (when i began the project, i wasn't even aware that dgindex accepted arguments on the command line, and so i thought that automating the steps involving the user interface might be impossible, thereby dooming it all to failure.)

but these open source tools came through for me in the end, and so i was able to produce a proof-of-concept much more quickly than i had anticipated - and even better - it worked: other people were actually encoding acceptable video using anri-chan!

even vista couldn't stop me.

and as if that weren't enough, the free, open source model impressed me yet again today, as b-man in the sda forum went and wrote the anri-chan encoding settings manager for me. i have always said that it is not only me who can do this (just that i was the first to be chosen), and now i have been proven right. it really is true: if you build it, they will come.

i will finally make sda eternal by taking away the cost of its maintenance (at least as far as my job is concerned).

so now it's just a matter of writing comforting documentation ("when the program says do x, that's when you do x!") and officially releasing the software. with this i will simultaneously increase submissions, decrease my workload and therefore ensure the future of the site.

two years wasn't so long to wait, after all.

1.9G test_rgb24.avi
924M test_rgb24.avi.zip
680M test_huffyuv.avi
611M test_huffyuv.avi.zip
467M test_lagarith.avi
467M test_lagarith.avi.zip
328M test_x264.avi
328M test_x264.avi.zip

[22:02:54] <nate> quantizer 0 x264 avi it is
[22:03:12] <nate> though it seems lagarith would come close
[22:04:32] <nate> xp (10 megabaud) mpeg-2 original from dvd would be just over 42.5 meg
[22:05:10] <DJGrenola> wonder if snow has a lossless mode
[22:19:57] <nate> trying quantizer 1 etc
[22:37:46] <nate> looks like quantizer 1 and quality 1 are similar in size to the quantizer 0
[22:38:01] <nate> so what i'm going to do is no quantizer two pass 10 megabaud and look at the thing closely to see if i can see any artifacts
[...]
[23:13:42] <nate> the difference between the original and 10 megabaud is slight
[23:13:50] <nate> visible ... but not necessarily bad
[23:13:57] <nate> what it did was smooth out some areas
[23:14:03] <nate> typical of h.264 i guess
[23:14:18] <nate> the thing is that a lot of what it smoothed out was actually not supposed to be there in the first place
[23:14:22] <nate> because it was artifacts from mvbob
[23:14:34] <nate> so sometimes the lossy looks better than the lossless (1, 3)
[23:16:54] <nate> it's certainly better than mpeg-2!
[23:17:50] <nate> near key frames they're almost identical (2)

1: original | 10 megabaud 2-pass x264
2: original | 10 megabaud 2-pass x264
3: original | 10 megabaud 2-pass x264

[23:26:31] <nate> so 10 megabaud 2-pass x264 avi is the new standard nmf
[23:26:35] <nate> hurrah

just set "false" to "true" on line 7 to enable d1 (d4 is default). pal autodetection remains in from the last version, which i can't remember if i posted here or not. change "false" to "true" on line 23 to enable the statid (after you've finished filling out the trim(), for example).

additionally, you'll need to change all occurrences of "dx" to your project name, which should be the same as your index and ac3 basenames. you also may need to change your drive letter (i use p: for my project drive). finally, watch out for the path to the sda logo pngs in the statid subroutines (and, obviously, the LoadPlugin()s at the very top!). all the other options from lines 10-19 depend on the input video source and desired output quality.

enjoy!

i finally uncovered the connection last month during a series of tests i was running for OPERATION ZWEI, an sda-related secret project some members of the sda team are working on right now (expect to see its release sometime this summer). these tests involved extremely memory-intensive avisynth scripts, and i later decided not to accomplish the effect in this way, because the avisynth system is simply broken when it comes to memory allocation (thanks, doom9 guys!). however, this situation afforded me repeated chances to see the exact same "access violation" error pop up -- again, pseudo-randomly -- but this time while watching the task manager intently.

i was able to distinguish two different types of access violation errors -- one thrown when the avisynth mother process reached doze's 2 gb allocation limit and another when the process would attempt to allocate memory beyond the total (3 gb) available to doze. it was at this point that i realized that radix had basically saved m2k2sda from these pesky access violations making their way into final encodes, because under normal conditions i don't use more than 1 gb of ram on v5. surely 2 gb free should be enough for any normal encode to allocate freely without the danger of running over the edge.

and indeed, i haven't seen or heard of a new encode afflicted with the problem since installing the new ram.

the input syntax for this batch varies slightly from the others due to the need to insert LQ in varying places in the filename depending on whether the run is segmented or not. to help me remember it (and to speed up master batch creation), i've also created a generic.bat.