sda capture blog

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.