Yes, the previous algorithm is "simple", which is a good thing. The difference is that it chooses the FFT size (N) in an optimal way, and derives the arbitrary segment length (L) accordingly. No zero-padding is necessary, so the claim "circular convolution used in it may be wrong, because we should pad zeroes in the head at initial step" is wrong and misleading. Your more-complicated algorithm, prioritizes the choice of L above the FFT size, P, (an important performance parameter). The claim that your inefficient and complicated code achieves the same result as conv(•) (as does the efficient, simple code) is not sufficient.
--Bob K (talk) 20:07, 5 March 2014 (UTC)
As can be seen in the Octave source code, the figure is generated using linear convolutions (Octave's conv() function). This just about totally defeats the whole point behind this algorithm, i.e. to use circular convolutions (since these can be efficiently implemented using FFTs). As far as I can see, the operation b = conv(a(Xa),h) should be replaced with:
H = fft([h, zeros(1, length(Xa)-M)]);
b = ifft(H .* fft(a(Xa)));
The results from this seem more sensible to me. Could anyone confirm this?
I believe that change would work. Also, a working example can be found at Discrete_Hilbert_transforms, if that's what you are looking for. In that example, the impulse response is zero-phase, because the result is subsequently compared to a non-FIR result, which is also zero-phase. Zero-phase means that the edge-effects are at both ends, instead of just the beginning.
But the change you propose does not match the description in the article, which breaks the whole thing down into two key concepts. Fully half of the main section, and all of the math, is devoted to the concept depicted in the figure, which is that of doing piece-wise convolution and creating a seamless result. It is easier to explain that without the unnecessary complexity of circular convolution. I think this is the only place in Wikipedia where it is found. The details of circular convolution are explained in another article, which is WikiLinked here.
The figure illustrating the overlap-save algorithm is misleading/wrong
the vertical axis labels indicate that the signals have an offset. The mean value seems to be 1. However, the convolution result itself indicates that the signals have zero-mean. Most likely the vertical axis is wrongly labeled. The labels should 0,1,2 should be replaced by -1,0,1.
the double arrow below the horizontal axis is misleading. The arrows should be removed or only the one pointing to the right should be shown
the length of the segments is not clear. From the caption it seems to 100 taps, but the red portion of the upper plot indicates a different length
it is not clear which part is overlapping from the previous segment
Plot #1 (top) is labeled "X[n], with segment k=3 in red". A similar label for plot #3 would be:
"Convolution of X3 and a lowpass filter, with Y3 shown in red. The non-red portions are the filter's discarded transient responses. Note that the rise-time response for Y1 (in plot #4) was not discarded, meaning that the filter is causal."
That's a bit long for a label... perhaps you would like to add it to the caption.
The vertical axes are all labeled correctly. I think that will be obvious to you, once you understand the rise and fall times.
The traditional algorithm name (Overlap-save) is not helpful. Overlap-discard would be more helpful. But we can't re-write history.