0
$\begingroup$

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.

Improve this question
$\endgroup$
5
  • $\begingroup$ You seem to have the software that produces the numbers of samples that you've observed. Don't you have the source code? $\endgroup$
    – Matt L.
    Jun 25, 2020 at 10:19
  • $\begingroup$ @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. $\endgroup$
    – 0__
    Jun 25, 2020 at 11:05
  • $\begingroup$ 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. $\endgroup$
    – Matt L.
    Jun 25, 2020 at 11:29
  • $\begingroup$ Is your ramp linear in input time or in output time? It can be a ramp in both time domains $\endgroup$
    – Hilmar
    Jun 25, 2020 at 12:18
  • $\begingroup$ @Hilmar linear in output time, that's where the trouble comes from. (This I cannot change at the moment, and it's by design). $\endgroup$
    – 0__
    Jun 26, 2020 at 20:22

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.