48 kHz audio in Camtasia 9

Wow, that does look pretty out-of-sync! I'll download the original and do some testing with it. Thanks for reporting this issue.

Hi Kevin, thank you for the fast reply and looking in to this specific example. The larger question I have is what specifically you guys have done for 48kHz in Camtasia 9. If it's supported and this is a bug specific to the Logitech Capture software, that would be OK.

For a long time now, Camtasia's timeline has run at 30-fps video and 44.1 kHz stereo audio. What has changed is how we decode and resample audio to 44.1kHz. In the 8.4 release (May 2014), we switched our resampling to use our own code in place of the older component supplied by the Windows DirectShow API. That resolved some long-standing issues with video and audio slowly drifting out of sync. With Camtasia 9, we use a newer Windows API (Media Foundation) for most of our audio decoding and resampling and so far have had good results with that. Camtasia 9 shipped with a brand-new set of default library media, and all of the music clips in that are 48kHz stereo audio.

Ideally, I think we'd like our timeline to run at arbitrary frame rates up to 60-fps and have some choice available for the audio format. 48 kHz would seem like a reasonable default these days; I think 44.1 was chosen for CS 6 because that was "CD quality". That is something that is under discussion currently, so I can't comment at this point on when that might show up in a release.

For the specific example that you posted, what I'm seeing on two different machines (Win 7 and Win 8.1) is that the audio and video are out-of-sync almost from the very beginning during preview and production. I've opened an internal bug report on it but so far haven't had a chance to dig into it too far. I think what is happening, though, is a problem with the video stream. It is at a frame rate that is a little odd (29.95 fps) but normally that should not be a problem. Based on the testing I've done so far, it looks like what's happening is we're jumping around a bit trying to find the correct video frame to match the time of the audio. That's very inefficient compared to the normal behavior of mostly stepping through the video frame-by-frame; I think that is the source of the out-of-sync issue in this case. I tried re-encoding the video stream to a constant 30-fps while keeping the audio at 48 kHz and working with that file previewed and produced without sync issues. The webcam you are using is a very common one, so I checked one out from our QA folks and tomorrow I'm planning on seeing if I can reproduce the problem recording with that. If the recording software provides some control over the output format, that may be a temporary workaround for Camtasia not handling these files correctly. Otherwise, having more files to test with should help in narrowing down the decoding problem. I'll report back here once I have some more info.

Kevin, thanks for the detailed response and a look 'under the hood'.
The Logitech Webcam Software (v2.80 now) has limited settings for output. So workaround might be finding a different webcam capture tool with more granular settings -- sounds like frame rate might be the key here.
Let me know if I can provide any other assets for testing.

Native 48kHz support would be in top 2 request for our company. #1 is White Balance control : )

Hey, sorry I never got back to you. I noticed something unusual about your sample file that I haven't been able to figure out so far. If played from the beginning, the audio is horribly out-of-sync. But if you start the playback a few seconds in, or just trim in those first couple of seconds, the audio seems fine. So if you are seeing that same behavior on all of your webcam recordings, that may be a workaround.

I wouldn't think 29.95fps is unusual or odd; it is the SMPTE standard for broadcast video, isn't it?  That frame rate is why chronologically-accurate time code must be drop-frame (which was always an annoyance in the ancient days when you might have to calculate insert shots precisely).

29.97 is the standard. 29.95 is odd
https://en.wikipedia.org/wiki/SMPTE_timecode

You're right.  I never noticed the 5 instead of the 7.  Is that even possible anywhere?

I guess the hardware creating the video may be involved?

I would assume it's the encoding process -- but what video encoder would enable such a strangely nonstandard frame rate?  I understand how the various standards evolved, but why would an encoder make something deviate from standards by 2%?  Maybe the post just had a minor typo -- nothing else makes sense.