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]

... 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.

[IanB]

Yes the audio sample rate property is an integer! So you cannot get the exact change in rate that you need. This does become more relevant the longer a clip becomes.

The difference between 48000 and 48001 becomes 200 milliseconds, considered a just noticeable offset, after about 2.6 hours.

Fortunately the ResampleAudio() filter has an optional new_rate_denominator argument which allows the internal workings of the filter to do extremely precise adjustment of the total audio length.
ResampleAudio(clip, int new_rate_numerator [, int new_rate_denominator])

ResampleAudio performs a high-quality change of audio sample rate. The conversion is skipped if the samplerate is already at the given rate.

When using fractional resampling the output audio samplerate is given by :

int(new_rate_numerator / new_rate_denominator + 0.5)

However the internally the resampling factor used is :

new_rate_numerator / (new_rate_denominator * old_sample_rate)

This causes the audio duration to vary slightly (which is generally what is desired). ... (http://avisynth.org/mediawiki/ResampleAudio)
Using it is a little bit barse-ackwards. You apply a precise correction as a rational pair, then you force the final sample rate back as it should be.
...
AdjustNumerator=36001 # 100ms per hour
AdjustDenominator=36000
Ar = Audiorate()
ResampleAudio(Ar*AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate
It's been a while since I last did this, so I may have the ratio reversed. Add the Info() filter to check the total audio duration and adjust the script accordingly.

[StainlessS]

Ooooo, thats a bit sneaky, one for my docs collection.

EDIT: Perhaps this might be a good candidate for some extra docs.

[zerowalker]

Oh that new_rate_numerator seems to be what i want, i read about it in wiki but didn´t know what it was or what it was used for.
But this seems to be what i may be looking for:)

But still wondering, how does
Assumesamplerate compare to AssumeFPS?

a=AVISource("Z:\w.avi")
b=AVISource("Z:\w.avi").AssumeFPS(29.99921630094044, sync_audio=true)

v1 = a.AudioDub(b)

vs

AdjustNumerator=36001 # 100ms per hour
AdjustDenominator=36000
Ar = Audiorate()
ResampleAudio(Ar*AdjustNumerator, AdjustDenominator) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate


(they aren´t both 100ms per hour though*)

[IanB]

@StainlessS,

Improved doco, yes always ;)

@zerowalker,

As I said,Yes the audio sample rate property is an integer!so the AudioRate can only ever be the nearest integer value. Compare the calculation used in the core code used to arrive at the value with what we have been calculating in the posts above (note: the numerator and denominator values are intelligently extract from the input float value) :-AssumeFPS::AssumeFPS(PClip _child, unsigned numerator, unsigned denominator, bool sync_audio, IScriptEnvironment* env)
: GenericVideoFilter(_child)
{
if (denominator == 0)
env->ThrowError("AssumeFPS: Denominator cannot be 0 (zero).");

if (sync_audio)
{
__int64 a = __int64(vi.fps_numerator) * denominator;
__int64 b = __int64(vi.fps_denominator) * numerator;
vi.audio_samples_per_second = int((vi.audio_samples_per_second * b + (a>>1)) / a);
}
vi.SetFPS(numerator, denominator);
}AssumeRate::AssumeRate(PClip _clip, int _rate)
: GenericVideoFilter(_clip) {
if (_rate < 0)
_rate = 0;
if (vi.SamplesPerSecond() == 0) // Don't add audio if none is present.
_rate = 0;

vi.audio_samples_per_second = _rate;
}

Assuming the input clip is 30000/1001 NTSC, AssumeFPS() speeds the audio (makes it shorter) by 1.000973850574712681333, so a 48000 input becomes 48047. About 3.5 seconds per hour. Which does not gel with what you were asking for so I have to infer the input clip is not actually 30000/1001.

The script I gave with the 36001/36000 values slows the audio (makes it longer) by 100ms per hour. Which is what you asked for in the 1st post.

:Edit: The 29.99921630094044 resolves to 38249/1275 which is approximately 29.999215686274509803921568627451

[zerowalker]

Can you tell more how to calculate, let´s say 133ms per hour etc?

And with the 29.99921630094044, it was a calculation to play the 30fps clip a small bit slower. but it seems in the end it became 47999, as you said it took the nearest Int i guess.

i as you said want to make it a bit slower, and i will use the captures i got with 5 hours straight as with that amount i should be able to get a very precise sync done with about anything compared to a 30min clip right?

[IanB]

Milliseconds per hour is 60 mins per hour * 60 secs per min * 1000 ms per sec = 3600000

So slow by 133ms per hour use :-AdjustNumerator=3600000+133 # 133ms per hour
AdjustDenominator=3600000And of course to speed up by 133ms per hour would be 3600000-133

[zerowalker]

Ah easy enough thanks:)!

[zerowalker]

It doesn´t work if i use more numbers than (36000) meaning miliseconds can´t be used;S

[IanB]

Oops yes the product of Ar*AdjustNumerator has to fit in a signed 32 integer, max value 2147483647, so 44739 is the max AdjustNumerator for 48000 audio rate.

3600133/3600000=1.0000369444...

Reducing this ratio with continues fractions at the limit of 44739 gives

27069/27068=1.00003694399 or 132.99837 milliseconds per hour
...
AdjustNumerator=3600133 # 133ms per hour
AdjustDenominator=3600000
Ar = Audiorate()

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

ResampleAudio(Ar*Num, Den) # Fine tune duration
AssumeSampleRate(Ar) # Put back sample rate

[zerowalker]

i don´t get any sound when i use that?
Do you get sound?

[IanB]

Yes, it works same as the original script, As it should, the numerator and denominator have just been scaled. Add an Info() call to the end of the script to make sure weird numbers are not happening. Try ColorBars() as a test source to dispel any source considerations.

[zerowalker]

got it to work i think:)

will this be 89.2 ms per hour?

AdjustNumerator=36000892
AdjustDenominator=36000000

thanks:)

[IanB]

36000892/10000-3600=0.0892 => 89.2, so yes ;)

[zerowalker]

It freezes if i use some other numbers, for example 62.5ms = 625 instead of 892, it has something to do with the Limit, though i don´t know what.

[IanB]

For Ar=48000Hz you get Limit=44739 which results in Num=44740, Den=44739,

48000*44740=2147520000 which is greater than the max value 2147483647, so you end up flipping a negative result.

Also 44740/44739 actually gives 80.466 milliseconds per hour, not the 62.5 you want. Lowering limit to avoid the overflow will make this worse.

You are running out of the available precision.

You could scale the AudioRate to crib a bit more precision but the current version of ResampleAudio also tests that the input AudioRate and the output AudioRate are actually different. If they are not then it does nothing. I have just committed a change to CVS that now tests the num_audio_samples instead, but that will not help you until a build is available.

This will get you very close at 62.4ms, with Limit=74565, Num=57693 and Den=57692...
AdjustNumerator = 36000625
AdjustDenominator = 36000000
XAr = 28800 # Lowest rate that supports 62.5ms/hour

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

Ar = Audiorate()
AssumeSampleRate(XAr) # Scale to crib a bit more precision
ResampleAudio(XAr*Num, Den) # Fine tune duration
AssumeSampleRate(Ar) # Put back original sample rateAdd this to you script as required to help you see what is happening.Return SubTitle(String(Num)+" "+String(Den)+" "+String(Limit))
With a build that includes the above mentioned fix the following will be possible :-...
AdjustNumerator= 36000625
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

[zerowalker]

Didn´t get everything with the numbers there, but i somewhat understand that there is a limit to how precise it can be thanks to many things.

Where do i look for the build, it´s very nice of you to commit a fix/tweak to it or what you all it so fast when you saw the "limits" or what it is!

Will do the code that you says work with the current build, and i think it´s somewhere around 60-70ms, it seems to be 62.5 but it´s hard to listen as i don´t know when exactly the sound is supposed to come so i have to guess more or less:)

But 10-20 ms here and there over some hours isn´t anything to worry about, it´s 50ms+ or - that´s noticeably if you ask me:)

As always thanks!

[zerowalker]

Does anyone know of a game or something, that has a very easy way to predict sound?

Like a flashing light that sounds exactly when it´s bright, or something?

As with games where you shoot, the sound doesn´t come Exactly when it´s fired, but some frames later depending on game of course.

Very Appreciated if anyone knows, it can be anything, just that it´s rendered somehow, even a clip will do i think:)

[StainlessS]

Just a suggestion if you want this for test purposes,
why not knock up test clip yourself, with maybe a grey blankclip with silence
and trim/splice in a white blankclip with tone as the test.
Maybe an integer FPS, perhaps even 1 FPS would do.

[zerowalker]

ah very true, will make a clip with AVS if i can (tip would be nice).
Will let it runt when i sleep so it will be like 8 hours or more hopefully.

EDIT:

Okay even if i had a clip that make a tone and change color, it won´t be precise when i record it´s playback, as it doesn´t record it Exact as it playsback, so i can´t look at the waveform and the video;S

Anyone have any ideas how it can be done?


EDIT 2:

please take a look at this and try to sync it with AudioGraph in avisynth, i can´t make it work for the entire clip.

http://www.sendspace.com/file/3sh7wm

[zerowalker]

Okay have to bring this up again.

I noticed that ResampleAudio gives alot of noise when converting from 47999 to 48000, and i can´t use the script above.
As it doesn´t seem to work, no matter what i write, it will still be the same lenght and delay.

EDIT:

It seems that the problem lies with how it works in the audio bit.
Cause if i "ConvertAudiotoFloat()" right before ResampleAudio(48000) the noise goes away.

[IanB]

What exactly is the added noise like?

What type of audio are you working with?

I am not sure exactly what you are saying, but the 16 bit path in ResampleAudio has it's problems, it always has. This is why SSRC was originally added and a sFloat code path later added. This script shows an issue with lack of precision :- ColorBars()
AmplifydB(-60.0)
ConvertAudioTo16Bit()
AssumeSampleRate(47999)
ResampleAudio(48000)
AmplifydB(57.0)The added buzz is quite substantial but then -60dB (1000 times) is a pretty low level, resulting in only ~5 bits resolution. For most medium quality audio in the -40 to -20 dB range the result are usually satisfactory. If you need better quality then using the sFloat path or SSRC is usually the answer.

[zerowalker]

The noise is, Hiss like.

And the audio is. Well don´t know what it´s called, but not Real Music, Gameboy SNES etc sound, i know it´s called something.

I understand that 16 bit has it´s problems, but doesn´t ResampleAudio work like SSRC now?
I remember that it was bad before, but they fixed it, by making it work in float, or something.

But as i can see, it doesn´t work in float, as if i Convert to float before the resample, and after convert it to 16 bit, it hiss isn´t there.
But that doesn´t really sound like an optimal way, but then again, i am not that good at this stuff.

If you need a sample, i will gladly provide it.

[Gavino]

I understand that 16 bit has it´s problems, but doesn´t ResampleAudio work like SSRC now?
I remember that it was bad before, but they fixed it, by making it work in float, or something.

But as i can see, it doesn´t work in float, as if i Convert to float before the resample, and after convert it to 16 bit, it hiss isn´t there.
ResampleAudio has two modes of working: 16 bit and floating point.
If you give it 16 bit, it will continue to work in 16 bit.
If you give it anything else, it works in float.

So if you are starting with 16 bit, you need to convert explicitly to float before calling ResampleAudio, if you want it to work in float mode.

[zerowalker]

I see, But.
What is good to do?
I mean, if i use for example, Virtualdubs Samplerate converter, at High Quality (haven´t tried without). I don´t get the hiss.

I don´t know how this resampling thing works, i just want best quality. Lossless if possible, but that isn´t i guess.

[IanB]

Resampling audio involves interpolating output samples from a collection of input samples. How you select and manipulate the input samples determines the faithfulness to the original that the output represents.

The very crudest interpolation would be a simple linear interpolation of the output sample from the 2 adjacent input samples weighted by the relative distance of the input position from the output position. So if going from 9 samples per interval to 10 samples per interval to generate output sample 5 we calculate this maps to input position 4.5 so we would take 0.5 of input sample 4 and add 0.5 of input sample 5. The other output samples would be similarly calculated based on their relative position to the input samples.

Even for simple sine wave input samples such a crude interpolation results in a noticeable amount of error. This error results in noise. So practical resamplers involve considerably more complex calculations, utilising 100's or even 1000's of input samples to generate each output sample.

The 16 bit code path uses uses 16 bit samples multiplied by 16 bit filter coefficients, accumulating 32 bit intermediate results. The interpolation position uses 24.8 fixed point arithmetic. All these compromises allow for a very fast implementation but result in small errors against the intended calculation. The original algorithm was intended for real time processing on a 80386 cpu. The accumulated error presents as noise.

If the 16 bit code path is not of sufficient quality use the sFloat code path, it may be slower but it is still many many times faster than real time on modern cpu's. The 16bit to sFloat back to 16bit is lossless.

[zerowalker]

How do i make it use sfloat?
Do i just convert it to float and then 16 bit after then resampling?
Or is it a way to make the resampling do it internally?

Thanks

[IanB]

Yes you explicitly convert to float.

You don't need to convert it back, the avi output layer will automatically convert it to 16 bit. It may actually be beneficial to convert to 24 bit if the output work flow can use it.

[zerowalker]

The original sound is at 16 bit, so shouldn´t i convert it to that?

But if i don´t convert, then it will still get converted, as it can´t stay Float i presume?
What will it get converted to?


And the end result will be 16 bit, (AAC or other lossy), would it still be beneficial to convert to 24 bit even if the source is 16 bit cause of the float resampling?

[IanB]

Once you process an audio stream at high bit depth, you should leave it in high bit depth format for the rest of the work flow. This minimises accumulating quantisation errors, e.g. if you simply amplify a stream by 3db a 16 bit input sample of value 1234 wants to become 1743.0713 and a value of 4321 want to become 6103.5747. Staying with 16 bit these 2 samples become 1743 and 6104. So the relationship between the values changes slightly what originally was a ratio of 3.5016207 becomes 3.5020080 the error is very small but if you keep performing this rounding it does eventually effect the sound.

By default the avi output layer will automatically convert float to 16 bit. The avisynth option "global OPT_AllowFloatAudio=True" can be used to control this behaviour if your work flow can actually accept IEEE floating point audio format. You can also explicitly ConvertAudioTo24Bit() or ConvertAudioTo32Bit() if your work flow can use those formats.

In most cases this does not matter, the background noise already present in the recording totally swamps all these considerations. You are experiencing a case where the additional noised caused by insufficient precision in the processing calculations adds noticeable extra noise.

If you want to know more about this issue, google for "audio noise shaping (http://www.google.com/search?q=audio+noise+shaping)"

[zerowalker]

Ah i see, or well, it´s a bit complicated. But i think i got a hold of it.

And currently this is my script:

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"))
ConvertAudioTo16bit()

A bit excessive maybe, but i am currently amplifying the clip that has wrong speed, right after i fix it, and before changing it to float for resampling.
The clip(intro) isn´t anything wrong with, so i just amplify it after float, and later resamples it to 48000 (it´s 44100).

And at the end i convert it to 16 bit. (I trim it after i convert it, but that shouldn´t affect anything).

And when i have listened to it. The wrong speed Clip, sound the same after this. well a bit slower, but it´s inaudible as it´s so slow. But i can´t hear any noise getting added, just the original noise that´s their. Proably cause of it being made in 16 bit from an Emulator, or maybe it´s within the sound, but i doubt it. (It´s midi like sound effects pretty much.)


But i think that as i can´t notice any difference, i will stay with 16 bit at the end. As i won´t make any more changes to the audio after that anyway, except encoding it.