Samplerate and Sync.

[IanB]

To be pedantic Amplify after you ConvertAudioToFloat.

And as I keep hinting if your work flow will accept 24bit, 32bit or sFloat use it! Avisynths ConvertAudioTo16Bit just does bit length truncation (no noise shaping), good audio encoders like AAC can include noise shaping as part of their lossy compression.

[zerowalker]

Ah, so it´s better to Amplify with Float, if it´s going to be Float in any stage?

Well my work flow is pretty much, Edit it in Avisynth and then Encode with x264 and AAC for example.

But if lossy encodings can do better with the highest quality work flow (Float in this scenario as i am resampling) i will keep that in mind.

So to do that, i will have to do something like this, right?

global OPT_AllowFloatAudio=True
v1 =Avisource("Z:\Yoshis Island\snes9x-unicode 2013-04-25 06-17-14-807.avi").Assumesamplerate(47999).Amplify(2.8).Convertaudiotofloat.ResampleAudio(48000).DelayAudio(-0.032)
Intro = avisource("E:\Fraps Projekt\Intros etc\Final 16-9.avi").Convertaudiotofloat.Amplify(1.77)

Clips = v1
AlignedSplice(Intro.resampleaudio(48000).Zoombox(Width (Clips), Height (Clips),ResizeMethod="BicubicResize").ChangeFPS((Clips)),Clips.ConvertToYV12(matrix="Rec709"))

Then feed it directly to the Lossy Audio encoder?

EDIT:

Or wait, i don´t really need to use: global OPT_AllowFloatAudio=True, if i feed it into the encoder right?
As it´s not converted to AVI, it should be float. It´s only if i save it with Virtualdub for example, that i would need it to prevent 16bit conversion right?

[IanB]

You should aim to only have zero or one bit length truncation operation in your audio graph. Bit length truncation happens every time you need to round the result of a calculation. E.g. in 16bit Amplify does So=(Si * K + 65536) >> 17, K=131072 is unity gain. Converting sFloat to 16 bit does So=(short)(Sf * 32768.0f + 0.5f) which is exactly the same rounding. So if you do 1 Amplify or 1 MixAudio or 1 whatever with 16bit input and 16 bit output that okay. If you need to do 2 or more operations then it is advantageous to do all the operations in sFloat and take a single hit with the single output bit length truncation. And if you can avoid the bit length truncation altogether e.g by folding it into the noise shaping of an advanced lossy audio compression then .....

Now the noise levels we are discussing here are very small, usually only extreme audiophiles have equipment that can reveal the noise and thus care about it. The 16 bit path in ResampleAudio does many 100's of these rounding operations so exposes the noise quite dramatically.


Yes, OPT_AllowFloatAudio and other option only effect the AVI/VFW output layer. If an application uses the Avisynth API then whatever the application does with the API is what you get, e.g. I believe MeGUI can automatically append a ConvertToYV12() to the end of it's graphs. The global OPT_AllowFloatAudio=True costs you nothing in your script, applications are free to ignore the value or implement some appropriate function of it's choice.

[zerowalker]

Okay thanks, really helped me out.
Think i got hold of it.

I will do it as the script above, as i currently does a bit more job, and as you said, it´s better to do it all in float. And i do use MeGUI and it should be able to feed it directly to the Encoders.
And if a do need it in AVI in float for some reason, i will use that command.

Really appreciate it, thanks!:)

[zerowalker]

Okay once again i need help.

This time i have need for getting samplerate to work in float.

To be exact, i need 48000hz to work in 47998.88hz

The earlier way doesn´t seem to work, where you could calculate the ms per hour and use a special function and resampling/conversion to get it to the work in more precision than "Assumesamplerate".

[IanB]

Read this thread again from post 21.

Do you want to build "AssumeSampleRate(47998.88).ResampleAudio(48000)" which will increase the audio duration by 84 milliseconds per hour. So AdjustNumerator=3600084 and AdjustDenominator=3600000

Or do you want to build "ResampleAudio(47998.88).AssumeSampleRate(48000)" which will decrease the audio duration by 84 milliseconds per hour. So AdjustNumerator=3600000 and AdjustDenominator=3600084

[zerowalker]

It doesn´t work.

it does work if i use this:

XAr = 28800 # Lowest rate that supports 62.5ms/hour

Limit=Floor($7FFFFFFF/XAr)
Num=ContinuedNumerator(AdjustNumerator, AdjustDenominator, Limit)
Den=ContinuedDenominator(AdjustNumerator, AdjustDenominator, Limit)


that you added, but is it accurate( thinking about the XAr variable).

[IanB]

Are you using Avisynth 2.6.0 Alpha 4 [130114] or a recent build that includes this bug fix :-

* Fixed ResampleAudio NOP test to compare vi.num_audio_samples, not sample rate.

If you are, then you can use the much simpler method at the bottom of Post 35. This avoids all the dodging precision and word size limitations that have plagued you in this thread.

[zerowalker]

Nicely, Works!

But i have used the MT versions of 2.6.

What is the different (Except MT)?

//Edit

How is the resampling btw?

Is it better than Assumesamplerate(47999) and resampleaudio(48000) which introduced quite some noise?
Or will i haveto convert to float before resampling?

(Checked it, it´s the same, which make sense:) )

[zerowalker]

Okay it seems my calculations where off.

If you look at these pictures, you can see that it´s the exact same place, but at different times.

So i use this clip to try to calculate the desync problem.

As you can see, it´s very close in the waveform, but still not correct.

This is with:

AdjustNumerator=36000710 # 100ms per hour
AdjustDenominator=36000000
Ar = Audiorate()
AssumeSampleRate(1) # Scale to crib a lot more precision
ResampleAudio(AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate

It seems that it should be

3600070x

But i can´t work at that precision, as it doesn´t change anything.

[IanB]

You cannot use thisAssumeSampleRate(1) # Scale to crib a lot more precisioncheat unless you have a version that includes the above mentioned code change.

To see if the script is working as required carefully check the before and after "Audio Length: 1742584833 samples.". The number should change by 48 per (millisecond per hour) per hour correction you apply, i.e 34367 samples for the 71 ms and 10 hour example above.

[zerowalker]

Okay, will use the version without MT then.

Okay i checked, the Samples seem to change, but the waveform() doesn´t.

Perhaps it can´t "see" small changes?

Look at this.
AdjustNumerator=36000710
http://i40.tinypic.com/e5ldlc.png
AdjustNumerator=36000717
http://i44.tinypic.com/bg1s83.png

As you can see, there isn´t any change.

Or well, there is a , extremely tiny change in the wave, if you look at extremely carefully.
But it doesn´t move.

But if i change from AdjustNumerator=36000717 to 718, it will move drasticly.

Here you can see.
The left is very early in the clip, the right is at it´s end about 10 hours later.
The waveform should appear very similar (atleast the loud part).
But as you can see, it´s off by a bit after 10 hours, even when i try to correct.
This is because i can´t move it a tiny bit, only big movements (atleast according to waveform() )

http://i43.tinypic.com/alr8yo.png

[IanB]

Okay I see what you are saying, the AudioLength has changed by the expected 7ms in 10 hours, but the audio graph has not shifted the waveform by 7ms on a frame near the end of the clip.

I assume the audio wave display is 1/30 of a second, 1600 samples. And 7ms is 336 samples which would be 21% of the wave display window. What tool are you using to paint the waveform display, it seems to be mapping the audio samples onto the video frame inaccurately.

I lashed up this script to prove the current Avisynth works as expected :-ColorBars(640, 480, "YV12") # 1 Hour
ChangeFPS(100, 1) # 10ms resolution
Trim(0,0) # Force AudioLength == VideoLength
Loop(10) # 10 Hours
X=Last # Save original

AdjustNumerator= 36000010 # Plus 10ms
AdjustDenominator=36000000
Ar = Audiorate()
AssumeSampleRate(1) # Scale to crib a lot more precision
ResampleAudio(AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate

MergeChannels(Last, X) # Mux new and old
Info()
AmplifyDB(-48.0) # Scale for display
Histogram("AudioLevels")
yes the audio is 10hours and 10ms and yes the new right channel, 2, per second transitions happen 1 frame later than the original, 4, at the end of the clip.

[zerowalker]

Yes it seems to, which makes it hard to do what i want.

I am using this plugin: http://forum.doom9.org/showthread.php?t=165703

I looked through and as you say, it seems to do it´s work, the only thing is then that the waveform is incorrect.

[IanB]

Waveform works correctly with my test script....
AmplifyDB(-48.0) # Scale for display
Histogram("AudioLevels")
AmplifyDB(48.0) # Scale for display
Waveform(1, Under=True)

:script: Post your entire script, you must have something strange happening.

[zerowalker]

Weird, but sure.


directshowsource("Z:\snes9x-unicode 2013-04-25 12-50-25-985.avi").DelayAudio(-0.032)
Crop(94, 0, -94, -0)

ConvertAudioToFloat()
Amplify(15)
AdjustNumerator=36000706 # 100ms per hour
AdjustDenominator=36000000
Ar = Audiorate()
AssumeSampleRate(1) # Scale to crib a lot more precision
ResampleAudio(AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate
info()

waveform(under=true,window=1)
Trim(1036, 1036)++Trim(1076458, 1076458)
StackHorizontal(Trim(0,0),Trim(1,2))


I am not sure we fully understand each other, if so i made a picture to clear things out what i am trying to do.

Point A, is where the sound should be at, if you look at the left.
http://i41.tinypic.com/4qiv0h.png

[IanB]

Are you adjusting in the right direction? In the post above you seem to want the audio at the end to play earlier, in which case you would need to shorten the audio track. I would estimate by about 7 milliseconds total in 10 hours 5 minutes. Thus try AdjustNumerator=36000699 # 69.9 per hour, i.e. 0.7ms per hour less.

Of course you do realise 200 milliseconds is generally consider the point that an audio delay is just noticeable.

[zerowalker]

Problem is, it won´t detect small changes for some reason.
It´s hard to show, would like to give you the clip, but it´s 10hours and well, extremely big.

But here is an example.

http://www.sendspace.com/file/64n02i

As you can see, nothing happens, until "d8".
Hope that shows what i am trying to explain with the lack of accuracy.

And yeah i know that i am currently working with quite an overkill in terms of what human can notice.
But i am quite a "perfectionist" or what to say. When i know it can be fixed extremely correct, than i want to do it.

I have you to thank for this, you are helping me extremely with what can be done with this case, thanks:)

[IanB]

I can see you are getting "quantisation" in your script. I am at a loss know what is going on. There must be some wood in them there trees, I just cant see it :confused:

I modified my test script, please try it :-Function DoIt(Clip clip, Int AdjustNumerator) {
clip
AdjustDenominator=36000000
Ar = Audiorate()
AssumeSampleRate(1) # Scale to crib a lot more precision
ResampleAudio(AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate
}

ColorBars(640, 240, "YV12") # 1 Hour
ChangeFPS(100, 1) # 10ms resolution
Trim(0,0) # Force AudioLength == VideoLength
Loop(10) # 10 Hours
ConvertToMono()

A=Doit(36000706)
B=Doit(36000705)
C=Doit(36000704)
D=Doit(36000703)
E=Doit(36000702)
F=Doit(36000701)
G=Doit(36000700)
H=Doit(36000699)

MergeChannels(A, B, C, D, E, F, G, H)
Info()
Waveform(1, Under=True, Height=60)Frame 3599970 should encompasses the last per second transitions, and each transition should be 0.1ms earlier.

Run this script and post a copy of frame 1076458.Function DoIt(Clip clip, Int AdjustNumerator) {
clip
AdjustDenominator=36000000
Ar = Audiorate()
AssumeSampleRate(1) # Scale to crib a lot more precision
ResampleAudio(AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate
}

DirectShowSource("Z:\snes9x-unicode 2013-04-25 12-50-25-985.avi")
DelayAudio(-0.032)
Crop(94, 0, -94, -0)
ConvertAudioToFloat()
Amplify(15)

Spline16Resize(640, 240)
ConvertToMono()

A=Doit(36000706)
B=Doit(36000705)
C=Doit(36000704)
D=Doit(36000703)
E=Doit(36000702)
F=Doit(36000701)
G=Doit(36000700)
H=Doit(36000699)

MergeChannels(A, B, C, D, E, F, G, H)
Info()
Waveform(1, Under=True, Height=60)

[zerowalker]

Yes, the only thing that changes until the last picture, is small "jitter" in the waves, but it doesn´t move.

Here is pictures from your scripts.

http://i42.tinypic.com/a2xc0i.png
http://i40.tinypic.com/eg4tjm.png
http://i40.tinypic.com/dgqfpi.png

Something weird is going on, you script seems to work just fine though, but not for my clip:S

[zerowalker]

Noticed something, if i resample the audio from something, than back to 48000 right before changing the lenght, it seems to act quite different.

Here is with: ResampleAudio(48001) and back again.
http://i41.tinypic.com/348ghty.png

[IanB]

Try adding a Preroll(audio=10) after the DirectShowSource(), if that doesn't help try an EnsureVBRMP3Sync().

[zerowalker]

It seems that EnsureVBRMP3Sync(). may be working.
But it´s very hard to try it out, as it need to read the 10hour clip every time i change anything, which takes ages:(

Preroll(audio=10) didn´t do anything though.

Though may be worth mentioning, i am NOT working with MP3 here, it´s pure PCM.

[zerowalker]

I think i detected the problem, it comes from Directshowsource.

I am using a file saved as Lagarith, with PCM 16bit 48khz Audio, and if i use Avisource, the audio goes silent after 3:52:11 hours, so i use directshowsource, and it seems to lack accuracy with that.
Though i don´t understand why the audio goes silent.

I even tried saving the audio and using audiodub, but i get:

AVIFileSource: Coultn´t open file

And i am using WAVSource on an .wav file, i don´t see the problem.
But i think Avisynth may be limited on how long the wav file can be, which seems to be 3:52:11 hours.


But it does work if i load it using Directshowsource, like this:

avisource("Z:\snes9x-unicode 2013-04-25 12-50-25-985.avi",audio=true)
audiodub(directshowsource("F:\Desktop\snes9x-.wav"))

Then everything seems to be working.
Though i would like to get the audio to work without this through Avisource().


Worth mentioning is.

avisource("Z:\snes9x-unicode 2013-04-25 12-50-25-985.avi",audio=true)
audiodub(directshowsource("F:\Desktop\snes9x-.wav"))

With this, it´s all good.

directshowsource("Z:\snes9x-unicode 2013-04-25 12-50-25-985.avi",audio=true)
audiodub(directshowsource("F:\Desktop\snes9x-.wav")

With this the problem occurs.
So it has to do with the how the video acts or something.
You maybe have a guess?

EDIT:

The problem works with

directshowsource("Z:\snes9x-unicode 2013-04-25 12-50-25-985.avi",audio=false)
audiodub(directshowsource("F:\Desktop\snes9x-.wav")

So it works if i use Audio=False.

[IanB]

Looks like something to do with Direct Show is quantising the audio seek position for big values. In the bottom image of your post 70 above :-
http://i40.tinypic.com/dgqfpi.png
The channels 5 & 7 have glitches and the shape of 8 does not match the others.

Given seeking is screwed for high number samples I am not surprised Preroll does not help. And EnsureVBRMP3Sync() which uses brute force to make seeking work properly solves the issue (but creates a performance issue).

Not sure why the audio goes silent after 3:52:11 hours it is some odd value. For 48000 you usually run into 32 bit size limits at 12:25:39, 6:12:49 or 3:06:24. Maybe this is where the container crosses a 32 bit boundary :confused:. (For 44100 the 32 bit boundaries are at 13:31:35, 6.45:47 and 3:22:53)

[creaothceann]

What about WAVSource or other source filters (http://avisynth.org/mediawiki/External_filters#Source_Filters)?

[zerowalker]

Looks like something to do with Direct Show is quantising the audio seek position for big values. In the bottom image of your post 70 above :-
http://i40.tinypic.com/dgqfpi.png
The channels 5 & 7 have glitches and the shape of 8 does not match the others.

Given seeking is screwed for high number samples I am not surprised Preroll does not help. And EnsureVBRMP3Sync() which uses brute force to make seeking work properly solves the issue (but creates a performance issue).

Not sure why the audio goes silent after 3:52:11 hours it is some odd value. For 48000 you usually run into 32 bit size limits at 12:25:39, 6:12:49 or 3:06:24. Maybe this is where the container crosses a 32 bit boundary :confused:. (For 44100 the 32 bit boundaries are at 13:31:35, 6.45:47 and 3:22:53)

I see, well that explains it.

Hmm, well i don´t know either, maybe it has to do with the video codec (I am using LAV Filter, and i guess it takes over the decoding of Lagarith with Directshow). But i don´t see how that matters for the audio. Or maybe it´s the AVI Splitter, don´t know have Avisynth works with that.


What about WAVSource or other source filters?

WAVSource doesn´t even work with the wavefile for some reason.

I get:

AVIFileSource: Coultn´t open file

So i have to use Directshowsource:(

It´s very odd.

[zerowalker]

Well it doesn´t really matters as i normalyl don´t work with files that are 10 hours;P
It´s just a test sample to use for sync purposes.

But i wonder.

I Virtualdub when i capture, it can detect the actual rate compared to the intended.
IF you look at Relative rate under Audio.

Is it possible to use that method to get a get the sync value (hz value)?

As virtualdub can only use the methot on capturing, which seems a bit limited as it also has to capture video and all that.

And the Relate Rate isn´t float, it´s Int with 2 decimals, so it´s a bit lacking.

http://i43.tinypic.com/34ythxj.jpg

[raffriff42]

Very interesting discussion. I would advise not to resample the audio for such a minor speed correction, because of the artifacts. If you must resample, use SSRC ('http://avisynth.org/mediawiki/SSRC')(32-bit float + supersampling). Note the caveat on the SSRC Wiki page:
Sampling rates of 44.1kHz and 48kHz are popularly used, but the ratio of these two frequencies is 147:160, and they are not a small numbers. Therefore, sampling rate conversion without degradation of sound quality requires filter with very large order, and it's difficult to achieve both quality and speed. This program achieves relatively fast and high quality with two different kinds of filters combined skillfully. The author is referring to the need to find the least common factor of the two sample rates, supersampling the audio to that common frequency, and subsampling to the new frequency. This is the only way to do it without getting strange artifacts like you are seeing. Now if 147:160 is a problem, yours is impossible.

70 ms is two video frames at 30 fps. Can't you find two frames per hour to drop or repeat as required? This would be a much better way to go.

[zerowalker]

The problem is that SSRC is very limited, and doesn´t allow resampling here and there.
I only get problems with 16bit, if i use 24bit+ (preferebly Float), there is no artifacts that i can hear.

And as you say, it´s another way to solve it, by adding/dropping frames, which i looked into a little while ago.

But i am currently trying to analyze the problem.

I want to know, Is it the audio that goes out of sync, or the video.
As i only guess it´s the audio, but i actually don´t have anything to back it up.

The best thing also, would be to solve the core problem, as there shouldn´t be desync to begin with.
I would appreciate it, if you could try to reproduce the error on your side, raffriff42.

If you could try to record something that goes on and on for along time (while you sleep) and see if you get the sync problems.
A recommendations is Super Mario World, as the intro there just goes on and on the same all the time.

btw, thanks for joining the discussion:)

[raffriff42]

Windows multimedia timing, specifically how it chooses a reference clock, is a mystery, wrapped in a riddle, etc - at least to me. My guess is your audio card is supplying the audio sample rate clock, and it it running approximately 0.000016% off for some reason. Probably due to the digital frequency generator's limited precision. Whatever. I am a "git er done" type of guy and try not to obsess over little things like this. :)

[zerowalker]

Would really love a way to calculate the off sync compared to that reference clock so i can get an exact value.
There should be a way to get it, but i don´t know how, Virtualdub seems to know a way to calculate the desync somehow, but i don´t know how.
And i can´t find any information at all on this.

Yeah i know that i am to obsessed, but i am a perfectionist, i can´t tolerate 70ms per hours, it´s just not possible.
If i know there is a problem, i have to solve it, Sync problem is one such problem where i can´t turn blind eye at all.

This is also true for capturing Analogue material, i will get the same desync there, and it´s extremely important to have good sync there, you can´t just duplicate frames here and there.
Or well you can, but you will lose information that way, which isn´t something you want on such material if you are into archiving and restoration.

[StainlessS]

Methinks you are destined for serial disappointment.

[zerowalker]

Well probably;P

Does this application work for you?
http://www.agm.me.uk/blog/uploaded_files/SoundSpeed.zip

It seems to do what i am looking for, but not sure if it works correctly.
http://www.agm.me.uk/blog/2007/09/soundcard-clock-accuracy.php

To confirm this theory I coded up a small application that uses the Windows multimedia API test the clock speed of the sound card. It compares this with the system clock to work out the error.

[zerowalker]

Does anyone have knowledge in Graphstudio/Graphedit?

It seems that i may be able to use it to determine the clock sync between to devices/filters.

[StainlessS]

Search , Advanced mode, threads, tites only: "GraphStudio OR GraphEdit" (EDIT: Without quotes of course)

You will find plenty of threads where you may be better served.

[zerowalker]

Found this: http://www.nomadelectronics.com/Vidcap/DirectShow/ShowClock/ShowClock.aspx

Can anyone test it, i atleast don´t get a match of 1, i get about 0.999xx

[Ghitulescu]

maybe is a problem with the recording software ...

[zerowalker]

Sadly that´s not the case.
I have gotten it down to that it´s the difference between the capture device clock and the audio clock that makes the sync problem.

And the capture device clock in this case, is the PC itself, which is what is weird.
If you capture video from a capture card, and audio from a sound card, those 2 would have difference clocks.

But a soundcard and the PC itself, shouldn't really be such a problem.
I am trying to see if there is a way to alter the PC clock, or QueryPerformanceFrequency, which seems to pretty much be the clock, to get it closer to the audio clock.
But i can't find anything about it.


But please try the filter in Graphedit/studio i posted, and write the result you get on Ref/QPC, i am very interested.

[StainlessS]

Something from MSDN:
http://msdn.microsoft.com/en-us/magazine/cc163996.aspx

[StainlessS]

I tried the showclock.ax in graphStudio (Graphedit crashed as soon as I clicked on "DirectShow Filters"),

On start, shows Ref/QPC ~ 0.9997xxxx, after ~ 200 seconds, crept up to 1.00000

[zerowalker]

So you get a stable 1?

Hmm mine seems to not get there.
I tried changing CPU Skew to delay 400, just to see if it changes anything, and i think it did.
I am currently at 0.999996 and going up, extremely slow though (9 min).
But perhaps it is random and hadn't anything to do with CPU Skew.

But thanks, at least you get 1, and that says something.

[StainlessS]

So you get a stable 1?

Yes, stable 1.0

Probably totally un-related but I just put in a brand new CMOS/RTC battery this morning.

(Got a batch of about 8 on a card, in the 99 pence shop, only last about 6 months each)

[zerowalker]

May be related, IF the timer depends on the RTC and the battery is bad.
I tried testing the battery by disabling internet time sync, to see if the time would go off.
And it didn´t for the time i tested, but i didn´t make a really thorough test, i will keep the battery in mind, thanks for the information.

[Ghitulescu]

Sadly that´s not the case.
I have gotten it down to that it´s the difference between the capture device clock and the audio clock that makes the sync problem.

Then you should have the same problems during playing ....

[zerowalker]

That's the weird thing i am trying to look closer at.
But there seems to be audio renderer that solved that by increasing the audio clock (or decreasing), so i guess the issue exist on playback aswell.
Though it's not the same for some reason, i guess the sync is a bit more loose or something.

Or maybe it is the software or method, i would love to be able to solve it or know the problem anyways.


And, i tried recording on another PC and let it run overnight.
I ran probably for about 10 hours i think, and it had desync issues aswell, though not as i did.
I didn't check, but i would guess the desync was a bit less then mine. Maybe 200-300ms at 10 hours.

[zerowalker]

Okay i have gotten a bit more knowledge, but it has made me quite interested in a thing.

It seems to work like this.

There is always a Video Clock and an Audio Clock.
If these to are not the same (which they never are, except if they are on the same device and created from the same source) they will be different.

So for example.

1:00:00 in the Video Clock could be 1:00:55 in the Audio Clock.

So the only way to solve this except using the same clock (which don't seem to be possible, it's hardware releated), is to sync the video to audio, or audio to video.

But here is the dilemma, it may sound good at first, i mean, sync one source to the other, and all is well, right?

But, which clock is correct?
Which is reality, which has the correct time based on reality (not going to deep, but which has 1 sec, that is 1 sec).

By looking at the video, and it say, the video duration is 2:00:00, then that should be correct in my eyes.
But if i sync it to the audio, then it would be 2:01:40 (an example).
Does that just mean that the Audio is wrong, and the clock goes to slow?

Or is the Audio correct, and the Video goes to fast?

I know it may sound like a science project now, but i don't care about, Oh the precision in Time Space blabla.

But hope you get what i mean with it. Cause as both aren't the same, one or both must be wrong if you compare it to Real time.
But i don't know well how Time works, but i only care about, well the Clock in my kitchen so to speak.

[Ghitulescu]

There will always be 4 clocks in a PC. One is the clock of the CPU. Another one is the RTC, already mentioned. The third one is the video clock, provided by the video card. The fourth one is the audio clock.
There is also the possibility that each clock be a plurality (for instance some older cards had a clock for each refresh rate, some audio cards had one for 48k another for 44k1, and so on).

[zerowalker]

Well for this case, there are only 2 clocks that matter, the Video Clock and the Audio Clock.
the rest doesn't seem to matter when capturing goes drift.

I am pretty sure my Audio card only goes with one clock, as different frequencies doesn't change anything.
Same with video card, resolution (and tiny difference with hertz, like 60,59.8 etc) doesn't seem to matter, atleast to recording.

But i would like to compare the clocks to reality if possible, cause i guess sitting and counting numbers doesn't yield much precision.

If i would have to guess, it would be that my Sound Card has more precision than the Video clock, but that's just a guess.

[IanB]

When capturing the video clock is from the video source, i.e. TV station, VCR, ...

Advance capture hardware also provides a synchronised audio clock to keep the two is sync.

Avery Lee has discussed this issue on his VirtualDub site blog (http://www.virtualdub.org/), Google for "video audio clock site:www.virtualdub.org (http://www.google.com.au/search?q=video+audio+clock+site:www.virtualdub.org)"