« January 2006 | Main | April 2006 »
February 18, 2006
revolution to the origin
after applying the statid to the sonic 2 single-segment run caused a screech in the audio of the mq/lq and total sound desync in the hq/iq, i decided to reevaluate how i process runs.
the problem, according to radix, is that encoding a waveform to mp3 changes its length. this means that any videos appended to a video with mp3 audio will have problems with sound synchronization. unfortunately, because the run has to be sent to a verifier before the statid is applied in the overwhelming majority of cases, the prospect of encoding everything twice rears its ugly head.
radix suggested that i save each segment's audio to a file before encoding the video the first time. the implications of doing this, however, are not pretty. an insane level of automation would be required to prevent me from having to treat each segment of a multisegment run individually multiple times (first on the initial audio save and compress, then again when applying the statid).
what i'm trying now is actually running all of the filters on the segments, but then, instead of compressing them to divx, recompressing them to huffyuv. the processed (denoised/normalized) audio is also copied to the "new master files" at this time. for d4 runs, only one file is required; for d1, both a d1 and a d4 master file is required (the d1 for iq/hq and the d4 for mq/lq).
the most obvious drawback to this method is the large amount of disk space required. further, much of that disk space will be in use until the run is ready to be encoded with statid, and the verification process sometimes takes months.
advantages, however, are numerous: no more missed false starts at the beginning of segments with no keyframe in sight forcing a complete recapture of the run (with huffyuv, every frame is a keyframe), no more compressing everything only to find the run is rejected by the verifier (only 1-pass high quality would be created for verification purposes), no more desynced audio, and, most of all, no more six sets of operations i have to go through on the keyboard for each segment i want to encode (i/i/h/m/m/l). now, i just have to write a shell script to either write a jobs file or write a batch file for vdub's command line driver (i am undecided yet as to which would be the better option) that takes all of the "new master files" and performs the six operations on them. because the final version of the audio is included in each file, i don't have to worry about the location of the processed .wav file that came from the original captured video (indeed, it can be deleted as soon as the "new master files" are created). on top of that, i can safely apply the statid using the same shell script with little to no actual work on my part. plus, i only need one statid file for d4 video, which i only have to compress to huffyuv (right now i have to do two-pass encoding twice, once for the f1 statid and once for the f2 or f3 statid), and, to top it all off, the statid will now be encoded at the same bitrate as the rest of the file, eliminating potential problems with buggy players before they even start.
but do i have the disk space? a test with the recent legend of zelda new game plus run by trebor shows that the d4 "new master file" will take up almost as room as the original 720x480 capture. i can only assume that a d1 "new master file" would take up over twice the room of the original capture. this means over 100 gigs of space would be gone for a d1 run only two hours in length until the run could be verified. of course, a change in the verification process is all that would be necessary to largely negate this problem - i simply wouldn't capture the run until a verifier for it were lined up. i suppose i'll talk to radix when he wakes up.
Posted by njahnke at 9:32 AM | Comments (4)
February 13, 2006
avisynth to the rescue
unable to find the time to get gbpvr working on v5, i've been forced to go back to the old dv bridge (the pre-summer 2004 capture device) to capture pal.
now, this isn't like the days of yore when i would capture pal nes and get several frames dropped every second - the standalone tbc ensures that few frames are dropped, and following from pal's superior image reproduction, the image quality is quite acceptable. a few minor problems still cropped up, but nothing warranting any further delays in releasing the now-ancient prince of persia run or the amazing new mega man runs from freddy andersson. i will simply replace the videos with better ones when i get gbpvr working.
incidentally, the delay there is not so much gbpvr's or my fault, but rather that gbpvr is exactly what it sounds like - a pvr, and not some random capture program like vdub. what i am trying to do - get it to simply display and capture s-video in - seems to be very difficult for it, and people are encouraged to look to other programs (such as graphedit or vdub) if they need to do what i need to do. the problem is, i have read that you can force the region using gbpvr with a tv wonder elite, and that is exactly what i need to do.
and now for the main focus of this entry ... upon opening the .avs file in virtualdub for the mega man 4 run, i noticed that it was jumping up and down exactly one pixel every other half-frame. thinking it was probably a symptom of either freddy's vcr, the horrid pal nes video signal, my old dv bridge, or maybe even all three, i googled for a solution and found this page.
using a .avs file inspired by the information at the bottom of that page, i was able to successfully correct the jumping without applying any quality-mangling filters in vdub. as always, i've provided before and after videos for your enjoyment.
that .avs file can be used to correct any f2 (half framerate) frequency jumping in any video. unfortunately, it can't help with insipidmuckywater's recent genesis runs, as that motion was far too irregular to even attempt an automated correction with a fixed measurement.
Posted by njahnke at 11:12 AM | Comments (0)
February 1, 2006
statid reborn
they're much less exciting this time, but for whatever they're worth, statids (short for "station ids") now come with every new run released on sda through metroid 2002 (me). hopefully, they will cut down on other sites stealing the content and releasing it without crediting either me or (more importantly) the one who created the run.
here's a sample for your viewing pleasure:
it appears for five seconds before every segment of the run.
Posted by njahnke at 12:51 PM | Comments (8)