From: Jonathan W. <jw...@ph...> - 2007-02-06 00:28:14
|
> when decoding dv video libdv gives me sometimes > 1921 audio samples instead of the expected 1920. > I' assume that this is some additional sample > to match the 25fps (PAL) timecode, but dividing > 48000/25 gives exactly 1920 so this seems not to be > necessary. It sounds very much like a (non-standards compliant) form of unlocked audio as implemented on some video cameras. The footage doesn't happen to come from a Sony camera which is around 7 years old, does it? In the affected cameras the frame clock is not synchronised to the audio clock at all - both are effectively free-running oscillators. Therefore relative to the video frame rate the audio sampling frequency will not be exactly 48 kHz, but rather something like 48.00001 kHz. This in turn means that every so often you happen to get 1921 audio samples taken in the time a given video frame is captured, which is why you see periodic occurances of 1921 audio samples in some video frames. Note that this type of unlocked audio is not described in the DV standard. The standard unlocked audio can drift in the short term (so you can get 1921 samples per frame) but over the long term it doesn't (occurances of 1921 samples are balanced by occurances of 1919, for example). The behaviour you're seeing is in fact more annoying than the official version of unlocked audio. The problem is that the resulting audio track, when assumed to be exactly 48 kHz relative to the video frame rate, will end up being too long; the end of the audio track will correspond to the end of the video track in terms of material, but (for clips 10 minutes long or longer) the audio will end some seconds after the video. Unless your editing software knows about this and can correct for it, a lot of your audio will be out of sync. This is the situation I have with a camera I use regularly. I wrote a little application called audiosync to deal with it. I capture using dvgrab to a Qt/DV file and then run audiosync to effectively resample the audio so it remains in sync with the video. This process means the pitch remains unchanged (as it should) but the resulting audio track is sampled at exactly 48 kHz relative to the video frame rate and thus is now the correct length. You can grab audiosync 0.4 from http://www.physics.adelaide.edu.au/~jwoithe/audiosync-0.4.tgz (I have a new version ready to go which will appear when I have time to make it so.) > And: when I simply ignore this additional sample the sound stops crackling > in my program. But maybe the timing in my program isn't that perfect yet. Which program are you using and how are you using it? Normally ignoring the extra sample will produce slight clicks in the audio output - possibly not detectable if the audio is speech, but with music they can be quite obvious. It sounds like the program might be one you wrote yourself so there might well be an issue in the code. If you could make a tarball available somewhere someone might be able to take a quick look and see if anything is obvious. I suspect there might be a gremlin in there somewhere because I've never had crackling when I've played the captured DV stream (with the periodic 1921 samples per video frame) back with things such as glav and mplayer. Regards jonathan |
From: Leander S. <leg...@t-...> - 2007-02-28 07:05:06
|
Jonathan Woithe wrote: > audio as implemented on some video cameras. The footage doesn't happen > to come from a Sony camera which is around 7 years old, does it? Yes, thats a good guess. It's not my cam but i know it was a Sony and I think it was some years old. > You can grab audiosync 0.4 from > http://www.physics.adelaide.edu.au/~jwoithe/audiosync-0.4.tgz Thanks a lot for your detailed answer! And sorry for my late reply. Leander |