overlap-save vs. overlap-add

Why overlap-save algo applys more often than overlap-add?  What is its
advantage comparing with overlap-add?

HyeeWang

On 14 Okt, 10:40, HyeeWang <hyeew...@gmail.com> wrote:
> Why overlap-save algo applys more often than overlap-add? &#4294967295;What is its
> advantage comparing with overlap-add?

Don't know the two algorithms well enough to comment
on the specifics, but in general any of several reasons
might decide. There are the technical reasons, like

- One method has some superior advantage, like less
  computational complexity or less memory footprint
  in terms of auxillary variables etc.
- One method is simpler to understand and implement

But then there are the arbitrary reasons, like

- One method tends to be listed first in textbooks.
  People read till they find it, realizes it's what
  they need, and never bother to investigaet the other
- One method is already dominant among users. One very
  often wants to eliminate variables in investigations.
  For that reason, one tends to select the most popular
  methods for the standard tasks. "If you want to step
  off the beaten path, make sure you have a good reason."

Rune

For some reason overlap add seems to get mentioned more in text books
at least that's my impression. Overlap save is a bit easier to handle
and more efficient because you eliminate a bunch of adds. Except when
you want to partition your impulse response it all gets a bit tricky.

"Fully Half Baked" <jfezl07@googlemail.com> wrote in message 
news:3353030c-28d2-4ceb-a26a-88a1775cc0f2@f16g2000yqm.googlegroups.com...
> For some reason overlap add seems to get mentioned more in text books
> at least that's my impression. Overlap save is a bit easier to handle
> and more efficient because you eliminate a bunch of adds. Except when
> you want to partition your impulse response it all gets a bit tricky.

I've used zero padded overlap-save successfully in reverb convolutions; and 
overlap-add for vocoder applications, where the overlap is more than 2. 

>Why overlap-save algo applys more often than overlap-add?  What is its
>advantage comparing with overlap-add?
>
>HyeeWang
>

I've often wondered what the real difference was as well.  While I can see
the implementation difference, both algorithms are used for implementation
of fast convolution using STFT.  This is supposed to be more efficient when
a large number of filter taps are needed, such as in reverb effects where a
room's impulse response has been sampled.  The real question is, is there
any difference in output, or are both algorithms numerically equivalent to
convolution the conventional way?

Jacob

On Oct 14, 3:14=A0pm, "foxcob" <jacob.the...@gmail.com> wrote:
> >Why overlap-save algo applys more often than overlap-add? =A0What is its
> >advantage comparing with overlap-add?
>
> >HyeeWang
>
> I've often wondered what the real difference was as well. =A0While I can =
see
> the implementation difference, both algorithms are used for implementatio=
n
> of fast convolution using STFT. =A0This is supposed to be more efficient =
when
> a large number of filter taps are needed, such as in reverb effects where=
 a
> room's impulse response has been sampled. =A0The real question is, is the=
re
> any difference in output, or are both algorithms numerically equivalent t=
o
> convolution the conventional way?
>
> Jacob

Both algorithms are equivalent. Short of any differences in the result
based on finite precision (since the actual operations you're doing
are different, you might end up with different roundoff errors), you
will get the same answer.

Jason

On Wed, 14 Oct 2009 14:14:58 -0500, "foxcob" <jacob.thefox@gmail.com> wrote:

>The real question is, is there
>any difference in output, or are both algorithms numerically equivalent to
>convolution the conventional way?

Overlap and add is necessary if your filter is time-varying.

Greg

On Oct 14, 8:11=A0pm, "contact" <cont...@invalid.com> wrote:
> "Fully Half Baked" <jfez...@googlemail.com> wrote in messagenews:3353030c=
-28d2-4ceb-a26a-88a1775cc0f2@f16g2000yqm.googlegroups.com...
>
> > For some reason overlap add seems to get mentioned more in text books
> > at least that's my impression. Overlap save is a bit easier to handle
> > and more efficient because you eliminate a bunch of adds. Except when
> > you want to partition your impulse response it all gets a bit tricky.
>
> I've used zero padded overlap-save successfully in reverb convolutions; a=
nd
> overlap-add for vocoder applications, where the overlap is more than 2.

I tried this a few weeks ago but it wasn't obvious to me how to keep
overlap save with a partitioned impulse.
So tell us how you do it ;)

>"Fully Half Baked" <jfezl07@googlemail.com> wrote in message 
>news:6bbdcadc-67f4-4ab6-aa56-4254c08b2b54@g23g2000yqh.googlegroups.com...
>On Oct 14, 8:11 pm, "contact" <cont...@invalid.com> wrote:
>> "Fully Half Baked" <jfez...@googlemail.com> wrote in 
>> messagenews:3353030c-28d2-4ceb-a26a-88a1775cc0f2@f16g2000yqm.googlegroups.com...
>>
>> > For some reason overlap add seems to get mentioned more in text books
>> > at least that's my impression. Overlap save is a bit easier to handle
>> > and more efficient because you eliminate a bunch of adds. Except when
>> > you want to partition your impulse response it all gets a bit tricky.
>>
>> I've used zero padded overlap-save successfully in reverb convolutions; 
>> and
>> overlap-add for vocoder applications, where the overlap is more than 2.
>
>I tried this a few weeks ago but it wasn't obvious to me how to keep
>overlap save with a partitioned impulse.
>So tell us how you do it ;)

Try:-  http://tinyurl.com/yzl582h     ; )
I can basically remember converting the IR into FFT sections by placing the 
impulse signal on the left half with zeros on the right, stepping through 
the signal in half FFT length overlaps. Then when in the convolution loop 
(2X overlap) use the right half to save as the continuous signal. Something 
like that.

On Oct 16, 9:27=A0pm, "contact" <cont...@invalid.com> wrote:
> >"Fully Half Baked" <jfez...@googlemail.com> wrote in message
> >news:6bbdcadc-67f4-4ab6-aa56-4254c08b2b54@g23g2000yqh.googlegroups.com..=
.
> >On Oct 14, 8:11 pm, "contact" <cont...@invalid.com> wrote:
> >> "Fully Half Baked" <jfez...@googlemail.com> wrote in
> >> messagenews:3353030c-28d2-4ceb-a26a-88a1775cc0f2@f16g2000yqm.googlegro=
ups.com...
>
> >> > For some reason overlap add seems to get mentioned more in text book=
s
> >> > at least that's my impression. Overlap save is a bit easier to handl=
e
> >> > and more efficient because you eliminate a bunch of adds. Except whe=
n
> >> > you want to partition your impulse response it all gets a bit tricky=
.
>
> >> I've used zero padded overlap-save successfully in reverb convolutions=
;
> >> and
> >> overlap-add for vocoder applications, where the overlap is more than 2=
.
>
> >I tried this a few weeks ago but it wasn't obvious to me how to keep
> >overlap save with a partitioned impulse.
> >So tell us how you do it ;)
>
> Try:- =A0http://tinyurl.com/yzl582h=A0 =A0 ; )
> I can basically remember converting the IR into FFT sections by placing t=
he
> impulse signal on the left half with zeros on the right, stepping through
> the signal in half FFT length overlaps. Then when in the convolution loop
> (2X overlap) use the right half to save as the continuous signal. Somethi=
ng
> like that.

I'm pretty sure that I scraped the bottom of googles barrel at the
time but didn't find a single explanation of it. What you've explained
sounds just like overlap save but the problem came when the impulse
response was longer than the input buffer it wasn't obvious how to do
it so I ended up with overlap add. I probably just need to sit down
with it sometime and figure it out properly.