Weird effect at end of resampled signal about resampy HOT 4 CLOSED

Thanks a lot, this looks much better :)

from resampy.

I think this is probably expected behavior given how short your input signals are, but I will look into it. (Your code example does reproduce the reported behavior on my environment.)

To get high quality reconstruction, the default filter (kaiser_best) uses a very long window to approximate a sinc filter. When you get to the end of the signal, the filter gets adaptively shortened to avoid running off the end of the input buffer, which results in the attenuation behavior that you reported above. You can see this by switching from kaiser_best to kaiser_fast, in which case the results look like:


(note that the edge effects occupy a much smaller portion of the signal). If you want even more control over this, you can call resampy(... filter='sinc_window', num_zeros=16); the num_zeros parameter controls the effective precision of the resampling filter, with larger values producing longer filters and better fidelity.

For typical audio signals, these edge effects should be negligible. ~100 samples at 22050 Hz would not be audible. Still, it's a bit strange that the beginning of the resampled signal does not exhibit these artifacts, since the filter is time-symmetric, so I'll look into it.

from resampy.

Update: this does indeed seem to be a bug, due to this line subtracting off the left-hand array bound when calculating the right-hand array bound. Removing that subtraction brings the boundary effects down to where I would expect them:

At this point though, I'm wondering if it makes more sense to calculate a symmetric array bound for time t so that each output sample always has an equal contributions from the left- and right- wings of the filter. I'll experiment with this and report back. Otherwise, I've flagged this issue for fixing in 0.2.1, which I hope to push in the next few days.

Thanks @bolau for reporting this!

from resampy.

Fix is merged, I'll push the bugfix release later today and it should appear on conda-forge shortly thereafter.

The fix as implemented is, I think, the correct thing to do if we assume the input signal is zero outside of the observations. More generally, I could imagine it being useful to support other edge modes, which might be useful depending on the assumptions you're willing to make about your signals. I've created a new issue #64 for that. I probably won't have time to implement that in the immediate future, but I'm happy to help any newcomers that want to work on it.

from resampy.