« avisynth to the rescue | Main | runner forgot to mark a segment? »

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 February 18, 2006 9:32 AM

Comments

Since I don't know your workflow I can't be sure, but I'm assuming the statid is put before the run. If you can't create the statid until the run is verified, try this:

1. Process/compress the run's video in whatever format you want, keeping the audio in WAV. Save this version for later.
2. Before sending it to your verifier, Direct Stream the video and compress the audio.
3. After verification and creation of the statid(with WAV audio), use an AVS to join the two. AviSource("statid.avi") ++ AviSource("run.avi")

The "++" performs an Aligned Splice, which fills in any gap left by statid.avi with silence. Vdub's "Append" command is Unaligned.

Posted by: andyo Author Profile Page at February 18, 2006 10:57 PM

holy crap.

i'm too in love with the amount of time saved making the "new master files" (especially when smart bob is involved) to go with that workflow now, but that last little trick (the avs aligned splice) will definitely come in handy as i try to apply statids to the last of the runs processed the old way.

have to say that comments like those are the number one reason why i made this blog.

Posted by: nate Author Profile Page at February 18, 2006 11:49 PM

Protoman? been a while since i've heard that name.

If you want a quick-and-dirty solution, have you thought of using the "Change so that video and audio durations match" setting under Video->Framerate in VirtualDub? It might not solve the problem completely, but it might help, and it'd be something preliminary to post until you get exactly what you want.

I've done some video capture/editing stuff myself for a while too. Anyway, I was wondering about some of the video distortions I see on some of your runs; I had the same problem when I tried to record some stuff onto tape years ago, and I just had a thought: Could the NES/SNES be using Macrovision? It seems like an odd thing to do, but it would explain a few things.

Posted by: OmegaWarrior at February 19, 2006 4:40 PM

long time no chat. would have to be more specific as to which areas of which videos you're looking at for me to try to explain what's going on.

as for the simple framerate resync in vdub, unfortunately it doesn't cut it, as the problem is not with syncing the framerate in one file but in multiple files so that they can be successfully appended.

things are good now, though - the "new master file" method described in this entry together with andyo's avs ++ tidbit provided in the first comment has worked wonders for this process i must do.

Posted by: nate Author Profile Page at February 19, 2006 4:47 PM

Post a comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


Remember me?