>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 onth=>e >> lef=3D >> >t >> >> or >> >> >> lower half of your results. =3D3DA0Treat the first N-1 outputpoint=>s >> as >> >> the >> >> >> left side results (waveform y later than waveform x), the Npoint>> as >> >> >> being the zero delay point and the second N-1 output points asthe>> >> >> right side (waveform x later than waveform y). =3D3DA0You shouldha=>ve >> 2N=3D >> > - >> >> 2 >> >> >> outputs. =3D3DA0So if the delay shows up in the first or lowerhalf=> 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 ofyour>> >> >> total number of points) and the peak to its left ( delay =3D3D3DN>> minus >> >> the >> >> >> peak). =3D3DA0When the delay shows up in the second or upper halfo=>f >> the >> >> >> results, the delay is computed from the zero delay point up tothe>> >> >> 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 factoredby =>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 is11=>, >> but >> >> >your calculated delay is 19. =3DA0Very tricky. >> >> >> Hi, >> >> >> yes it is tricky and that is exactly what is confusing me as towhich>> 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, theni>> 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. =A0Yourinputs>> >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 Ican>> >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 is2N-1>> >points. =A0The N point is halfway betweeen point 0 (the firstoutput),>> >and point 2N-1 (the last point). =A0In the middle of all those pointsis>> >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. =A0Justimagine>> >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 onthe>> >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 willbe>> >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 itmight>> >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 are430120>> samples long. If i had to record it in matlab, then i would obviouslyset=> N >> to some value which is =3D multiple of sampling frequency i.e. N=3D44100=> 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.
cross correlation sound
Started by ●August 24, 2008
Reply by ●September 6, 20082008-09-06
Reply by ●September 6, 20082008-09-06
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.
Reply by ●September 6, 20082008-09-06
>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 withy>> >> later >> >> >> >> than x. =3D3D3DA0So the peak should be interpreted asoccurring =>on >> th=3D >> >e >> >> lef=3D3D >> >> >t >> >> >> or >> >> >> >> lower half of your results. =3D3D3DA0Treat the first N-1output>> 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 pointsas>> the >> >> >> >> right side (waveform x later than waveform y). =3D3D3DA0Youshou=>ld >> ha=3D >> >ve >> >> 2N=3D3D >> >> > - >> >> >> 2 >> >> >> >> outputs. =3D3D3DA0So if the delay shows up in the first orlower>> half=3D >> > of >> >> t=3D3D >> >> >he >> >> >> >> results, then your delay is the distance (in number ofsamples)>> >> >> >> 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 upperh=>alf >> o=3D >> >f >> >> the >> >> >> >> results, the delay is computed from the zero delay point upto>> the >> >> >> >> peak (subtract N from the location of the peak). >> >> >> >> >> But one problem I see is that you have a difference of 11points>> >> >> >> between m1 and m2. I'm not quite sure how you arrived at someof>> >> the >> >> >> >> numbers you're using. >> >> >> >> >I knew those numbers were suspicious! =3D3DA0430120 can befactore=>d >> by =3D >> >8 >> >> >> >then 5 to yield 10753, which is a prime number. =3D3DA0So MATLABi=>s >> >> probably >> >> >> >zero padding to do the computations. =3D3DA0That's why yourdelay =>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 usingsome>> >> other >> >> >> recording software and not MATLAB bcuz MATLAB doesnt supportfour>> >> 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 you2N =>- >> 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 thosepoin=>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 showsup =>on >> >> >the left side of the 2N-1 outputs (the peak is at a point lessthan>> >> >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 thecenter>> >> >as being the 'no delay between them.' =3DA0So if the peak shows upon>> the >> >> >left side of the results (peak location less than N), your delay isN>> >> >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), whichwill>> 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 yourcalculated>> >> >result indicates a delay of 19 sample times. =3DA0Something iswrong.>> =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 yoursample>> >> >rate 44100, and your computed delay at 430101? =3DA0Please checkyour>> >> >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 wouldobviously>> 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 delayis>> >11 sample times between them, and =A0I presume that you got it by >> >eyeballing the data. =A0But your calculated delay is N - 430101 =3D3D19=>. >> >Since it's on the left or lower side of the result (the computeddelay>> >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 happento>> >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 helpbut>> >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 thatprime>> >factor of 10753. =A0Quite possibly, it's adding a few zero paddedpoints>> >such that N can be factored more favorably. =A0MATLAB will zero padthe>> >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 forN,>> >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 withthat.>> >> Hi, >> >> Can you suggest me what to do now? >> Also, sound source cannot be couple of miles away. the location of mic1>> is (0,0) and mic 2 is (0,60) and the location at which i made the noisei=>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 amountof>> time i captured the input from the microphones. As soon as i used toget =>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 =3D176=>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.
Reply by ●September 6, 20082008-09-06
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.
Reply by ●September 6, 20082008-09-06
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.
Reply by ●September 6, 20082008-09-06
> >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.
Reply by ●September 7, 20082008-09-07
>> >>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 becauseof>the little noise which is there. Therefore, when I plot this, I get agraph>which has a straight line, then these series of peaks (going fromamplitude>of 1 to -1) and again a straight line (which is almost zero) till theend.> > >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 youknow>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 maxvalue>at two mics were at 257118 and 257120 respectively. i think this isproper>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 942740which>is strange because the difference then is 148. > >Any suggestions?
Reply by ●September 7, 20082008-09-07
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.
Reply by ●September 8, 20082008-09-08
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.
Reply by ●September 9, 20082008-09-09
>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 thathave>> 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 datalength>> - you've got 942888 data points. =A0148 doesn't seem too bad whenusing>> 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?
