# Resampling with factor linearly moving from one value to another: calculate expected target length

I am resampling an audio (1D) signal, using a resampling factor that moves linearly from startFactor to endFactor; say the input signal has a length of 4194304 sample frames, and startFactor is 1.0 and endFactor is 4.0, for example. Since the DSP blocks reads the resampling factors from a signal (here a linear ramp) at one sample per resampled output sample, I need to know the target length in advance to generate a linear movement.

My first intuition was that this is the geometric mean of startFactor and endFactor, but that is unfortunately not the case. For the given example values, that would be 2.0, and my ramp would move from startFactor to endFactor over 8388608 frames. However, the resulting output "overshoots" and the target is 9656320 sample frames instead (+15%). Likewise, if I change endFactor to 0.25, the geometric idea would estimate the target to have length 2097152, but the actual length is 2176638 (+4% overshoot).

Those discrepancies tell me it's not just floating point noise, but the formula has to be different.

I know I can calculate the target length by integrating the factor signal, but I need the target length to create the factor signal, so it's a catch-22.

I can also iterate to "find" the value, but I need an analytical solution. For example, the correct length factor for 1.0 and 4.0 is ca. 2.16356, so that both the ramp and target signal have length 9074628. For 1.0 and 2.0 the length factor is ca. 1.44236, for 1.0 and 0.5, the length factor is ca. 0.721344, and for 1.0 and 0.25, the length factor is ca. 0.541011.

• You seem to have the software that produces the numbers of samples that you've observed. Don't you have the source code? – Matt L. Jun 25 '20 at 10:19
• @MattL. Yes, it's my software, I wrote it. As stated, the resampling takes a factor signal that provides one resampling factor value per resampled output sample. There is nothing wrong with that piece as far as I can see. Obviously, a ramp from 0.25 to 4.0 does thus not produce the same duration as a ramp from 4.0 to 0.25, because of the skewing of the ramp. – 0__ Jun 25 '20 at 11:05
• OK, but you seem to be surprised at the number of output samples, given certain values for startFactor and endFactor. If you know what your code does, I don't understand why you can't exactly predict the number of output samples. – Matt L. Jun 25 '20 at 11:29
• Is your ramp linear in input time or in output time? It can be a ramp in both time domains – Hilmar Jun 25 '20 at 12:18
• @Hilmar linear in output time, that's where the trouble comes from. (This I cannot change at the moment, and it's by design). – 0__ Jun 26 '20 at 20:22