Samplerate and Sync.

[zerowalker]

Okay i am recording gameplays, and i get Desync overtime.
It seems to be the cause of some kind of sync clock between the sound and the CPU, i have 2 sound cards, 1 built in, 1 external.

Of both of them i get best results with the one built in.
Though i do get desync overtime, but it´s not delay, it´s the opposite, so in 5 hours of constant gameplay, the audio can be about 500ms earlier then the video.


Now i have "solved" this by manually adding DelayAudio(x.xx), but it´s not a good solution.

So now i started to think, isn´t there a way to make it go 500ms slower over 5 hours?

I don´t know how to calculate that, so i found a setting called AssumeSamplerate (tried playing with fps but it changed the video of course).

And if i use it to reduce the samplerate with 1, it´s pretty much in sync.

from 48000 to 47999.

Don´t know what changed there, but i guess it plays a small bit slower.

The problem is, i got a separate Intro, and i usually use SSRC() to get both of them into 48khz, but SSRC can´t change the samplerate of 47999 to that, so i have to reduce it to 44.1khz.


I normally don´t care about that becuase it´s not audible, but i want to know for learning reasons.

Is there a way to do what i am doing more properly?
Is there anything that´s wrong?

Thanks

[StainlessS]

I calculate sample rate for 0.5 delay over 5 hours (18000 secs) to be 0.999972222 of original
which at 48000 is 47998.66667 or about 47999 as you tried.

Suggest maybe

    AssumeSamplerate(47999)
    ResampleAudio(48000)

[zerowalker]

How did you calculate that?
This kind of calculation is not within my field if i say so;P

And yes i noticed that ResampleAudio works but SSRC doesn´t.
But SSRC is higher quality (atleast i read so).

But wondering, should i resample the to a standard samplerate, or should i resample the separate files to the 47999 samplerate?

[StainlessS]

((18000-0.5) / 18000.0) = 0.999972222

0.999972222 * 48000 = 47998.66667 ie 47999 would play about 0.5 secs longer.

Well, to lengthen the sample, you play 1 sample fewer per second so over 5 hours
the fewer played samples accumulate to about 0.5 and so plays longer (or later @ 5 hours)
but if you want to eg burn on DVD using standard samplerate then you have to resample
to be compatible. SSRC used be be a lot better than Resampleaudio, but not any more
http://forum.doom9.org/showthread.php?t=165321

SSRC is more restrictive in what rates it can convert and will often fail, it is also slower.

Suggest as posted in previous post, or if you want 44.1Khz then 44100 instead of 48000
in ResampleAudio().

You could also use TimeStretch filter, but over 5 hours, it may not work reliably (lack of precision).

[zerowalker]

Ah nice, learned some calculation, will go back many times for that one, i am really not that bright with math;P

Hmm as i understood SSRC was better thanks to the 32bit float, but now ResampleAudio has it aswell, so there isn´t really any difference, and SSRC has much more restrictions?

I am going for playback on PC, but this will go to youtube, which uses 44.1.

But what is the highest quality, or mostly intact to the originaly, resampling to 48khz (adding 1 samplerate), or downsampling to 44.1, or letting it stay at the Assumedsamplerate (i guess this one).
And is there a way to make AssumeSamplerate work with a more precise number (47998.66667)?

And another thing, as i understand, my sound is recording in about 1.3 samplerates to few each second, or something.
What is lost with that except losing some secs over a long time?

Is the audio Really slower?
As it doesn´t skip anywhere, so i can´t think of anything else then that it doesn´t follow the correct samplerate.

[StainlessS]

If you want to change the length then you need to do the AssumeSampleRate otherwise
the length will be wrong. After that, you choose whatever compatible rate you require.
If you dont resample, you could just play that on PC and be happy, so long as you dont want to
give it to YouTube or burn on DVD etc, you take your pick. If you want two different versions,
then convert to 44.1 for YouTube and decide what you want for yourself, 48 or 44.1khz would be
the better choice unless you just dont care. Which is best, well it probably does not matter too
much, as far as I know, adult humans can hear in the (roughly) 20hz to 20khz range (babies
probably a little higher, because they are smaller, and less damaged hearing over time). To
accurately represent 20khz you need double that, ie 40khz, so even CD 44.1 khz is a little
excessive to most needs, and DVD 48khz is well, un-necessary. Where high rates are good to have,
is in the studio where many transformations may be done, the higher sample rate keeps better
precision, but when editing and manipulation is complete, then 44.1 khz is probably quite sufficient.
I'm sure there are many here on D9 who would disagree, but they must have hearing that is out of
human range (I have long suspected that many of them have pointy ears).

[zerowalker]

I Will go with 47999 if there isn´t a way to be more precise.
And if youtube doesn´t downsample it, i will do it manually.

But what i don´t understand with the, humans hear 20 to 20k, is the thing with 44.1 and 48.
I understand that there is more precision from Analog to Digital with higher samplerate, and Bit depths and all that. But how come you can´t downsample from 40+ to 20khz, without it sounding like a radio, i thought we only heard till 20khz?

I guess it´s some technical thing and not constatly related to the human hearing samplerate estimation?

[StainlessS]

If you downsample 40khz+ to 20khz, then it can only accurately represent 20khz/2 = 10khz.
Hence the radio like sound. You need twice the sample rate.

[zerowalker]

Oh, why is that?
Why not just name it 10khz instead of 20 then?
Or am i missing something?

[librarian]

Originally Posted by StainlessS

... then 44.1 khz is probably quite sufficient...

I agree, for normal adults 40 y.o. limits are often 40 - 14.000 Hz.
On Youtube there are some tests:

http://www.youtube.com/watch?v=R0A72A-c8EU
http://www.youtube.com/watch?v=igGroIcga3g

I ignore their precision (it depends on your sound card too), but for a rough measure may be enough.

@ zerowalker

Nyquist Theorem

[cretindesalpes]

Doing listening tests on with Youtube videos or with any lossy-compressed sound seems to be a bad idea! Audio coders often apply a low-pass filter on the source before encoding to limit the content bandwidth explicitly.

Back to the topic, you should resample your sound instead of just setting its sampling rate to a value extremely close to a standard rate. Some players might round it to 48000 Hz, like video decoders sometimes do with 29.970000 fps they round to the exact ratio 30000/1001 = 29.970029970029... Convert it to 44.1 or 48 kHz, it doesn't matter much, especially if you want to upload it on YT where it will be compressed and damaged anyway.

[zerowalker]

Okay i have uploaded it for now, will see if it´s anything wrong with it.
And for the decoding, it says the correct samplerate (LAV Audio).

But still wondering, as StainleSS calculated, the samplerate is in float, but AssumeSamplerate only works in Int.
Is there a way to workaround this?
It´s not a Big issue, but it would be nice to sync it more precise.

[zerowalker]

I think i learned a way to workaround the Int restriction.

If i use this: AssumeFPS(29.99921630094044, sync_audio=true)
for example.

a = video.
b = video_audio.AssumeFPS(29.99921630094044, sync_audio=true)

a.Audiodub(video_audio)


Is there anything wrong with this?
Is it worse/better or identical to the use of Assumesamplerate?

[StainlessS]

Samples may be in float, but samplerate is ALWAYS in int.

Do as already suggested, you are just wasting your time.

EDIT: You are also giving yourself a messed up video frame rate to match a messed up audio rate.

[zerowalker]

Okay, but how am i wasting time, doesn´t the thing i wrote above work accurately?
Or is there something that´s bad with it?

And your suggestion, do you mean stay with a rounded number, or use timestretch?
Cause timestretch works pretty much as what i am trying to do i think?

[StainlessS]

AssumeSamplerate(47999)
ResampleAudio(48000)

See previous EDIT.

Timestretch at 5 hours would probably work but due to float precision and the maths it uses, it would
likely result in your only being able to adjust length in steps of maybe 0.5 seconds, maybe 1 second,
something like that. I've done it before and ended up spending a LOT of time to little good effect.
If you want to use timestretch, suggest cutting into several pieces and adjust them individually.
It might not be 5 hours, may be about 7 hours, but at some point the precision is insufficient
and is just not usable. Try it yourself, but dont ask me to help, I've already been there.

EDIT: If you do try Timestretch, cutting into pieces, then give yourself a few extra seconds on the
ends of EACH piece.

[zerowalker]

Yeah i know that, it worked very well, but it´s not precise with the samplerate thanks to Int.

And as you say that Timestretch is not the best piece of work i haven´t tried it, and don´t think i really want to.

But i want to know as i wrote before, is there a reason not to use this:

AssumeFPS(29.99921630094044, sync_audio=true)
And take that audio and put it in the same clip but with original 30fps.

That way i don´t have to resample, and i get to work with float numbers to get a more precise sync

[StainlessS]

sync_audio=true, resamples.

EDIT: Oops, no it doesn't its same as as AssumeSampleRate, but to match the new length
after ASsumeFPS.

If you want to use AssumeSampleRate, then why do it via the back door using AssumeFPS
for a clip that you will throw away anyway.

EDIT: You're going to give your self a headache.

[zerowalker]

It´s because AssumeSampleRate uses Int and can´t be precise.
AssumeFPS uses Float and can be as precise as the calculation is.

It´s not necessary for this stuff to be Perfect no, but it´s better to learn it if i need it in the future

[StainlessS]

I'm not altogether sure what it is that you have learnt.

From Avisynth source

int audio_samples_per_second;   // 0 means no audio

So no matter how you arrive at your destination, the sample rate is always going to be int.