cross correlation sound

>On Sep 5, 7:51=A0am, "maz_p5" <maz...@hotmail.com> wrote:
>> >On Sep 5, 5:21=3DA0am, "maz_p5" <maz...@hotmail.com> wrote:
>> >> >On Sep 5, 12:53=3D3DA0am, kevinjmc...@netscape.net wrote:
>> >> >> m2 is later than m1, so it's the same as you had before with y
>> later
>> >> >> than x. =3D3DA0So the peak should be interpreted as occurring on
th=
>e
>> lef=3D
>> >t
>> >> or
>> >> >> lower half of your results. =3D3DA0Treat the first N-1 output
point=
>s
>> as
>> >> the
>> >> >> left side results (waveform y later than waveform x), the N
point
>> as
>> >> >> being the zero delay point and the second N-1 output points as
the
>> >> >> right side (waveform x later than waveform y). =3D3DA0You should
ha=
>ve
>> 2N=3D
>> > -
>> >> 2
>> >> >> outputs. =3D3DA0So if the delay shows up in the first or lower
half=
> of
>> t=3D
>> >he
>> >> >> results, then your delay is the distance (in number of samples)
>> >> >> between the zero delay point (point N, or the exact middle of
your
>> >> >> total number of points) and the peak to its left ( delay =3D3D3D
N
>> minus
>> >> the
>> >> >> peak). =3D3DA0When the delay shows up in the second or upper half
o=
>f
>> the
>> >> >> results, the delay is computed from the zero delay point up to
the
>> >> >> peak (subtract N from the location of the peak).
>>
>> >> >> But one problem I see is that you have a difference of 11 points
>> >> >> between m1 and m2. I'm not quite sure how you arrived at some of
>> the
>> >> >> numbers you're using.
>>
>> >> >I knew those numbers were suspicious! =3DA0430120 can be factored
by =
>8
>> >> >then 5 to yield 10753, which is a prime number. =3DA0So MATLAB is
>> probably
>> >> >zero padding to do the computations. =3DA0That's why your delay is
11=
>,
>> but
>> >> >your calculated delay is 19. =3DA0Very tricky.
>>
>> >> Hi,
>>
>> >> yes it is tricky and that is exactly what is confusing me as to
which
>> is
>> >> the right one.
>>
>> >> No, it is not zero padding. Actually i start recording using some
>> other
>> >> recording software and not MATLAB bcuz MATLAB doesnt support four
>> multipl=3D
>> >e
>> >> inputs. I start recording, and as soon as i capture the peak, then
i
>> stop
>> >> the recording after about couple of seconds.
>>
>> >> Now what should i do. How do i verify if my delay calculation is
>> correct?=3D
>> >- Hide quoted text -
>>
>> >> - Show quoted text -
>>
>> >OK. =A0Let's just focus on what your output really means. =A0Your
inputs
>> >are two N point time domain recordings. =A0MATLAB will give you 2N -
1
>> >outputs (keep in mind that I'm not familiar with it - I do my own
>> >cross correlations in C++ because I know how my stuff works, and I
can
>> >trust it). =A0I said previously that you get 2N - 2 points - that's
>> >wrong - MATLAB gives you 2N - 2 points plus the N point, which is
2N-1
>> >points. =A0The N point is halfway betweeen point 0 (the first
output),
>> >and point 2N-1 (the last point). =A0In the middle of all those points
is
>> >point N. =A0It is the zero delay point. If the peak in the cross
>> >correlation shows up at the N point in the outputs, it means that
>> >there is no delay between the 2 waveforms. =A0If the peak shows up on
>> >the left side of the 2N-1 outputs (the peak is at a point less than
>> >N), it means that one waveform is delayed from the other by the
>> >distance in sample times from the point N to the left. =A0Just
imagine
>> >the points as being from -(N-1) to N to +(N-1), with N in the center
>> >as being the 'no delay between them.' =A0So if the peak shows up on
the
>> >left side of the results (peak location less than N), your delay is N
>> >minus the location of the peak, expressed as a positive number. =A0If
>> >the peak shows up on the right side of the results (peak location
>> >greater than N), then your delay is (peak location - N), which will
be
>> >a positive number.
>>
>> >The reason I'm concerned is that you seem to have a delay between
>> >waveforms of 11 sample times in a previous post, but your calculated
>> >result indicates a delay of 19 sample times. =A0Something is wrong.
=A0I
>> >don't know how MATLAB actually computes cross correlations (do you
>> >know how it does it?). =A0Your sample length is so large that it
might
>> >not do it with a direct calculation. That's what led me to believe
>> >that it's might be doing it some other way, and your sample length
>> >doesn't factor well (it has a very large prime factor).
>>
>> >I won't be back until sometime tonight, but I'll think about your
>> >problem a bit further. =A0In the mean time, is N actually 430120
>> >samples, and your programmed delay 11 sample times, and your sample
>> >rate 44100, and your computed delay at 430101? =A0Please check your
>> >numbers.
>>
>> Hi,
>>
>> Yes the nos. are correct.
>> When i stop recording, i open the .wav files in matlab which are
430120
>> samples long. If i had to record it in matlab, then i would obviously
set=
> N
>> to some value which is =3D multiple of sampling frequency i.e. N=3D
44100=
> x 10
>> for 10 sec recording; which is not the case here.
>> So, N=3D 430120.
>> max(m1)=3D176426
>> max(m2)=3D176437
>> z=3Dxcorr(m1,m2);
>> max(z)=3D430101
>> Thank you.
>> -Maz- Hide quoted text -
>>
>> - Show quoted text -
>
>I'm presuming that your max(m1) and max(m2) values are actual
>physically measured peaks occurring in your recordings. The delay is
>11 sample times between them, and I presume that you got it by
>eyeballing the data. But your calculated delay is N - 430101 =3D 19.
>Since it's on the left or lower side of the result (the computed delay
>is less than N), then it should actually be considered to be a
>negative delay, but we'll ignore that for now. As for the rest of
>your numbers, I find it quite extraordinary that you just so happen to
>have an N that has a huge prime factor (10753) in it. Similarly, your
>data length is about 9.75 seconds, which corresponds to a couple of
>miles at a sound speed of 1100 feet/sec.
>
>But your 'measured' and calculated results differ. I can't help but
>think that MATLAB may be padding the numbers without your knowledge
>because of that large prime factor in N. I seriously doubt that
>MATLAB is doing the calculation using a direct N squared computation
>(that's 1.85... x10 to the 11th calculations!). So it's probably
>factoring N into more manageable amounts. The problem is that prime
>factor of 10753. Quite possibly, it's adding a few zero padded points
>such that N can be factored more favorably. MATLAB will zero pad the
>data if you give it two different input lengths, and it wouldn't
>surprise me if it did something similar when it comes up against a
>large prime like 10753. So try changing the value you're using for N,
>and chop a few data points off your recordings. For instance, 409600
>is 640 squared, and MATLAB should have no problem with it.
>
>Otherwise, you may have a problem with how MATLAB is actually
>performing the calculation internally, and I can't help you with that.
>

Hi,

Can you suggest me what to do now?
Also, sound source cannot be couple of miles away. the location of mic 1
is (0,0) and mic 2 is (0,60) and the location at which i made the noise is
(30,20). Using calculations i have to find this point.
Yes, it is 9.75 sec of data but that is only because thats the amount of
time i captured the input from the microphones. As soon as i used to get my
peak, I used to stop the recoding button of the software.

Secondly,
[a1,b1]=max(m1);
will give me the max peak of the data m1.
a1- will be the amplitude and b1- will be the sample point which i am
interested. Therefore, using this function i can find b1 which is = 176426
for m1.

Please suggest.
(Also if u want i can send u my .wav files for you to verify)

Thank you so much for your help.

On Sep 6, 5:36*am, "maz_p5" <maz...@hotmail.com> wrote:
> >On Sep 5, 7:51=A0am, "maz_p5" <maz...@hotmail.com> wrote:
> >> >On Sep 5, 5:21=3DA0am, "maz_p5" <maz...@hotmail.com> wrote:
> >> >> >On Sep 5, 12:53=3D3DA0am, kevinjmc...@netscape.net wrote:
> >> >> >> m2 is later than m1, so it's the same as you had before with y
> >> later
> >> >> >> than x. =3D3DA0So the peak should be interpreted as occurring on
> th=
> >e
> >> lef=3D
> >> >t
> >> >> or
> >> >> >> lower half of your results. =3D3DA0Treat the first N-1 output
> point=
> >s
> >> as
> >> >> the
> >> >> >> left side results (waveform y later than waveform x), the N
> point
> >> as
> >> >> >> being the zero delay point and the second N-1 output points as
> the
> >> >> >> right side (waveform x later than waveform y). =3D3DA0You should
> ha=
> >ve
> >> 2N=3D
> >> > -
> >> >> 2
> >> >> >> outputs. =3D3DA0So if the delay shows up in the first or lower
> half=
> > of
> >> t=3D
> >> >he
> >> >> >> results, then your delay is the distance (in number of samples)
> >> >> >> between the zero delay point (point N, or the exact middle of
> your
> >> >> >> total number of points) and the peak to its left ( delay =3D3D3D
> N
> >> minus
> >> >> the
> >> >> >> peak). =3D3DA0When the delay shows up in the second or upper half
> o=
> >f
> >> the
> >> >> >> results, the delay is computed from the zero delay point up to
> the
> >> >> >> peak (subtract N from the location of the peak).
>
> >> >> >> But one problem I see is that you have a difference of 11 points
> >> >> >> between m1 and m2. I'm not quite sure how you arrived at some of
> >> the
> >> >> >> numbers you're using.
>
> >> >> >I knew those numbers were suspicious! =3DA0430120 can be factored
> by =
> >8
> >> >> >then 5 to yield 10753, which is a prime number. =3DA0So MATLAB is
> >> probably
> >> >> >zero padding to do the computations. =3DA0That's why your delay is
> 11=
> >,
> >> but
> >> >> >your calculated delay is 19. =3DA0Very tricky.
>
> >> >> Hi,
>
> >> >> yes it is tricky and that is exactly what is confusing me as to
> which
> >> is
> >> >> the right one.
>
> >> >> No, it is not zero padding. Actually i start recording using some
> >> other
> >> >> recording software and not MATLAB bcuz MATLAB doesnt support four
> >> multipl=3D
> >> >e
> >> >> inputs. I start recording, and as soon as i capture the peak, then
> i
> >> stop
> >> >> the recording after about couple of seconds.
>
> >> >> Now what should i do. How do i verify if my delay calculation is
> >> correct?=3D
> >> >- Hide quoted text -
>
> >> >> - Show quoted text -
>
> >> >OK. =A0Let's just focus on what your output really means. =A0Your
> inputs
> >> >are two N point time domain recordings. =A0MATLAB will give you 2N -
> 1
> >> >outputs (keep in mind that I'm not familiar with it - I do my own
> >> >cross correlations in C++ because I know how my stuff works, and I
> can
> >> >trust it). =A0I said previously that you get 2N - 2 points - that's
> >> >wrong - MATLAB gives you 2N - 2 points plus the N point, which is
> 2N-1
> >> >points. =A0The N point is halfway betweeen point 0 (the first
> output),
> >> >and point 2N-1 (the last point). =A0In the middle of all those points
> is
> >> >point N. =A0It is the zero delay point. If the peak in the cross
> >> >correlation shows up at the N point in the outputs, it means that
> >> >there is no delay between the 2 waveforms. =A0If the peak shows up on
> >> >the left side of the 2N-1 outputs (the peak is at a point less than
> >> >N), it means that one waveform is delayed from the other by the
> >> >distance in sample times from the point N to the left. =A0Just
> imagine
> >> >the points as being from -(N-1) to N to +(N-1), with N in the center
> >> >as being the 'no delay between them.' =A0So if the peak shows up on
> the
> >> >left side of the results (peak location less than N), your delay is N
> >> >minus the location of the peak, expressed as a positive number. =A0If
> >> >the peak shows up on the right side of the results (peak location
> >> >greater than N), then your delay is (peak location - N), which will
> be
> >> >a positive number.
>
> >> >The reason I'm concerned is that you seem to have a delay between
> >> >waveforms of 11 sample times in a previous post, but your calculated
> >> >result indicates a delay of 19 sample times. =A0Something is wrong.
> =A0I
> >> >don't know how MATLAB actually computes cross correlations (do you
> >> >know how it does it?). =A0Your sample length is so large that it
> might
> >> >not do it with a direct calculation. That's what led me to believe
> >> >that it's might be doing it some other way, and your sample length
> >> >doesn't factor well (it has a very large prime factor).
>
> >> >I won't be back until sometime tonight, but I'll think about your
> >> >problem a bit further. =A0In the mean time, is N actually 430120
> >> >samples, and your programmed delay 11 sample times, and your sample
> >> >rate 44100, and your computed delay at 430101? =A0Please check your
> >> >numbers.
>
> >> Hi,
>
> >> Yes the nos. are correct.
> >> When i stop recording, i open the .wav files in matlab which are
> 430120
> >> samples long. If i had to record it in matlab, then i would obviously
> set=
> > N
> >> to some value which is =3D multiple of sampling frequency i.e. N=3D
> 44100=
> > x 10
> >> for 10 sec recording; which is not the case here.
> >> So, N=3D 430120.
> >> max(m1)=3D176426
> >> max(m2)=3D176437
> >> z=3Dxcorr(m1,m2);
> >> max(z)=3D430101
> >> Thank you.
> >> -Maz- Hide quoted text -
>
> >> - Show quoted text -
>
> >I'm presuming that your max(m1) and max(m2) values are actual
> >physically measured peaks occurring in your recordings. *The delay is
> >11 sample times between them, and *I presume that you got it by
> >eyeballing the data. *But your calculated delay is N - 430101 =3D 19..
> >Since it's on the left or lower side of the result (the computed delay
> >is less than N), then it should actually be considered to be a
> >negative delay, but we'll ignore that for now. *As for the rest of
> >your numbers, I find it quite extraordinary that you just so happen to
> >have an N that has a huge prime factor (10753) in it. *Similarly, your
> >data length is about 9.75 seconds, which corresponds to a couple of
> >miles at a sound speed of 1100 feet/sec.
>
> >But your 'measured' and calculated results differ. *I can't help but
> >think that MATLAB may be padding the numbers without your knowledge
> >because of that large prime factor in N. *I seriously doubt that
> >MATLAB is doing the calculation using a direct N squared computation
> >(that's 1.85... x10 to the 11th calculations!). *So it's probably
> >factoring N into more manageable amounts. *The problem is that prime
> >factor of 10753. *Quite possibly, it's adding a few zero padded points
> >such that N can be factored more favorably. *MATLAB will zero pad the
> >data if you give it two different input lengths, and it wouldn't
> >surprise me if it did something similar when it comes up against a
> >large prime like 10753. *So try changing the value you're using for N,
> >and chop a few data points off your recordings. *For instance, 409600
> >is 640 squared, and MATLAB should have no problem with it.
>
> >Otherwise, you may have a problem with how MATLAB is actually
> >performing the calculation internally, and I can't help you with that.
>
> Hi,
>
> Can you suggest me what to do now?
> Also, sound source cannot be couple of miles away. the location of mic 1
> is (0,0) and mic 2 is (0,60) and the location at which i made the noise is
> (30,20). Using calculations i have to find this point.
> Yes, it is 9.75 sec of data but that is only because thats the amount of
> time i captured the input from the microphones. As soon as i used to get my
> peak, I used to stop the recoding button of the software.
>
> Secondly,
> [a1,b1]=max(m1);
> will give me the max peak of the data m1.
> a1- will be the amplitude and b1- will be the sample point which i am
> interested. Therefore, using this function i can find b1 which is = 176426
> for m1.
>
> Please suggest.
> (Also if u want i can send u my .wav files for you to verify)
>
> Thank you so much for your help. *- Hide quoted text -
>
> - Show quoted text -

At a sound speed in air of 1100 ft/sec., 9.75 sec. of data corresponds
to a travel distance of about 11000 ft., which is roughly 2 miles. I
still don't know exactly how far away in actual distance your
microphones are located.

Suppose you compute xcorr(m2,m1) instead of xcorr(m1,m2). This may
tell me if MATLAB is adding points to do the calculation.

I should also mention that there's a possibility that your results may
be correct. Just because you determine that the peak in your inputs
are at a certain point, the rest of the waveforms have some bearing on
the outcome. So even if your max(waveform 1) - max(waveform 2) = 11
points, and your calculated result yields 19 points, I suppose it's
possible to be correct. It's just that the difference seems too large
(8 points).

Compute xcorr by reversing the inputs, and let me know what you get.
Windowing your input data may also be helpful, but let's try one thing
at a time.

>On Sep 6, 5:36=A0am, "maz_p5" <maz...@hotmail.com> wrote:
>> >On Sep 5, 7:51=3DA0am, "maz_p5" <maz...@hotmail.com> wrote:
>> >> >On Sep 5, 5:21=3D3DA0am, "maz_p5" <maz...@hotmail.com> wrote:
>> >> >> >On Sep 5, 12:53=3D3D3DA0am, kevinjmc...@netscape.net wrote:
>> >> >> >> m2 is later than m1, so it's the same as you had before with
y
>> >> later
>> >> >> >> than x. =3D3D3DA0So the peak should be interpreted as
occurring =
>on
>> th=3D
>> >e
>> >> lef=3D3D
>> >> >t
>> >> >> or
>> >> >> >> lower half of your results. =3D3D3DA0Treat the first N-1
output
>> point=3D
>> >s
>> >> as
>> >> >> the
>> >> >> >> left side results (waveform y later than waveform x), the N
>> point
>> >> as
>> >> >> >> being the zero delay point and the second N-1 output points
as
>> the
>> >> >> >> right side (waveform x later than waveform y). =3D3D3DA0You
shou=
>ld
>> ha=3D
>> >ve
>> >> 2N=3D3D
>> >> > -
>> >> >> 2
>> >> >> >> outputs. =3D3D3DA0So if the delay shows up in the first or
lower
>> half=3D
>> > of
>> >> t=3D3D
>> >> >he
>> >> >> >> results, then your delay is the distance (in number of
samples)
>> >> >> >> between the zero delay point (point N, or the exact middle of
>> your
>> >> >> >> total number of points) and the peak to its left ( delay
=3D3D3D=
>3D
>> N
>> >> minus
>> >> >> the
>> >> >> >> peak). =3D3D3DA0When the delay shows up in the second or upper
h=
>alf
>> o=3D
>> >f
>> >> the
>> >> >> >> results, the delay is computed from the zero delay point up
to
>> the
>> >> >> >> peak (subtract N from the location of the peak).
>>
>> >> >> >> But one problem I see is that you have a difference of 11
points
>> >> >> >> between m1 and m2. I'm not quite sure how you arrived at some
of
>> >> the
>> >> >> >> numbers you're using.
>>
>> >> >> >I knew those numbers were suspicious! =3D3DA0430120 can be
factore=
>d
>> by =3D
>> >8
>> >> >> >then 5 to yield 10753, which is a prime number. =3D3DA0So MATLAB
i=
>s
>> >> probably
>> >> >> >zero padding to do the computations. =3D3DA0That's why your
delay =
>is
>> 11=3D
>> >,
>> >> but
>> >> >> >your calculated delay is 19. =3D3DA0Very tricky.
>>
>> >> >> Hi,
>>
>> >> >> yes it is tricky and that is exactly what is confusing me as to
>> which
>> >> is
>> >> >> the right one.
>>
>> >> >> No, it is not zero padding. Actually i start recording using
some
>> >> other
>> >> >> recording software and not MATLAB bcuz MATLAB doesnt support
four
>> >> multipl=3D3D
>> >> >e
>> >> >> inputs. I start recording, and as soon as i capture the peak,
then
>> i
>> >> stop
>> >> >> the recording after about couple of seconds.
>>
>> >> >> Now what should i do. How do i verify if my delay calculation is
>> >> correct?=3D3D
>> >> >- Hide quoted text -
>>
>> >> >> - Show quoted text -
>>
>> >> >OK. =3DA0Let's just focus on what your output really means.
=3DA0Your
>> inputs
>> >> >are two N point time domain recordings. =3DA0MATLAB will give you
2N =
>-
>> 1
>> >> >outputs (keep in mind that I'm not familiar with it - I do my own
>> >> >cross correlations in C++ because I know how my stuff works, and I
>> can
>> >> >trust it). =3DA0I said previously that you get 2N - 2 points -
that's
>> >> >wrong - MATLAB gives you 2N - 2 points plus the N point, which is
>> 2N-1
>> >> >points. =3DA0The N point is halfway betweeen point 0 (the first
>> output),
>> >> >and point 2N-1 (the last point). =3DA0In the middle of all those
poin=
>ts
>> is
>> >> >point N. =3DA0It is the zero delay point. If the peak in the cross
>> >> >correlation shows up at the N point in the outputs, it means that
>> >> >there is no delay between the 2 waveforms. =3DA0If the peak shows
up =
>on
>> >> >the left side of the 2N-1 outputs (the peak is at a point less
than
>> >> >N), it means that one waveform is delayed from the other by the
>> >> >distance in sample times from the point N to the left. =3DA0Just
>> imagine
>> >> >the points as being from -(N-1) to N to +(N-1), with N in the
center
>> >> >as being the 'no delay between them.' =3DA0So if the peak shows up
on
>> the
>> >> >left side of the results (peak location less than N), your delay is
N
>> >> >minus the location of the peak, expressed as a positive number.
=3DA0=
>If
>> >> >the peak shows up on the right side of the results (peak location
>> >> >greater than N), then your delay is (peak location - N), which
will
>> be
>> >> >a positive number.
>>
>> >> >The reason I'm concerned is that you seem to have a delay between
>> >> >waveforms of 11 sample times in a previous post, but your
calculated
>> >> >result indicates a delay of 19 sample times. =3DA0Something is
wrong.
>> =3DA0I
>> >> >don't know how MATLAB actually computes cross correlations (do you
>> >> >know how it does it?). =3DA0Your sample length is so large that it
>> might
>> >> >not do it with a direct calculation. That's what led me to believe
>> >> >that it's might be doing it some other way, and your sample length
>> >> >doesn't factor well (it has a very large prime factor).
>>
>> >> >I won't be back until sometime tonight, but I'll think about your
>> >> >problem a bit further. =3DA0In the mean time, is N actually 430120
>> >> >samples, and your programmed delay 11 sample times, and your
sample
>> >> >rate 44100, and your computed delay at 430101? =3DA0Please check
your
>> >> >numbers.
>>
>> >> Hi,
>>
>> >> Yes the nos. are correct.
>> >> When i stop recording, i open the .wav files in matlab which are
>> 430120
>> >> samples long. If i had to record it in matlab, then i would
obviously
>> set=3D
>> > N
>> >> to some value which is =3D3D multiple of sampling frequency i.e.
N=3D3=
>D
>> 44100=3D
>> > x 10
>> >> for 10 sec recording; which is not the case here.
>> >> So, N=3D3D 430120.
>> >> max(m1)=3D3D176426
>> >> max(m2)=3D3D176437
>> >> z=3D3Dxcorr(m1,m2);
>> >> max(z)=3D3D430101
>> >> Thank you.
>> >> -Maz- Hide quoted text -
>>
>> >> - Show quoted text -
>>
>> >I'm presuming that your max(m1) and max(m2) values are actual
>> >physically measured peaks occurring in your recordings. =A0The delay
is
>> >11 sample times between them, and =A0I presume that you got it by
>> >eyeballing the data. =A0But your calculated delay is N - 430101 =3D3D
19=
>.
>> >Since it's on the left or lower side of the result (the computed
delay
>> >is less than N), then it should actually be considered to be a
>> >negative delay, but we'll ignore that for now. =A0As for the rest of
>> >your numbers, I find it quite extraordinary that you just so happen
to
>> >have an N that has a huge prime factor (10753) in it. =A0Similarly,
your
>> >data length is about 9.75 seconds, which corresponds to a couple of
>> >miles at a sound speed of 1100 feet/sec.
>>
>> >But your 'measured' and calculated results differ. =A0I can't help
but
>> >think that MATLAB may be padding the numbers without your knowledge
>> >because of that large prime factor in N. =A0I seriously doubt that
>> >MATLAB is doing the calculation using a direct N squared computation
>> >(that's 1.85... x10 to the 11th calculations!). =A0So it's probably
>> >factoring N into more manageable amounts. =A0The problem is that
prime
>> >factor of 10753. =A0Quite possibly, it's adding a few zero padded
points
>> >such that N can be factored more favorably. =A0MATLAB will zero pad
the
>> >data if you give it two different input lengths, and it wouldn't
>> >surprise me if it did something similar when it comes up against a
>> >large prime like 10753. =A0So try changing the value you're using for
N,
>> >and chop a few data points off your recordings. =A0For instance,
409600
>> >is 640 squared, and MATLAB should have no problem with it.
>>
>> >Otherwise, you may have a problem with how MATLAB is actually
>> >performing the calculation internally, and I can't help you with
that.
>>
>> Hi,
>>
>> Can you suggest me what to do now?
>> Also, sound source cannot be couple of miles away. the location of mic
1
>> is (0,0) and mic 2 is (0,60) and the location at which i made the noise
i=
>s
>> (30,20). Using calculations i have to find this point.
>> Yes, it is 9.75 sec of data but that is only because thats the amount
of
>> time i captured the input from the microphones. As soon as i used to
get =
>my
>> peak, I used to stop the recoding button of the software.
>>
>> Secondly,
>> [a1,b1]=3Dmax(m1);
>> will give me the max peak of the data m1.
>> a1- will be the amplitude and b1- will be the sample point which i am
>> interested. Therefore, using this function i can find b1 which is =3D
176=
>426
>> for m1.
>>
>> Please suggest.
>> (Also if u want i can send u my .wav files for you to verify)
>>
>> Thank you so much for your help. =A0- Hide quoted text -
>>
>> - Show quoted text -
>
>At a sound speed in air of 1100 ft/sec., 9.75 sec. of data corresponds
>to a travel distance of about 11000 ft., which is roughly 2 miles. I
>still don't know exactly how far away in actual distance your
>microphones are located.
>
>Suppose you compute xcorr(m2,m1) instead of xcorr(m1,m2). This may
>tell me if MATLAB is adding points to do the calculation.
>
>I should also mention that there's a possibility that your results may
>be correct. Just because you determine that the peak in your inputs
>are at a certain point, the rest of the waveforms have some bearing on
>the outcome. So even if your max(waveform 1) - max(waveform 2) =3D 11
>points, and your calculated result yields 19 points, I suppose it's
>possible to be correct. It's just that the difference seems too large
>(8 points).
>
>Compute xcorr by reversing the inputs, and let me know what you get.
>Windowing your input data may also be helpful, but let's try one thing
>at a time.
>
Hi,

Well when i try xcorr(m2,m1). I get the max sample as 430139 which again
shows a difference of 19.

And, all the co-ordinates which i told you are in cm; that means that the
2 mics are 60 cm apart.

On Sep 6, 6:58*am, "maz_p5" <maz...@hotmail.com> wrote:
> >On Sep 6, 5:36=A0am, "maz_p5" <maz...@hotmail.com> wrote:
> >> >On Sep 5, 7:51=3DA0am, "maz_p5" <maz...@hotmail.com> wrote:
> >> >> >On Sep 5, 5:21=3D3DA0am, "maz_p5" <maz...@hotmail.com> wrote:
> >> >> >> >On Sep 5, 12:53=3D3D3DA0am, kevinjmc...@netscape.net wrote:
> >> >> >> >> m2 is later than m1, so it's the same as you had before with
> y
> >> >> later
> >> >> >> >> than x. =3D3D3DA0So the peak should be interpreted as
> occurring =
> >on
> >> th=3D
> >> >e
> >> >> lef=3D3D
> >> >> >t
> >> >> >> or
> >> >> >> >> lower half of your results. =3D3D3DA0Treat the first N-1
> output
> >> point=3D
> >> >s
> >> >> as
> >> >> >> the
> >> >> >> >> left side results (waveform y later than waveform x), the N
> >> point
> >> >> as
> >> >> >> >> being the zero delay point and the second N-1 output points
> as
> >> the
> >> >> >> >> right side (waveform x later than waveform y). =3D3D3DA0You
> shou=
> >ld
> >> ha=3D
> >> >ve
> >> >> 2N=3D3D
> >> >> > -
> >> >> >> 2
> >> >> >> >> outputs. =3D3D3DA0So if the delay shows up in the first or
> lower
> >> half=3D
> >> > of
> >> >> t=3D3D
> >> >> >he
> >> >> >> >> results, then your delay is the distance (in number of
> samples)
> >> >> >> >> between the zero delay point (point N, or the exact middle of
> >> your
> >> >> >> >> total number of points) and the peak to its left ( delay
> =3D3D3D=
> >3D
> >> N
> >> >> minus
> >> >> >> the
> >> >> >> >> peak). =3D3D3DA0When the delay shows up in the second or upper
> h=
> >alf
> >> o=3D
> >> >f
> >> >> the
> >> >> >> >> results, the delay is computed from the zero delay point up
> to
> >> the
> >> >> >> >> peak (subtract N from the location of the peak).
>
> >> >> >> >> But one problem I see is that you have a difference of 11
> points
> >> >> >> >> between m1 and m2. I'm not quite sure how you arrived at some
> of
> >> >> the
> >> >> >> >> numbers you're using.
>
> >> >> >> >I knew those numbers were suspicious! =3D3DA0430120 can be
> factore=
> >d
> >> by =3D
> >> >8
> >> >> >> >then 5 to yield 10753, which is a prime number. =3D3DA0So MATLAB
> i=
> >s
> >> >> probably
> >> >> >> >zero padding to do the computations. =3D3DA0That's why your
> delay =
> >is
> >> 11=3D
> >> >,
> >> >> but
> >> >> >> >your calculated delay is 19. =3D3DA0Very tricky.
>
> >> >> >> Hi,
>
> >> >> >> yes it is tricky and that is exactly what is confusing me as to
> >> which
> >> >> is
> >> >> >> the right one.
>
> >> >> >> No, it is not zero padding. Actually i start recording using
> some
> >> >> other
> >> >> >> recording software and not MATLAB bcuz MATLAB doesnt support
> four
> >> >> multipl=3D3D
> >> >> >e
> >> >> >> inputs. I start recording, and as soon as i capture the peak,
> then
> >> i
> >> >> stop
> >> >> >> the recording after about couple of seconds.
>
> >> >> >> Now what should i do. How do i verify if my delay calculation is
> >> >> correct?=3D3D
> >> >> >- Hide quoted text -
>
> >> >> >> - Show quoted text -
>
> >> >> >OK. =3DA0Let's just focus on what your output really means.
> =3DA0Your
> >> inputs
> >> >> >are two N point time domain recordings. =3DA0MATLAB will give you
> 2N =
> >-
> >> 1
> >> >> >outputs (keep in mind that I'm not familiar with it - I do my own
> >> >> >cross correlations in C++ because I know how my stuff works, and I
> >> can
> >> >> >trust it). =3DA0I said previously that you get 2N - 2 points -
> that's
> >> >> >wrong - MATLAB gives you 2N - 2 points plus the N point, which is
> >> 2N-1
> >> >> >points. =3DA0The N point is halfway betweeen point 0 (the first
> >> output),
> >> >> >and point 2N-1 (the last point). =3DA0In the middle of all those
> poin=
> >ts
> >> is
> >> >> >point N. =3DA0It is the zero delay point. If the peak in the cross
> >> >> >correlation shows up at the N point in the outputs, it means that
> >> >> >there is no delay between the 2 waveforms. =3DA0If the peak shows
> up =
> >on
> >> >> >the left side of the 2N-1 outputs (the peak is at a point less
> than
> >> >> >N), it means that one waveform is delayed from the other by the
> >> >> >distance in sample times from the point N to the left. =3DA0Just
> >> imagine
> >> >> >the points as being from -(N-1) to N to +(N-1), with N in the
> center
> >> >> >as being the 'no delay between them.' =3DA0So if the peak shows up
> on
> >> the
> >> >> >left side of the results (peak location less than N), your delay is
> N
> >> >> >minus the location of the peak, expressed as a positive number.
> =3DA0=
> >If
> >> >> >the peak shows up on the right side of the results (peak location
> >> >> >greater than N), then your delay is (peak location - N), which
> will
> >> be
> >> >> >a positive number.
>
> >> >> >The reason I'm concerned is that you seem to have a delay between
> >> >> >waveforms of 11 sample times in a previous post, but your
> calculated
> >> >> >result indicates a delay of 19 sample times. =3DA0Something is
> wrong.
> >> =3DA0I
> >> >> >don't know how MATLAB actually computes cross correlations (do you
> >> >> >know how it does it?). =3DA0Your sample length is so large that it
> >> might
> >> >> >not do it with a direct calculation. That's what led me to believe
> >> >> >that it's might be doing it some other way, and your sample length
> >> >> >doesn't factor well (it has a very large prime factor).
>
> >> >> >I won't be back until sometime tonight, but I'll think about your
> >> >> >problem a bit further. =3DA0In the mean time, is N actually 430120
> >> >> >samples, and your programmed delay 11 sample times, and your
> sample
> >> >> >rate 44100, and your computed delay at 430101? =3DA0Please check
> your
> >> >> >numbers.
>
> >> >> Hi,
>
> >> >> Yes the nos. are correct.
> >> >> When i stop recording, i open the .wav files in matlab which are
> >> 430120
> >> >> samples long. If i had to record it in matlab, then i would
> obviously
> >> set=3D
> >> > N
> >> >> to some value which is =3D3D multiple of sampling frequency i.e.
> N=3D3=
> >D
> >> 44100=3D
> >> > x 10
> >> >> for 10 sec recording; which is not the case here.
> >> >> So, N=3D3D 430120.
> >> >> max(m1)=3D3D176426
> >> >> max(m2)=3D3D176437
> >> >> z=3D3Dxcorr(m1,m2);
> >> >> max(z)=3D3D430101
> >> >> Thank you.
> >> >> -Maz- Hide quoted text -
>
> >> >> - Show quoted text -
>
> >> >I'm presuming that your max(m1) and max(m2) values are actual
> >> >physically measured peaks occurring in your recordings. =A0The delay
> is
> >> >11 sample times between them, and =A0I presume that you got it by
> >> >eyeballing the data. =A0But your calculated delay is N - 430101 =3D3D
> 19=
> >.
> >> >Since it's on the left or lower side of the result (the computed
> delay
> >> >is less than N), then it should actually be considered to be a
> >> >negative delay, but we'll ignore that for now. =A0As for the rest of
> >> >your numbers, I find it quite extraordinary that you just so happen
> to
> >> >have an N that has a huge prime factor (10753) in it. =A0Similarly,
> your
> >> >data length is about 9.75 seconds, which corresponds to a couple of
> >> >miles at a sound speed of 1100 feet/sec.
>
> >> >But your 'measured' and calculated results differ. =A0I can't help
> but
> >> >think that MATLAB may be padding the numbers without your knowledge
> >> >because of that large prime factor in N. =A0I seriously doubt that
> >> >MATLAB is doing the calculation using a direct N squared computation
> >> >(that's 1.85... x10 to the 11th calculations!). =A0So it's probably
> >> >factoring N into more manageable amounts. =A0The problem is that
> prime
> >> >factor of 10753. =A0Quite possibly, it's adding a few zero padded
> points
> >> >such that N can be factored more favorably. =A0MATLAB will zero pad
> the
> >> >data if you give it two different input lengths, and it wouldn't
> >> >surprise me if it did something similar when it comes up against a
> >> >large prime like 10753. =A0So try changing the value you're using for
> N,
> >> >and chop a few data points off your recordings. =A0For instance,
> 409600
> >> >is 640 squared, and MATLAB should have no problem with it.
>
> >> >Otherwise, you may have a problem with how MATLAB is actually
> >> >performing the calculation internally, and I can't help you with
> that.
>
> >> Hi,
>
> >> Can you suggest me what to do now?
> >> Also, sound source cannot be couple of miles away. the location of mic
> 1
> >> is (0,0) and mic 2 is (0,60) and the location at which i made the noise
> i=
> >s
> >> (30,20). Using calculations i have to find this point.
> >> Yes, it is 9.75 sec of data but that is only because thats the amount
> of
> >> time i captured the input from the microphones. As soon as i used to
> get =
> >my
> >> peak, I used to stop the recoding button of the software.
>
> >> Secondly,
> >> [a1,b1]=3Dmax(m1);
> >> will give me the max peak of the data m1.
> >> a1- will be the amplitude and b1- will be the sample point which i am
> >> interested. Therefore, using this function i can find b1 which is =3D
> 176=
> >426
> >> for m1.
>
> >> Please suggest.
> >> (Also if u want i can send u my .wav files for you to verify)
>
> >> Thank you so much for your help. =A0- Hide quoted text -
>
> >> - Show quoted text -
>
> >At a sound speed in air of 1100 ft/sec., 9.75 sec. of data corresponds
> >to a travel distance of about 11000 ft., which is roughly 2 miles. *I
> >still don't know exactly how far away in actual distance your
> >microphones are located.
>
> >Suppose you compute xcorr(m2,m1) instead of xcorr(m1,m2). *This may
> >tell me if MATLAB is adding points to do the calculation.
>
> >I should also mention that there's a possibility that your results may
> >be correct. *Just because you determine that the peak in your inputs
> >are at a certain point, the rest of the waveforms have some bearing on
> >the outcome. *So even if your max(waveform 1) - max(waveform 2) =3D 11
> >points, and your calculated result yields 19 points, I suppose it's
> >possible to be correct. *It's just that the difference seems too large
> >(8 points).
>
> >Compute xcorr by reversing the inputs, and let me know what you get.
> >Windowing your input data may also be helpful, but let's try one thing
> >at a time.
>
> Hi,
>
> Well when i try xcorr(m2,m1). I get the max sample as 430139 which again
> shows a difference of 19.
>
> And, all the co-ordinates which i told you are in cm; that means that the
> 2 mics are 60 cm apart.- Hide quoted text -
>
> - Show quoted text -

A delay of 19 looks good to me. I'm still a little troubled by the 8
point difference (delay of 11 versus 19), but given the large value of
N, there's certainly some computational noise in the result. And
MATLAB may indeed be zero padding to get rid of that large prime
factor, but your result using reversed inputs tells me that at least
it knows enough to change the N point (the zero delay point in the
middle of the results). So perhaps your result is correct. I'm
presuming that your two N point data sequences have a lot of zero or
small numbers in the earlier and later parts of the data on either
side of the peak within the waveforms. If not, then you're doing a
circular cross correlation, and that can skew your results. Windowing
or zero padding your data would be helpful in that case. But since
you've said that you're dealing with a low noise situation, and you're
using a very large N, then you might be OK.

Now you've got to compute the location of your source within your
problem framework. Good luck with that. I hope it works out well. If
I can be of any help, let me know.

A delay of 19 looks good to me. I'm still a little troubled by the 8
point difference (delay of 11 versus 19), but given the large value
of
N, there's certainly some computational noise in the result. And
MATLAB may indeed be zero padding to get rid of that large prime
factor, but your result using reversed inputs tells me that at least
it knows enough to change the N point (the zero delay point in the
middle of the results). So perhaps your result is correct. I'm
presuming that your two N point data sequences have a lot of zero or
small numbers in the earlier and later parts of the data on either
side of the peak within the waveforms. If not, then you're doing a
circular cross correlation, and that can skew your results. Windowing
or zero padding your data would be helpful in that case. But since
you've said that you're dealing with a low noise situation, and
you're
using a very large N, then you might be OK.

Now you've got to compute the location of your source within your
problem framework. Good luck with that. I hope it works out well.
If
I can be of any help, let me know.

>
>A delay of 19 looks good to me. I'm still a little troubled by the 8
>point difference (delay of 11 versus 19), but given the large value
>of
>N, there's certainly some computational noise in the result. And
>MATLAB may indeed be zero padding to get rid of that large prime
>factor, but your result using reversed inputs tells me that at least
>it knows enough to change the N point (the zero delay point in the
>middle of the results). So perhaps your result is correct. I'm
>presuming that your two N point data sequences have a lot of zero or
>small numbers in the earlier and later parts of the data on either
>side of the peak within the waveforms. If not, then you're doing a
>circular cross correlation, and that can skew your results. Windowing
>or zero padding your data would be helpful in that case. But since
>you've said that you're dealing with a low noise situation, and
>you're
>using a very large N, then you might be OK.
>
>Now you've got to compute the location of your source within your
>problem framework. Good luck with that. I hope it works out well.
>If
>I can be of any help, let me know.
>
>
>
>
Hi,

Yes, as i said before, there are lot of zero values and close to zero
values in the data like for example "0.0003 and -0.0003" This is because of
the little noise which is there. Therefore, when I plot this, I get a graph
which has a straight line, then these series of peaks (going from amplitude
of 1 to -1) and again a straight line (which is almost zero) till the end.


I hope, then what have u just said is the right way. Because I have been
doing that all this while but was not sure of the results. Also do you know
how can I verify if my delay is right?

For testing purpose, I put two mics 120 cm apart and the sound was made
right in the center. The value of both the data is : 942888. The max value
at two mics were at 257118 and 257120 respectively. i think this is proper
because in real world case a delay of 2 is acceptable. Then, i cross
correlated both the files i.e. z=xcorr(m1,m2); The max of z is 942740 which
is strange because the difference then is 148.

Any suggestions? I know I am making it all the more difficult for you and
I am sorry for it, but I hope you understand my situation; I am stuck on
this point for almost more than a month now and my deadline is approaching.


Sorry for the trouble and thank you once again.

>>
>>A delay of 19 looks good to me. I'm still a little troubled by the 8
>>point difference (delay of 11 versus 19), but given the large value
>>of
>>N, there's certainly some computational noise in the result. And
>>MATLAB may indeed be zero padding to get rid of that large prime
>>factor, but your result using reversed inputs tells me that at least
>>it knows enough to change the N point (the zero delay point in the
>>middle of the results). So perhaps your result is correct. I'm
>>presuming that your two N point data sequences have a lot of zero or
>>small numbers in the earlier and later parts of the data on either
>>side of the peak within the waveforms. If not, then you're doing a
>>circular cross correlation, and that can skew your results. Windowing
>>or zero padding your data would be helpful in that case. But since
>>you've said that you're dealing with a low noise situation, and
>>you're
>>using a very large N, then you might be OK.
>>
>>Now you've got to compute the location of your source within your
>>problem framework. Good luck with that. I hope it works out well.
>>If
>>I can be of any help, let me know.
>>
>>
>>
>>
>Hi,
>
>Yes, as i said before, there are lot of zero values and close to zero
>values in the data like for example "0.0003 and -0.0003" This is because
of
>the little noise which is there. Therefore, when I plot this, I get a
graph
>which has a straight line, then these series of peaks (going from
amplitude
>of 1 to -1) and again a straight line (which is almost zero) till the
end.
>
>
>I hope, then what have u just said is the right way. Because I have been
>doing that all this while but was not sure of the results. Also do you
know
>how can I verify if my delay is right?
>
>For testing purpose, I put two mics 120 cm apart and the sound was made
>right in the center. The value of both the data is : 942888. The max
value
>at two mics were at 257118 and 257120 respectively. i think this is
proper
>because in real world case a delay of 2 is acceptable. Then, i cross
>correlated both the files i.e. z=xcorr(m1,m2); The max of z is 942740
which
>is strange because the difference then is 148.
>
>Any suggestions?

The delay of 2 using max( ) seems good - the cross correlation of 148
seems not as good. It's possible, however, that the number is
correct. As you pointed out, you're dealing with waveforms that have
a series of peaks. The cross correlation does NOT give you a result
that is dependent on just the delay difference between the largest
values in each waveform. Rather, the result depends on all the data
in each waveform. And think of it in terms of the overall data length
- you've got 942888 data points. 148 doesn't seem too bad when using
so many points. And think of how that number 148 relates to the
physical parameters you are using. How far in distance does that
correspond to when using a sample rate of 44100 with a sound speed of
1100 ft/sec.?

To check the delay, try reversing the order of the xcorr( ) inputs
again. If the number is anywhere near 148, then I suspect that the
delay is correct.

The small numbers at the beginning and end of the data records are
also good, because it's unlikely that you'll have to zero pad or
window your data.

On Sep 7, 8:41*pm, kevinjmc...@netscape.net wrote:
> The delay of 2 using max( ) seems good - the cross correlation of 148
> seems not as good. *It's possible, however, that the number is
> correct. *As you pointed out, you're dealing with waveforms that have
> a series of peaks. *The cross correlation does NOT give you a result
> that is dependent on just the delay difference between the largest
> values in each waveform. *Rather, the result depends on all the data
> in each waveform. *And think of it in terms of the overall data length
> - you've got 942888 data points. *148 doesn't seem too bad when using
> so many points. *And think of how that number 148 relates to the
> physical parameters you are using. *How far in distance does that
> correspond to when using a sample rate of 44100 with a sound speed of
> 1100 ft/sec.?
>
> To check the delay, try reversing the order of the xcorr( ) inputs
> again. *If the number is anywhere near 148, then I suspect that the
> delay is correct.
>
> The small numbers at the beginning and end of the data records are
> also good, because it's unlikely that you'll have to zero pad or
> window your data.


I just spent 15 minutes looking at your numbers. For a 1.2m mic
separation, at roughly 340 m/sec sound speed, the time to travel that
distance is .0035294 sec. At a sample rate of 44100 samples/sec, one
sample time is 1/44100 or .00002267 sec. So the number of sample
times required to travel 1.2m corresponds to 155 sample times. Half
that distance is 77.5 sample times (.0017647 sec).

You're using nearly a million (942888) sample times to record the
data. I presume that you start recording, wait a few seconds, initiate
the sound, then wait a few more seconds. Your number of 257118
corresponds to a time length of 5.83034 seconds. But since the sound
comes from a point midway between the mics, it only takes 77.5 sample
times to arrive at each of them (presuming everything is absolutely
perfect).

You're using way too many data points. I said before that having
small numbers at the beginning or end of your data record is good, but
not when you take it to such an extreme. All it would take is a
little bit of microphone gain differences, a little bit of power
supply hum feeeding into them, or any one of a number of things to
mess up the results. Just consider what happens to those small
numbers of .0003 or -.0003 when you compute something using a couple
of million points. If those numbers are in any way correlated, you
results will be affected.

Consider an absolutely perfect set up with the sound source at the
midpoint. The actual delay would be 77.5 sample times, and the the
computed delay would be 0, because it takes 77.5 sample times to reach
each of the mics simultaneously. The delay of 0 says that the sound
source is exactly at the midpoint between the 2 mics.

You need to severely cut down on the number of data points that you're
using. And believe it or not, those numbers of 2 and 148 may not be
as far apart as you think (in an imperfect world, the numbers may be
some multiple of the 77.5).

So go ahead and reverse the inputs to the xcorr( ) and see what you
get. Then cut your data length down to a more reasonable number.

>On Sep 7, 8:41=A0pm, kevinjmc...@netscape.net wrote:
>> The delay of 2 using max( ) seems good - the cross correlation of 148
>> seems not as good. =A0It's possible, however, that the number is
>> correct. =A0As you pointed out, you're dealing with waveforms that
have
>> a series of peaks. =A0The cross correlation does NOT give you a result
>> that is dependent on just the delay difference between the largest
>> values in each waveform. =A0Rather, the result depends on all the data
>> in each waveform. =A0And think of it in terms of the overall data
length
>> - you've got 942888 data points. =A0148 doesn't seem too bad when
using
>> so many points. =A0And think of how that number 148 relates to the
>> physical parameters you are using. =A0How far in distance does that
>> correspond to when using a sample rate of 44100 with a sound speed of
>> 1100 ft/sec.?
>>
>> To check the delay, try reversing the order of the xcorr( ) inputs
>> again. =A0If the number is anywhere near 148, then I suspect that the
>> delay is correct.
>>
>> The small numbers at the beginning and end of the data records are
>> also good, because it's unlikely that you'll have to zero pad or
>> window your data.
>
>
>I just spent 15 minutes looking at your numbers. For a 1.2m mic
>separation, at roughly 340 m/sec sound speed, the time to travel that
>distance is .0035294 sec. At a sample rate of 44100 samples/sec, one
>sample time is 1/44100 or .00002267 sec. So the number of sample
>times required to travel 1.2m corresponds to 155 sample times. Half
>that distance is 77.5 sample times (.0017647 sec).
>
>You're using nearly a million (942888) sample times to record the
>data. I presume that you start recording, wait a few seconds, initiate
>the sound, then wait a few more seconds. Your number of 257118
>corresponds to a time length of 5.83034 seconds. But since the sound
>comes from a point midway between the mics, it only takes 77.5 sample
>times to arrive at each of them (presuming everything is absolutely
>perfect).
>
>You're using way too many data points. I said before that having
>small numbers at the beginning or end of your data record is good, but
>not when you take it to such an extreme. All it would take is a
>little bit of microphone gain differences, a little bit of power
>supply hum feeeding into them, or any one of a number of things to
>mess up the results. Just consider what happens to those small
>numbers of .0003 or -.0003 when you compute something using a couple
>of million points. If those numbers are in any way correlated, you
>results will be affected.
>
>Consider an absolutely perfect set up with the sound source at the
>midpoint. The actual delay would be 77.5 sample times, and the the
>computed delay would be 0, because it takes 77.5 sample times to reach
>each of the mics simultaneously. The delay of 0 says that the sound
>source is exactly at the midpoint between the 2 mics.
>
>You need to severely cut down on the number of data points that you're
>using. And believe it or not, those numbers of 2 and 148 may not be
>as far apart as you think (in an imperfect world, the numbers may be
>some multiple of the 77.5).
>
>So go ahead and reverse the inputs to the xcorr( ) and see what you
>get. Then cut your data length down to a more reasonable number.
>
>

Hi,
Yes, you are absolutely right. I wait for sometime (in seconds) before and
after generating the sound.

As far as this experiment with two mics is concerned, I reversed the cross
correlation i.e. now z1=xcorr(m2,m1);
max(z)=-max(z1) i.e. the max value of this reversed cross correlation
matrix z1 is -148.

What is your interpretation out of this?

As far as cutting down the length, do you just want me to delete few
thousands of initial and final values? After cutting down, should i again
try cross-correlating them?