When you set the threads in the x264 codec to fully utilize your CPU, meaning all cores, and then some, you make sure the CPU is working at its maximum capacity just for video processing.

If you then add audio to the pile, the CPU just hasn't got any resources to spare, and if it does, it does a miserable job, thus resulting in lag which translates in asynchronous sound.

If that is the case, lowering the numbers of threads in the x264 codec should fix it. This way you can have both audio and video encoding in one go. I haven't tried this method, because I employ a different solution.

How I do it:

I process video and audio separately. First I encode/transcode the video, leaving the audio in its original form. Then I encode the audio and overwrite it.

Let say we have recorded a video and named this video myvideo_unedited.avi .

Transcode/Encode your myvideo_unedited.avi according to this or this BUT leave "Audio" at "Direct Stream copy". DO NOT change it like suggested in the aforementioned links and name this new video for instance transcoded-myvideo_RAWAUDIO.avi.

Now open transcoded-myvideo_RAWAUDIO.avi and set your "Video" to "Direct Stream copy". In "Audio" you set it to "Full Processing Mode". Go on and set your "Compression", "Volume", and other settings to your liking and save this new sound via "File"->"Save WAV...". The WAV-file is called the same as the video, in this case it'll be transcoded-myvideo_RAWAUDIO.wav.

Now set your "Audio" to "Direct Stream copy", and click "Audio from another file..." and select the new transcoded-myvideo_RAWAUDIO.wav and save this new video with its new audio via "File"->"Save as AVI..." and name it for example myvideo_final.avi.

You're surely asking why I'm doing this stupid extra work, when I can just lower the threads and be possibly done with it. The answer is transcoding/encoding speed. Lowering the threads in the x264 codec translates into longer transcoding time. Processing video needs much, much more time, than processing sound does.

Say for example, if I were to encode a 15 min. video, and I'd lower the threads just so I can process sound and video in one go, the whole process might take me maybe 1 hour, 30 min. If I encode video first, and leave the sound alone, the process takes me about 1 hour to complete. Then I process the sound alone which takes about 10 seconds. After that I merge both and I'm done in 1 hour and 5 min. That's 25 minutes shaved off.

Another important notice: Sometimes the sound is asynchronous when you play it in your vlc or any other player. However after you upload your video to YouTube the sound magically seems to be synchronous again. I haven't got a clue why that is but it happens sometimes.

Related posts:

1. VirtualDub 720p HD settings for YouTube! [Good quality, small file size]
2. Fraps & VirtualDub: How to save disk space and enjoy good quality, small file size HD video clips
3. VirtualDub: How to split and merge video files

But no it wasn't. The lag was caused by Firefox's session saving feature. A simple and fast change in it and "poof" went the lag.

• Open Firefox and type in "about:config" (without the ") in the Address Bar and hit Enter.
• Type in "session" in the "Filter" line at the top of the list.
• Find “browser.sessionstore.interval” and double click it. The 10000 milliseconds (equals 10 seconds) is the interval in which Firefox keeps saving your session in case of a crash; same amount of time between video lags.
• Change it to something different. 120000 equals 2 minutes, 300000 equals 5 minutes or something else you desire. I went with 600000 (10 minutes), because I don’t particularly care about session saving.

Related posts:

1. Firefox: “I see where you are!”, Me: “No, ya don’t!” [Turning off Geolocation Tracking in Firefox]
2. Using Firefox 3.x? Speed it up by vacuuming its SQLite database!
3. Force Firefox Add-ons to work with Firefox 3.6 betas!