Sound comparison

Can anybody help me on developing a sensor instrument that can differentiate a dull ( hollow sound ) and a solid sound of a material when we light knock on it.. Right now i'm using piezeo speaker as the analog sensor...Before start ,I will test (light knock) on a good sample materials ( solid sound ) to record as the reference sound.. It can detect the sound but it cannot differentiate the sound.. is it due to the programming or what? :cold_sweat:

okay.. i have remove other topic...

Right now it can only detects patterns of knocks and illuminate the green LED it if the pattern is correct. I don't want to detect pattern...
I'm trying to compare sound.. can someone help me?

Maybe share some of the code you got so far?

Wk

just because I'm tired of seeing this question pop up with no movement:
http://skoba.no-ip.org/msgeq7/index.html

That's about the best you are going to get.

Sparkfun sells the msgeq7.

@ ameora
The reason that there are so few replies is that this is a near impossible project. Differentiating between sounds is not easy given unlimited memory and processing power. With the limited amount of memory and processing on the arduino you are wasting your time.

Maybe if ELM Chan's FFT Library for Arduino was used it could work?
http://arduino.cc/forum/index.php/topic,56331.0.html

the dull sound would have less high frequency energy compared to the high pitched frequency components of the normal sound...
correct me if i'm wrong,but sampling should also be very fast to accurately record high pitched components, but maybe...

qwertygin:
Maybe if ELM Chan's FFT Library for Arduino was used it could work?
http://arduino.cc/forum/index.php/topic,56331.0.html

the dull sound would have less high frequency energy compared to the high pitched frequency components of the normal sound...
correct me if i'm wrong,but sampling should also be very fast to accurately record high pitched components, but maybe...

This has potential. Offloading the spectrum analysis to the MSGEQ7 would help reduce CPU cycles spent sampling the audio and free them up for the actual fingerprint analysis. Essentially, you'd need to record as many example sounds as possible, play them into the device, note the spectrum spread, convert this into percentage values for each spectrum as compared to the others, keeping in mind volume variations and allowing a certain percentage of variation.

Test, repeat, repeat (repeat......) until you have a reasonable table of sounds to values.

It's more and more possible the more I think about it, though not easy at all. Decay of the sound will also play a big part when testing against certain sounds, as well. The MSGEQ7 has variable delay by just resetting and throwing away samples. Play with that as well... Keep the expected duration of your event in mind, and sample continuously, then go back by the appropriate amount of time and process your array then. This let's you do nothing but sample for most cycles then do the hard work only when a threshold is hit.

Have fun out there

brucethehoon,could you please elaborate

Offloading the spectrum analysis to the MSGEQ7 would help reduce CPU cycles spent sampling the audio and free them up for the actual fingerprint analysis.

how would MSGEQ7 help? isn't fft enough on its own?

FFT is great. In this instance it might even be REQUIRED because the MSGEQ7 is only 7 bands, while you can go nuts with FFT.

The biggest issue I found is that 8bit FFT is just not quite enough for some of the applications where I've ended up using the MSGEQ7. You can throw a 12bit ADC on it and get genuinely great results. Add in that the MSGEQ7 can sample at 160kHz+, and it's good for giving minute detail, though obviously, if you're going to use an external ADC, your bottleneck would be in the comms.

Anyhoo- regardless of which ends up being best, and why NOT try FFT first and see if it gives the desired result, this post is increasingly interesting to me.

I'm getting interested too, i'd like to try FFT and sound processing in general,just stuck with my drumkit for now...
but is ameora still interested? where is that guy?

so in conclusion does it need to interface with other software also? matlab?? i'm thought its a simple project.

I'm not sure where you got the impression there would be external software at all, much less matlab.

You could Do raw sample dumps to processing or other apps that can be interfaced with serial, though which MIGHT be easier due to the comparatively unlimited memory.

Why don't you back up and tell us exactly what you're trying to do?

Hi ! I am a newby and need some help with something.

I have an Arduino Micro and I would like to do the following :

I would like for my Arduino to detect sound trough a microphone and check if it is "glass breaking" or just some other random low frequency noice.
Is that poassible ?
do i have to use an active crossover driver or an improvised crossover driver using caps ?
Please let me know what you think..
Thank you !

I would like for my Arduino to detect sound trough a microphone and check if it is "glass breaking" or just some other random low frequency noice.
Is that poassible ?

I would say not.

do i have to use an active crossover driver or an improvised crossover driver using caps ?

No I don't seem how that would help you.

The main components of breaking glass are high frequencies, I would have said.

I only really think of crossovers in respect of loudspeakers - what is their purpose here?

AWOL:
The main components of breaking glass are high frequencies, I would have said.

And, apparently, TI has everything one needs including a reference design...
http://www.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa389