sda capture blog

money changes hands at least once every month, as i have to pay the $99 monthly m2k2sda server bill. when the google ads on the site earn us more than $99 a month, then sda requires no outside investment to continue to operate so long as it is continually updated (it's thought that otherwise, site traffic, and therefore ad revenue, would go down, while the server bill would remain the same, thereby reversing the aforementioned positive trend).

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.