DSPGuru or other: Relative Audio Frequency Question

[mkanar]

DSPGuru or other,

This question has to do with the audio part of video capture. I'm placing this message in this forum as those in this forum tend to have a more accurate and mathematical understanding of audio datarate/conversion than others. :) I make statements here

I am capturing video+audio at 29.9706fps (frames per second). VirtualDub actually calculates a more specific and accurate fps during capture. I assume that VirtualDub assumes that its calculated fps is accurate; this seems pretty simple, as I assume it is dividing the clock against the number of frames received from the video capture driver.

Anyhow, VirtualDub then calculated the relative audio frequency; maybe against the clock or maybe against the fps? There has been discussion that sound cards are inaccurate and that the relative frequency of capture varies during the capture. However, my tests with my various sound cards shows that each sound card captures at an inaccurate but consistant datarate. For example, my Dell machine captures at 44107.01 Hz. However, VirtualDub stores a flag in the AVI somewhere that describes the embedded audio frequency as being 44100Hz, the intended frequency. VirtualDub does however have an option when I open an AVI file for modification so that I can force the audio frequency to 44107Hz. Unfortunately, this value of 44107Hz is used by VirtualDub, but not stored back within the AVI file; I have posted a message in the capture forum to see if I can change the AVI file myself to reflect this more accurate value. Opening the AVI file with an audio frequency of 44107Hz is important because otherwise the length of the audio and video streams differ and thus will become out-of-sync.

My question here is what is more accurate in changing the audio frequency back to the standard 44100Hz: resampling the audio from 44107Hz to 44100Hz or simply cutting out 7 out of every 44107 samples (spaced-out) (I think that SSRC might use this method). In other words, what is more accurate: playing the 44107Hz-relative-datarate audio back as 44100Hz or 44107Hz?

I realize that the sound card can't play back 44107Hz. I ask this question so that I can understand if it is better to resample or cut-out-samples in order to match the length of the audio and video.

Thanks,
MKanar

[DSPguru]

greetings mkanar !
having a track at sample-rate 44107 means that you have more samples/information/resulution than your sound card can reproduce per second.

the question is : how do i decimate the information so it can fit my soundcard capabilites.

basicly, all sample-rate-convertors does the same thing : get rid of undesired data.
the more complicated thing to do, is to throw the undesired data without harming the desired data.

a signal sampled at 44107hz can represent audio signal with bandwidth up to 22053.5hz (shannon/nyquist), and throwing samples won't change that, it will only lead to aliasing (when high-frequencies are being reproduced as low frequencies, in addition to the low-frequencies that were originally there ).
in order to avoid this, HQ SRCs are implementing anti-aliasing filter before decimating the signal. that's why the SSRC method is much more advised than WLA's method.

use ssrc !
the conversion would take long, but the result would be fine.

Dg.

[tangent]

Originally posted by DSPguru
a signal sampled at 44107hz can represent audio signal with bandwidth up to 22053.5hz (shannon/nyquist), and throwing samples won't change that, it will only lead to aliasing (when high-frequencies are being reproduced as low frequencies, in addition to the low-frequencies that were originally there )

In this case, worst case scenario would be having a 22053.5Hz signal reproduced at 22046.5Hz .... ouch :)

[DSPguru]

aliasing is a bad idea. simple as that.

[mkanar]

Wow! Well, thanks for the mega-quick and very informative replies!

So, ultimately I am converting to mpeg 1 layer 2 for SVCD (hopefully with DVD2SVCD's AVI2SVCD in the near future), so I assume that the BeSweet commandline would go something like this (?):

BeSweet.exe -core( -input "44107.wav" -output "44100.mp2" ) -ota( -fs 44107 ) -2lame(-s 44.1)

Is a parameter such as -ota( -r 29971 29960 -fs 44107 ) valid as well? Well, I realize that the "-r # #" part isn't working yet, but...

Maybe it would be easier to calculate all of this in a different way all-together:

-When capturing, I know that my various sound cards record audio at a consistant rate that is near but not exactly 44100Hz. I have heard that sound cards capture at an inconsistant frequency relative to time, but my tests with many sound cards has demonstrated to me that different sound cards capture at their own relative frequency but that this minor shew away from 44100Hz is usually consistant (ex. 44107Hz consistantly with a particular sound card)

-I also know that the start and stop of capture occurs at exactly the same time for both video and audio.

-Finally, I know that the fps should be 29.9706 (in my case anyway).

-I have no dropped video frames (I simply turn off the video/audio sync and the capture app doesn't drop frames anymore)

-The assume that the playback applications easily determine the time length of the video using fps*number of frames=time in seconds.

So, if we know the proper time length of the video, is it possible to SSRC the audio as 44100Hz and adjust the time length of the audio to be equal to the time length of the video? I assume this would require 2 passes on the audio.

Had to ask.

Thanks!
MKanar