> Michel Rouzic wrote:
>
> > I'm convolving sounds, not images. Those are the spectrograms of these
> > signals. My convolution function apparently works, I just didn't know
> > how to deal with the result. Confusing thing tho is why does image 1
> > appear on the first part of image 3
>
> Have you tried convolving the stimulus with the inverse before passing
> the stimulus through a system? If the result isn't a one sample impulse
> then there is something wrong with your implementation. This should be
> your acid test that you have things right.
Oh crap, you had a good idea, it revealed that something is wrong
(basically the result of the convolution of the chirp by it's inverse
gives the same chirp plus another more silent chirp starting at the
middle of the signal). Explains why the beginning of the result of my
convolution started with the first signal in it as it shouldn't even
have been there. I'm tired of having broken convolution functions, I've
went through many last summer and at last I thought I had made one that
worked (it convolved signals with windowed-sinc functions perfectly
well tho, go figure). here's the code, in case you can figure out
what's wrong. I can't see what can be tho, I must have misunderstood
something about FFT convolution
I'm not including the dftfunction(), I know it works perfectly well.
it's based on FFTW 3's real to real interface
double *zeropad(double *s, int32_t nin, int32_t nout)
{
int32_t i;
double *h;
h=malloc (sizeof(double) * nout);
for (i=0; i<nin; i++)
h[i]=s[i];
for (i=nin; i<nout; i++)
h[i]=0;
return h;
}
double *fftconv(double *s1, int32_t n1, double *s2, int32_t n2, int32_t
*n3)
{
int32_t i, parity;
double *s3, *t, a, b, c, d;
*n3=n1+n2-1; //output signal length
parity=*n3 % 2;
s3=malloc (*n3 * sizeof(double));
s1=zeropad(s1, n1, *n3);
s2=zeropad(s2, n2, *n3);
dftfunction(s1, s1, *n3, 0, 0);
dftfunction(s2, s2, *n3, 0, 1);
s3[0]=s1[0]*s2[0]; //DC element
for (i=1; i<*n3/2+parity; i++)
{
a=s1[i];
b=s1[*n3-i];
c=s2[i];
d=s2[*n3-i];
s3[i]=a*c - b*d;
s3[*n3-i]=b*c + a*d;
}
if (parity==0)
s3[*n3/2]=s1[*n3/2] * s2[*n3/2];
free(s1);
free(s2);
dftfunction(s3, s3, *n3, 1, 1);
return s3;
}
Reply by Michel Rouzic●February 3, 20062006-02-03
Bob Cain wrote:
> Michel Rouzic wrote:
>
> >
> > I'm tempted to say that for some reason signal 1 was longer than signal
> > 2, don't know what to blame tho, I thought about blaming my ADC but
> > that would mean it plays and samples at about 44,085 Hz instead of
> > 44,100, idk if it's possible.
>
> Yes, I've seen that much deviation and more between generating and
> sampling devices. You should play by the rule that the same clock must
> generate the stimulus that samples the response.
Oh yeah wait I did a major error in claiming that it had to both play
and sample at 44,085 Hz, cuz if so then I actually couldn't tell. The
input sampling rate has to be different than the output, otherwise I
can't see any explanation. It think it could only do it if the two had
about 30 Hz of difference
> > For you to see how my small chirp looks like, here is a zoom on it
> > http://www.geocities.com/michel0528/chirp.jpg
>
> I've never tried generating a chirp and an inverse slightly different in
> length nor doing any kind of formal analysis of what one would get but a
> small chirp instead of an impulse intuitively seems to be a good
> possibility.
>
> > You can see clearly that it does look as a small chirp. The only
> > explanation I can see is that the output signal was longer than the
> > input signal, and that thus I should do one further convolution by a
> > chirp to bring that small chirp vertical.
>
> Dunno how that could be made to work even if it could be. I'd make sure
> the generating D/A clock was the same one as the sampling A/D clock.
> I.e. same sound card on the same computer with its clock being
> internally generated. Working with a stimulus and response that don't
> use a common time base is pretty much out of bounds.
>
> There was a DX plugin from Sound Forge once upon a time called Acoustic
> Modeler which allowed asynchronous operation. Somehow it was able to
> very accurately determine the relative clock rate of the response
> sampling clock and analytically generated the inverse stimulus at that
> rate before doing the convolution. The implementor was closed mouth
> about how that rate determination was done (possibly by first generating
> a little chirp the way you have and adjusting the inverse rate based on
> its length for a second pass.)
>
>
> Bob
> --
>
> "Things should be described as simply as possible, but no simpler."
>
> A. Einstein
Reply by Bob Cain●February 3, 20062006-02-03
Michel Rouzic wrote:
> I'm convolving sounds, not images. Those are the spectrograms of these
> signals. My convolution function apparently works, I just didn't know
> how to deal with the result. Confusing thing tho is why does image 1
> appear on the first part of image 3
Have you tried convolving the stimulus with the inverse before passing
the stimulus through a system? If the result isn't a one sample impulse
then there is something wrong with your implementation. This should be
your acid test that you have things right.
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
Reply by Bob Cain●February 3, 20062006-02-03
Michel Rouzic wrote:
>
> I'm tempted to say that for some reason signal 1 was longer than signal
> 2, don't know what to blame tho, I thought about blaming my ADC but
> that would mean it plays and samples at about 44,085 Hz instead of
> 44,100, idk if it's possible.
Yes, I've seen that much deviation and more between generating and
sampling devices. You should play by the rule that the same clock must
generate the stimulus that samples the response.
I've never tried generating a chirp and an inverse slightly different in
length nor doing any kind of formal analysis of what one would get but a
small chirp instead of an impulse intuitively seems to be a good
possibility.
> You can see clearly that it does look as a small chirp. The only
> explanation I can see is that the output signal was longer than the
> input signal, and that thus I should do one further convolution by a
> chirp to bring that small chirp vertical.
Dunno how that could be made to work even if it could be. I'd make sure
the generating D/A clock was the same one as the sampling A/D clock.
I.e. same sound card on the same computer with its clock being
internally generated. Working with a stimulus and response that don't
use a common time base is pretty much out of bounds.
There was a DX plugin from Sound Forge once upon a time called Acoustic
Modeler which allowed asynchronous operation. Somehow it was able to
very accurately determine the relative clock rate of the response
sampling clock and analytically generated the inverse stimulus at that
rate before doing the convolution. The implementor was closed mouth
about how that rate determination was done (possibly by first generating
a little chirp the way you have and adjusting the inverse rate based on
its length for a second pass.)
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
Reply by Michel Rouzic●February 3, 20062006-02-03
Mike Yarwood wrote:
> "Michel Rouzic" <Michel0528@yahoo.fr> wrote in message
> news:1138711496.407992.178200@f14g2000cwb.googlegroups.com...
> >
> >> <prune>
> >
> > I understood something about convolving with a chirp, it just displaces
> > each band of frequency differently. Here, it's in order to bring a
> > chirp vertical.
> I'm tempted to say that I disagree completely but I still don't know what
> you mean by 'bring a chirp vertical' so all I can say is I strongly doubt
> it.
>
> > It actually does it, but I had yet to normalize my
> > result signal to see that the kinda of delta function was there
> > (actually more like a shortened chirp, due to the fact that my first
> > chirp is 0.066% longer than my second one).
> It's normal that your second chirp is longer than the original as it
> is(hopefully) just the superposition of a lot of copies of your original
> chirp with different relative delays and amplitudes.
> When you convolve these with the time reversed replica of your transmitted
> original chirp you should see a wiggly line representing the amplitude of
> all of those echoes/different delay paths, neatly separated out to within
> the resolution of your pulse compression scheme + more ripply stuff due to
> edge effects. If you are really seeing something that looks like a chirp
> near where you expect your echo reponse to be then I suspect that you have a
> lot of dispersion in your system or some substantial non-linearities or
> both.
I'm tempted to say that for some reason signal 1 was longer than signal
2, don't know what to blame tho, I thought about blaming my ADC but
that would mean it plays and samples at about 44,085 Hz instead of
44,100, idk if it's possible.
For you to see how my small chirp looks like, here is a zoom on it
http://www.geocities.com/michel0528/chirp.jpg
You can see clearly that it does look as a small chirp. The only
explanation I can see is that the output signal was longer than the
input signal, and that thus I should do one further convolution by a
chirp to bring that small chirp vertical.
Reply by Michel Rouzic●February 3, 20062006-02-03
Matt Timmermans wrote:
> "Michel Rouzic" <Michel0528@yahoo.fr> wrote in message
> news:1138502806.658790.269740@g47g2000cwa.googlegroups.com...
> > Since an image is word ten thousand words, here's what sums up what i'm
> > trying to do http://www.geocities.com/michel0528/correlation.jpg
>
> It looks like:
>
> - You're trying to do a bunch of 1D convolutions instead of a 2D
> convolution;
Only one 1D convolution
> - Your 3rd image has twice the resolution on the X axis, and you rescaled it
> without telling us; and
yeah, oops
> - Your convolution function is broken. Image 3 looks like the image 2
> convolved row-by-row with something like the background noise from image 1,
> and then added to image 1. Perhaps you got some buffers mixed up?
I'm convolving sounds, not images. Those are the spectrograms of these
signals. My convolution function apparently works, I just didn't know
how to deal with the result. Confusing thing tho is why does image 1
appear on the first part of image 3
Reply by Matt Timmermans●February 1, 20062006-02-01
"Michel Rouzic" <Michel0528@yahoo.fr> wrote in message
news:1138502806.658790.269740@g47g2000cwa.googlegroups.com...
It looks like:
- You're trying to do a bunch of 1D convolutions instead of a 2D
convolution;
- Your 3rd image has twice the resolution on the X axis, and you rescaled it
without telling us; and
- Your convolution function is broken. Image 3 looks like the image 2
convolved row-by-row with something like the background noise from image 1,
and then added to image 1. Perhaps you got some buffers mixed up?
--
Matt
Reply by Mike Yarwood●January 31, 20062006-01-31
"Michel Rouzic" <Michel0528@yahoo.fr> wrote in message
news:1138711496.407992.178200@f14g2000cwb.googlegroups.com...
>
>> <prune>
>
> I understood something about convolving with a chirp, it just displaces
> each band of frequency differently. Here, it's in order to bring a
> chirp vertical.
I'm tempted to say that I disagree completely but I still don't know what
you mean by 'bring a chirp vertical' so all I can say is I strongly doubt
it.
> It actually does it, but I had yet to normalize my
> result signal to see that the kinda of delta function was there
> (actually more like a shortened chirp, due to the fact that my first
> chirp is 0.066% longer than my second one).
It's normal that your second chirp is longer than the original as it
is(hopefully) just the superposition of a lot of copies of your original
chirp with different relative delays and amplitudes.
When you convolve these with the time reversed replica of your transmitted
original chirp you should see a wiggly line representing the amplitude of
all of those echoes/different delay paths, neatly separated out to within
the resolution of your pulse compression scheme + more ripply stuff due to
edge effects. If you are really seeing something that looks like a chirp
near where you expect your echo reponse to be then I suspect that you have a
lot of dispersion in your system or some substantial non-linearities or
both.
>The rest of what you can
> see is the noise of the first signal inclined according to the
> inclination of the second chirp
>
Best of Luck - Mike
Reply by Michel Rouzic●January 31, 20062006-01-31
Mike Yarwood wrote:
> "Michel Rouzic" <Michel0528@yahoo.fr> wrote in message
> news:1138579611.652105.276500@g47g2000cwa.googlegroups.com...
> >
> <prune>
> > I'm not sure I got what you meant... Frequency is axis Y. Just like for
> > any other spectrogram.
>
> But when you convolve the original chirp with your time reversed sequence
> of received samples you just get one long string of real numbers which is
> the impulse response , one value for each time step. How can that can
> translate into the many values per timestep I see in your final spectrogram?
I understood something about convolving with a chirp, it just displaces
each band of frequency differently. Here, it's in order to bring a
chirp vertical. It actually does it, but I had yet to normalize my
result signal to see that the kinda of delta function was there
(actually more like a shortened chirp, due to the fact that my first
chirp is 0.066% longer than my second one). The rest of what you can
see is the noise of the first signal inclined according to the
inclination of the second chirp
> In the earlier spectrograms (of the chirp and the return) I assume that your
> display program took your original long chirp and chopped it into a set of
> (possibly overlapping) shorter windows so that it could calculate the
> spectrum over a short interval of chirp and display as a vertical line of
> pixels, spectral estimate for next window goes in the next line of pixels
> etc. , if the chirp frequency doesn't change much during the window length
> then you get a fairly good peak and a nice thin straight line on the
> spectrogram - if it's doing the same thing with the channel impulse response
> I don't see how you will be able to make any sense of it at all.
The problem was that the final signal is so big (almost 20 million bins
I think) that the spectrogram display program made the almost
continuous 6400 bins long line almost disappear. But it's there.
Reply by Michel Rouzic●January 31, 20062006-01-31
Andreas Schwarz wrote:
> Michel Rouzic schrieb:
> > Andreas Schwarz wrote:
> >
> >>Michel Rouzic schrieb:
> >>
> >>>Since an image is word ten thousand words, here's what sums up what i'm
> >>>trying to do http://www.geocities.com/michel0528/correlation.jpg
> >>>
> >>>As you can see, I'm trying to correlate the first signal by the second
> >>>by correlation. The problem is, I didn't really expect the result you
> >>>can see on the picture, I expected more something looking like from not
> >>>too close like a delta function right in the middle.
> >>
> >>Take a look at the result in the time domain, and you will see a delta
> >>function. It looks that way in a spectrogram, your convolution function
> >>is working correctly.
> >
> >
> > Oh yeah damn, i'm feeling dumb for not having noticed that. My result
> > is stored on floats and as you can see by the magnitude it was too big
> > for me to see that.
> >
> > However, what do I do with my result?
>
> Depends on what you *want* to do.
>
> > The "delta function" I got isn't
> > even really a delta function, but a 6400 bins chirp, surrounded by all
> > the noise you can see.
>
> As I wrote above, forget the spectrogram, it's making things much more
> complicated than they are. Take a look at your convolution result in the
> time domain. I'm sure you will see a pretty sharp peak at the center.
> Try to shift one of the input signals and look at the result again, you
> will see the peak shifted too, etc.
>
> > Do I keep only the 6400 bins of interest? Do I
> > convolve that one little chirp with another to make it at last
> > straight? Why isn't it even straight in the first place?? Does it mean
> > that the recorded chirp lasted about 0.066% longer that the original
> > one for some reason?
>
> Sorry, I don't understand. Why don't you post a more detailed
> description of what you are trying to accomplish and what you have tried
> so far?
Sure. I have a linear system. I send the second signal (reversed)
through this system and obtain the first signal. What I am trying to do
here is to get rid of the surrounding noise in the first signal. To do
so, someone told me to cross-correlate the two signals in order to get
a delta function representing the frequency response of the linear
system i am trying to study.
However, the result is not exactly a delta function, but a 6400 bins
long chirp, surely due to the fact that for some reason the first
signal was 0.066% longer than the second. So that's why I think I
should convolve it again with another 6400 bins long chirp to make it
at last straight vertical.
The next question is how to get rid of the noise. My guess is that I
should only keep the highest bin and a few hundreds or thousands of
surrounding bins, and maybe eventually window them, in order to get a
proper impulse response of my linear system, without the noise. What do
you think about that?