August 29, 2005
static audio adjustment in vdub
radix taught me today how to correct a static (unchanging) audio offset error in an avi using vdub.
you just go to audio -> interleaving and change the "delay audio track by" number to either a positive or a negative number. then hit ok and change both video -> and audio -> to direct stream copy, and save as a new avi. you'll need to check the new avi to see if you used too much or too little correction. i used numbers from about -20 ms up to -200 ms to correct the progressively worsening (yet static within each file) audio offset errors in smilingjack13's hard 22% run's later segments. (see the previous entry for more on how these errors were introduced.)
all in all i'm quite pleased with this, as it saved me not only from having to set up new jobs for all of the affected segments, but also from having to encode them to divx again as well (cpu cycles are one of my most precious resources here).
Posted by njahnke at 11:06 AM | Comments (3)
August 28, 2005
d1 vs d2 audio update
so it turns out the audio got progressively further behind in the dvd master as well as the divx master, just not as severely so. this means that i'll need to process each file's audio individually (which won't be quite as bad as it could have been were normalization necessary in this run) as well as correct the offset in each segment in imovie before i sent the project to idvd. will think twice about capturing in multiple files in the future, even though the disk space wasted in the process may be extreme.
Posted by njahnke at 1:55 PM | Comments (0)
August 27, 2005
d1 versus d2 audio
just learned the avisynth syntax for joining multiple files today:
clip = avisource("file1.avi", "file2.avi") ... and so i used it to join all of the smilingjack13 hard 22% files (most with one segment per file) (the reason i do this is so i only have to process the audio once, rather than once per source file).
unfortunately, as i was marking the segment boundaries for the five divx passes in the appended mess in vdub, it sounded as though the audio was getting progressively further and further behind. will have to check out one of the final files to verify this, but if true, it would mean that i would have to process the audio twice for such projects - once for the dvd master (d1) and once for the divx master (d2 (field split via avisynth)). most times that wouldn't be much of an issue, but for complex audio with lots of normalization false positives (i.e. loud cable tv programming wedged between segments, loud pops from pesky vhs hardware), it will be a pain.
my theory is that the d1 audio didn't match the d2 frames because the d2 appended mess's framerate was calculated all from the first file's framerate by avisynth, and i guess the later files had a slightly slower framerate than the first one did. perhaps the new tbc will help with this.
Posted by njahnke at 1:14 PM | Comments (0)
extend luma black point is a no go
so i was reading phaeron's blog and iirc he said he had the 'extend luma black/white point' feature in 1.6.x in order to correct issues with the old ati all in wonder dropping detail in dark areas. sounds like me, right?
well, i decided that this looked better than this, so i'll be sticking to brightness +10 (138) with the old drivers for any adjustments i make on capture. as far as i can tell, that luma black point adjustment is just a fancy term for a preset contrast adjustment, and there are big problems with doing it that way, especially for the divx encoder (wasted bits keeping track of noise in the margins that's not all #000000, etc). the detail regained in such an adjustment was just not worth how ugly the adjustment made the rest of the picture.
also, i received my new datavideo tbc-1000 yesterday, and this sonic adventure dx (ntsc) run is the first thing captured with it. i'm dropping about 1 frame every 2 minutes with a dvd master importing into imovie over the network. however, i'm pretty sure that the dropped frames are still the drivers' problem. too bad the newer drivers don't work for crap with vdub on this machine. i'll try to remember to post an update on whether the dropped frames are 'extra' (vdub reports 'no next dropped frame found' when hitting }) or actual lost information.
edit: looks like the dropped frames were "real" after all, about 70 out of 204776 captured.
Posted by njahnke at 12:54 AM | Comments (0)