I was doing some precision work on the slices of my bass samples and discovered that zero crossing detection doesn’t work as I expected: every time I press the F5, it jumps to a different neighboring zero crossing, even if a valid zero-point was already detected!
For my work, I had to remove the clicky beginnings of my bass samples and adjust sample ends so that everything sounds nice and clean, always with zero crossings. But, as you may have already suspected, after adjusting the end point and clicking the F5, I discovered that the start point moved to a different position!
Maybe the snap is working correctly, but the graphical display is what is off a bit? Like maybe the display gain, or whatever algorithm draws the waveform, isn’t able to resolve that what you think should be a ZC isn’t quite? I’ve noticed it generally snaps to the nerest neighbor ZC, but if I’m zoomed in on that level already, then i don’t really need the ZC function at all I guess.
I don’t think the zero point detection has anything to do with how the waveform is drawn. The graphical display is rather secondary in this situation, it just shows what’s there.
The sequence of samples (= the sound wave) must be stored in a buffer as numbers and that’s where the search for zero crossing must be done.
I have no idea how naïve or sophisticated the algorithm is, but it looks to me that one thing is missing: if you are already at the zero crossing, don’t look for another one.
It feels to me that when the cursor is at position N, the machine looks for the next zero crossing to the left and to the right of N, in the ranges [0, N] and [N, max_length], then compares which point is closer to N and jumps to this position.
Maybe, instead, it should look in the ranges [0, N+1] and [N-1, max_length], or something like that?
@Mickey I know this solution is not well thought (and will not work for samples with consecutive zeros) but you get the idea.