Floating point audio_samples_per_second

[IanB]

Dear all,

I would like to float the idea that Audio sampling rate be held internally in floating point format to minimise accumulated rounding errors.

When dealing with long .AVI files particularly with low sample rate audio (11025, 8000) it requires special tricks to avoid lip sync problems. The difficulty manifests itself as the integer rounding error accumulates over time. i.e. :-

A 1 unit diffference in a 11025/second audio stream over 1 Hour (3600 seconds) has an accumulated rounding error of 326.53 milliseconds, which is quite noticable (8KhZ has 450mS/Hour error). There are many tricks like tweaking the video rate or supersampling the audio to a very high rate on input, but resampling multiple times causes distortion and is best avoided.

The principle players AssumeFPS(sync_audio=true) and ResampleAudio() already use doubles internally for these calculations.

I have examined the source code and the changes required would be minimal apart from the evil public "int audio_samples_per_second;" in avisynth.h affecting all plugins already using that class member. Some tricky OO overlaying and new methods could avoid this but could make things a little messy.

Thoughts?

IanB

[Richard Berg]

I'm not sure I understand. So long as calculations are done in FP, where are the errors coming from? Isn't the actual sample rate always an integer?

[IanB]

Originally posted by Richard Berg
I'm not sure I understand. So long as calculations are done in FP, where are the errors coming from? Isn't the actual sample rate always an integer? After the accurate calculation is done to result is truncated and jammed into an integer. The next script statement now has rounded data. Consider the following script :-# NTSC 3:2 -> PAL 104%
AviSource("abc.avi", true, "YUY2") # 29.97fps/8000Hz
Telecide()
Decimate() # 23.976fps/8000Hz
AssumeFPS(25,1,True) # 25fps/8341.666666667Hz -> 8342Hz Now 144ms/Hour short
ResampleAudio(8000) # 25fps/8000Hz Opps! need 25.001fpsUnfortunatly .AVI format has no synchronization between Audio and Video other than the unreasonably precise relationship beween the respective sampling rates.

IanB

[sh0dan]

Precision in all other cases will suffer, since float point aren't exact. Hence:

integer 44100 != float 44100

So rounding errors will creep in many other places. It could be done after an API change (v. 3.0), but it isn't realistic in the 2.5 API.

[IanB]

Originally posted by sh0dan
Precision in all other cases will suffer, since float point aren't exact. Hence:

integer 44100 != float 44100

So rounding errors will creep in many other places. It could be done after an API change (v. 3.0), but it isn't realistic in the 2.5 API.I beg to differint i;
double a;

i = 44100;
a = i;For this case (i == int(a +0.5)) is always true

However, revisiting the issue, a better solution for when exact precision is required might be to calculate the exact audio rate based on the total number of audio samples and the total audio clip duration. The catch will be in the source filters don't deliver the exact audio duration, they assume the video duration.

IanB

P.S. Gee I'm dumb, the KISS solution is obvious. Allow the exact rescale ratio to be specified directly into the ResampleAudio() core.

[sh0dan]

That would probably be the best solution. That way we also don't run into problems when audio with fraction samplerates has to be delviered by AviSynth.

I'll submit it to sourceforge. (This is the only way for me to remember "minor" changes).