Forums

similar sounds need to be identified.... ideas?

Started by NightHawk October 1, 2005
Jerry:
Thanks for the advice, quality stuff as usual... I was intrigued about the
neural net part... I do know their working concepts, but have never
implemented one, nor have all the knowledge to implement a sound
identifing network, but I think that a neural network implementation might
be best. Know where can I learn what I need?

Gigi:

Will look into array processing, never even heard of it. Also, Im
currently looking into covariance and correlation....


>I'd go with Jerry's advice to use several audio and/or vibration >sensors placed in various physical locations around the clay pots. > >But I would recommend the following processing: > >1. Array (vector) processing instead of scalar (1-D) processing: since >you have a vector measurement per time-point (e.g. if you have 5 >sensors, then at each sampling time you have a 5-element vector of >measurements). Therefore, if you're really serious about a good >solution, take a look at books about Array Processing. > >2. Do not use a regular FFT for spectrum estimation. For example, in >1-D instead of FFT use some AR (auto-regressive) estimator such as Burg >or Covariance. In vector cases there are appropriate extensions. > >Notes: >- Audio sensors (microphones) don't have to actually touch the object, >but vibration sensors usually do, so vibration sensors have a >disadvantage. >- The sensor position should be "standardized" and also the "hammer" >(it's velocity, hitting position, and hitting force). > >Gidi > >
This message was sent using the Comp.DSP web interface on www.DSPRelated.com
NightHawk wrote:


> ... I was intrigued about the > neural net part... I do know their working concepts, but have never > implemented one, nor have all the knowledge to implement a sound > identifing network, but I think that a neural network implementation might > be best. Know where can I learn what I need?
Sorry, no. I've been impressed by results I've seen, but our knowledge of the subject is on the same level. ... Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
NightHawk wrote:
> >NightHawk wrote: > >> There are 2 very similar sounds, and I need a method to automatically > >> identify if its of type 1 or type 2. Sounds of type 1 have a > manufacturing > >> defect, while sounds of type 2 have no defects. > >> > >> The problem is the sounds are very similar, and so far, I have tried > the > >> Fourier Transform to try and find something that makes each sound > unique( > >> one or more specific frecuencys present in items with or without > defect), > >> but so far no luck.... > >> > >> What other methods can I try to identify something that makes helps me > >> identify the type of sound?. > >> Please help me, as Im out of Ideas!!! > >> > >> Must be a somewhat speedy method(1 or 2 seconds at most for real time > >> audio sampling, processing, and test result). > >> > >> This message was sent using the Comp.DSP web interface on > >> www.DSPRelated.com > > > >What are the sounds? > > > > > The sounds are the result of hitting a ceramic "cone" with a hammer. When > the ceramic cone was not well cooked, its sound is slightly diferrent > because of the internal defects.
If you can, try to make some intensionally very bad specimens of whatever items you monitor. That way you have an extreme example of what you are searching for, and can possibly get a better clue of what to look for in the poor specimens. Apart from that, you might want to look at energy distributions in fundamentals and harmonics, and maybe try to estimate Q factors from f/BW data for the individual harmonics. Rune
NightHawk wrote:
> I was intrigued about the > neural net part... I do know their working concepts, but have never > implemented one, nor have all the knowledge to implement a sound > identifing network, but I think that a neural network implementation might > be best. Know where can I learn what I need?
You might start with the FAQ from Usenet comp.ai.neural-nets: http://www.faqs.org/faqs/ai-faq/neural-nets/part1/preamble.html -Will Dwinnell http://will.dwinnell.com
"Jerry Avins" <jya@ieee.org> wrote in message 
news:itmdnRtfAZW0jt3eRVn-vA@rcn.net...
> NightHawk wrote: > > >> ... I was intrigued about the >> neural net part... I do know their working concepts, but have never >> implemented one, nor have all the knowledge to implement a sound >> identifing network, but I think that a neural network implementation >> might >> be best. Know where can I learn what I need? > > Sorry, no. I've been impressed by results I've seen, but our knowledge of > the subject is on the same level. >
There's also the possibility that if you look at the stressed and the unstressed response you'll find an obvious difference in how the sound and defective pieces respond (or maybe your neural net will be able to discriminate more reliably). If you've got the time to get a signature twice for each piece then maybe squeezing the cone while taking the second signature will reveal something. Best of Luck - Mike
"Predictor" <predictr@bellatlantic.net> wrote in message 
news:1128248894.228322.74970@o13g2000cwo.googlegroups.com...
> > NightHawk wrote: >> There are 2 very similar sounds, and I need a method to automatically >> identify if its of type 1 or type 2. Sounds of type 1 have a >> manufacturing >> defect, while sounds of type 2 have no defects. >> >> The problem is the sounds are very similar, and so far, I have tried the >> Fourier Transform to try and find something that makes each sound unique( >> one or more specific frecuencys present in items with or without defect), >> but so far no luck.... >> >> What other methods can I try to identify something that makes helps me >> identify the type of sound?. >> Please help me, as Im out of Ideas!!! >> >> Must be a somewhat speedy method(1 or 2 seconds at most for real time >> audio sampling, processing, and test result). > > > The solution will require two parts: an appropriate feature extraction > (you mention trying FT), and a classifier which operates on the > provided features to render a classification (you didn't mention, > above, how you used the FT). > > A little creativity goes a long way toward making the classifier's job > easy. Obviously, just about any signal processing tool or trick that > your hardware will support is fair game. I'd suggest starting with > simpler alternatives since they tend to require less effort to > implement and to execute faster. I once read about a speech > recognition solution (for spoken digits, 0 to 9) which merely segmented > the digitzed sample of the users voice into 24 regions (4 bins in > amplitude, 6 in time). A fuzzy logic rule set was applied to the > counts of the samples which fell in each region to classify the user's > speech. > > Classifiers also come in a wide variety. Since you are posting this in > a DSP forum and have indicated familiarity with FT, I conclude that you > are most likely a DSP person, not a statistician or machine learning > person. That is fine. Some classifiers are easy to understand and are > effective at solving problems, especially when fed good features. > Again, I recommend starting with the simplest, such as linear > discriminant.
I certainly agree that this is the best conceptual approach: feature extraction and then classification. Since your initial attempts didn't work well, I assume that the resonant frequency(ies) aren't the same from good unit to good unit. One approach used in machinery vibration sensing to get past this type of limitation is to clock the analyzer to the rotation frequency. So, I wonder what would happen if you clocked the ADC to a multiple of the fundamental resonant frequency of the unit under test? Then, when you do an FFT, the result isn't in "frequency" (as in 1/t) but in "hits per rotation" or "hits per fundamental vibration cycle" - locked to the "machine". This implies a frequency multiplier to *lots* of samples per cycle of vibration. For that matter, is your sampling frequency high enough now? You may find that there are recognizable differences in the FFT if you provide it with this type of input. Maybe a long shot. Back to feature extraction and classification... If an FFT is somehow a good thing then the length of the sequences and the number of sequences is important to adjust if you want to have good classification. Not just any length FFT will do. If it's too long then temporal things get averaged more than you want. If it's too short then frequency characteristics get averaged more than you want. Then, will you compare many FFTs sequentially or what? What will you use for comparison in doing classification should always be in mind. If the sampling is done locked to the resonance then *maybe* temporal subtraction would be helpful - and you could do the subtraction on a sliding basis to find the minimum point. You may be able to see "good" (i.e. low) minimums and "bad" (i.e. high) minimums. Compare one good unit with itself (using a new trial) as a control. How good is the method when comparing a good unit to itself over multiple trials? If the variance is too great, then the method is probably unsuitable. It may be that the repeatability of some method is so poor that classification is impossible. Think of: False positives vs. false negatives in classification. There will be some rate of each. A false positive will say "here is a bad unit" when it's actually good. A false negative will say "here is not a bad unit - i.e. a good unit" when it's actually bad. You can generally improve one false rate at the expense of the other. Think of: "The more parameters you decide to use in feature extraction leading to classification, the higher the signal to noise ratio needs to be" Why? Because we have to assume that each parameter that is extracted has a signal to noise ratio that is not the same as others you might extract. And, we might assume that you will naturally gravitate to parameters that are "easy" to extract - thus "high" signal to noise ratio. As you add parameters then, it's likely that you will be adding ones with lower signal to noise ratio. So, as you increase the parameters you are including lower and lower signal to noise ratio cases - which pushes on the overall signal to noise ratio. It needs to go up. Well, at least this thinking works in simple cases like classifying acoustic signals in the presence of noise. Your "signal to noise ratio" situation may be different. Fred
> >"Predictor" <predictr@bellatlantic.net> wrote in message >news:1128248894.228322.74970@o13g2000cwo.googlegroups.com... >> >> NightHawk wrote: >>> There are 2 very similar sounds, and I need a method to automatically >>> identify if its of type 1 or type 2. Sounds of type 1 have a >>> manufacturing >>> defect, while sounds of type 2 have no defects. >>> >>> The problem is the sounds are very similar, and so far, I have tried
the
>>> Fourier Transform to try and find something that makes each sound
unique(
>>> one or more specific frecuencys present in items with or without
defect),
>>> but so far no luck.... >>> >>> What other methods can I try to identify something that makes helps
me
>>> identify the type of sound?. >>> Please help me, as Im out of Ideas!!! >>> >>> Must be a somewhat speedy method(1 or 2 seconds at most for real time >>> audio sampling, processing, and test result). >> >> >> The solution will require two parts: an appropriate feature extraction >> (you mention trying FT), and a classifier which operates on the >> provided features to render a classification (you didn't mention, >> above, how you used the FT). >> >> A little creativity goes a long way toward making the classifier's job >> easy. Obviously, just about any signal processing tool or trick that >> your hardware will support is fair game. I'd suggest starting with >> simpler alternatives since they tend to require less effort to >> implement and to execute faster. I once read about a speech >> recognition solution (for spoken digits, 0 to 9) which merely
segmented
>> the digitzed sample of the users voice into 24 regions (4 bins in >> amplitude, 6 in time). A fuzzy logic rule set was applied to the >> counts of the samples which fell in each region to classify the user's >> speech. >> >> Classifiers also come in a wide variety. Since you are posting this
in
>> a DSP forum and have indicated familiarity with FT, I conclude that
you
>> are most likely a DSP person, not a statistician or machine learning >> person. That is fine. Some classifiers are easy to understand and
are
>> effective at solving problems, especially when fed good features. >> Again, I recommend starting with the simplest, such as linear >> discriminant. > >I certainly agree that this is the best conceptual approach: feature >extraction and then classification. > >Since your initial attempts didn't work well, I assume that the resonant
>frequency(ies) aren't the same from good unit to good unit. > >One approach used in machinery vibration sensing to get past this type of
>limitation is to clock the analyzer to the rotation frequency. So, I
wonder
>what would happen if you clocked the ADC to a multiple of the fundamental
>resonant frequency of the unit under test? Then, when you do an FFT, the
>result isn't in "frequency" (as in 1/t) but in "hits per rotation" or
"hits
>per fundamental vibration cycle" - locked to the "machine". This implies
a
>frequency multiplier to *lots* of samples per cycle of vibration. For
that
>matter, is your sampling frequency high enough now? > >You may find that there are recognizable differences in the FFT if you >provide it with this type of input. >Maybe a long shot. > >Back to feature extraction and classification... >If an FFT is somehow a good thing then the length of the sequences and
the
>number of sequences is important to adjust if you want to have good >classification. Not just any length FFT will do. If it's too long then
>temporal things get averaged more than you want. If it's too short then
>frequency characteristics get averaged more than you want. >Then, will you compare many FFTs sequentially or what? > >What will you use for comparison in doing classification should always be
in
>mind. > >If the sampling is done locked to the resonance then *maybe* temporal >subtraction would be helpful - and you could do the subtraction on a
sliding
>basis to find the minimum point. You may be able to see "good" (i.e.
low)
>minimums and "bad" (i.e. high) minimums. > >Compare one good unit with itself (using a new trial) as a control. How
>good is the method when comparing a good unit to itself over multiple >trials? If the variance is too great, then the method is probably >unsuitable. It may be that the repeatability of some method is so poor
that
>classification is impossible. > >Think of: >False positives vs. false negatives in classification. >There will be some rate of each. >A false positive will say "here is a bad unit" when it's actually good. >A false negative will say "here is not a bad unit - i.e. a good unit"
when
>it's actually bad. >You can generally improve one false rate at the expense of the other. > >Think of: >"The more parameters you decide to use in feature extraction leading to >classification, the higher the signal to noise ratio needs to be" >Why? >Because we have to assume that each parameter that is extracted has a
signal
>to noise ratio that is not the same as others you might extract. >And, we might assume that you will naturally gravitate to parameters that
>are "easy" to extract - thus "high" signal to noise ratio. >As you add parameters then, it's likely that you will be adding ones with
>lower signal to noise ratio. >So, as you increase the parameters you are including lower and lower
signal
>to noise ratio cases - which pushes on the overall signal to noise ratio.
>It needs to go up. > >Well, at least this thinking works in simple cases like classifying
acoustic
>signals in the presence of noise. Your "signal to noise ratio" situation
>may be different. > >Fred > > > > > > > > > >
Thanks for the all the help guys... I will be taking new samples based on all the advice, and will perfomrm the analysis mentioned... Ill keep you informed. This message was sent using the Comp.DSP web interface on www.DSPRelated.com