I've started a hobby project which is to detect and count the number of impacts (for example someone clapping, bouncing a ball or hitting a boxing bag).

I've been reading and playing around (in java) with a few variations of total amplitude, FFT, IIR etc but with so much information and concepts to grasp (I'm normally a web/database developer) I can't figure out which is the right path to follow.

practically speaking I know i'll need a high frequency sample rate in order to distinguish between peaks and i think i'll need some form of filtered amplitude to distinguish between the crisp leading edge of the impact and the rumble noise that may follow.

I'm hoping someone here can point me in the right direction.

Thanks for your time!

  • 1
    $\begingroup$ Onset detection with a buffer can be a way to go. $\endgroup$ – jojek Jan 7 '15 at 20:47
  • $\begingroup$ i ended up using FFT and comparing to a forward and backward moving average. $\endgroup$ – pstanton Feb 9 '15 at 0:55

If your environment's noise level allows it, you can use a quiet no-brainer solution. Just make sure that the impacts have greater peak amplitude than the noise floor in every case.

  • Specify a threshold level based on previous experiments. This level has to be great enough for all the impacts you generate and you want to detect. If your signal crosses the level, you can assume, that an impact has happened.

  • If a detection has occurred, you can start a timer, that prevents unwanted re-detection for the same impact because you can't expect that your impact will be below the threshold for the next sound sample. For this reason, the timer has to run longer than the maximum detectable length of any impacts. Until the timer runs, you disable the threshold detection.

  • After the timer has fired, you can enable the threshold detection again.

sketch for the method

This method requires previous experiment and knowledge about the detectable impacts. You have to determine the minimum sampling rate that allows you to catch at least a few sample of the impact. Standard audio quality sampling rate would be good enough.

You can of course apply signal conditioning by filtering the signal with a digital filter, but this necessity is highly depends on your environment and noise floor.

Note that this is possibly the most no-brainer solution. There are many more sophisticated methods for this particular problem.

  • $\begingroup$ In principle this is a working solution, but it should be noted that this triggers for any kind of signal with sufficient level, be it dog barks, voices, car horns, you name it. So if the OP is specifically after transient events the level detector can be replaced with an onset detector that also measures the attack time for example. $\endgroup$ – Jazzmaniac Jan 7 '15 at 21:18
  • $\begingroup$ thanks for the answer simon, this is where i started. jazz, your comment is to the point. for example, the human ear/brain can detect/count successive drum beats even if they are close together (ie not quite a roll) however the amplitude in this scenario would never drop back to base. i'd like to be able to cope with other noise to a reasonable extent. i'd also like to cope with non-events such as the user bumping the mic which generally would be more of a clip. i'm not asking for a complete solution but a few prods in the right direction! some filter might help. FT isn't going to help is it? $\endgroup$ – pstanton Jan 7 '15 at 21:27
  • $\begingroup$ and great diagram! $\endgroup$ – pstanton Jan 7 '15 at 21:27
  • $\begingroup$ jazz, yes, totally agreed. The usability is highly depends on the environment where the system is deployed. $\endgroup$ – tiborsimon Jan 7 '15 at 21:46
  • $\begingroup$ pstanton, for advanced pattern recognition (the transient of the detectable impact is it's signature, it's pattern. not necessary one transient, but a transient set) you can utilize the cross-correlation function. it measures the similarity between two waveforms. take the given transient signature(s) and one piece of the windowed input signal (the two may match in length), and you can get the cross-correlation function(s) for the given window. higher the function value, the higher the possibility of an actual impact. this method could be used even in noisy environment. $\endgroup$ – tiborsimon Jan 7 '15 at 22:06

A good advice would be to load the sound file into Audacity, and look at the spectrogram (FFT) representation in there. Impact (impulse) sounds are easily spotted visually in the spectrogram, as they're sharp vertical lines. Echo's may trail, so the right side is usually a bit fuzzy.

That also gives you the simple algorithm to detect them: for every FFT bin, look for a sharp and sudden increase in energy.

  • $\begingroup$ what sample rate and fft sample size would you recommend? i am coming across the trade-off between temporal resolution and frequency resolution .. ie the shorter the sample the less fft buckets. i'm assuming i need a short time-frame rather than many fft samples/buckets? $\endgroup$ – pstanton Jan 18 '15 at 23:56
  • $\begingroup$ That's one of the reasons you should play around in Audacity. It has a dropdown control to set the FFT length. We don't have your data; you're the best person to judge it. That said, less than 256 buckets is going to hurt for statistical reasons. $\endgroup$ – MSalters Jan 19 '15 at 9:58
  • $\begingroup$ maybe i'm looking at the wrong feature .. i'm using "analyze>plot spectrum" and i can only see one 'selection' at a time? therefore its difficult to compare sample to sample. is there a better view? $\endgroup$ – pstanton Jan 19 '15 at 22:44
  • $\begingroup$ The 2D FFT view is an alternative to the waveform display. To the left of each track in the main view there's a dialog; the very lop left is the [x] button to close that track. Next is the track name, and finally there's a dropdown arrow \/. From that menu, select "Spectrogram". $\endgroup$ – MSalters Jan 20 '15 at 8:27

If you are only after a certain few types of impact, then you might try this:

  1. Make clean recordings of each impact type - trim the recordings to remove extraneous samples before and after the impact.
  2. As you are sampling, run a cross correlation with each of the recordings.
  3. A peak in a cross correlation indicates an impact of that type.

You will want to use the lowest sampling rate that still delivers recognizable recordings - this is to reduce the processing load. I would try using 8kHz - most sound cards can deliver this rate, even though it isn't commonly used.

Once you have the correlation working, you can do a real time plot of the correlation level and determine what levels to use for detection.
I would take the log of absolute value of the correlation, run that through a high pass filter with a cut off of 10Hz, then look for changes above a certain level. Doing it that way will let you detect a peak regardless of the input level - it works sort of like an automatic gain control, but it tracks the ambient sound level faster. The cutoff can be raised to anything lower than the frequencies in the onset of the impact, and it will still work.

  • $\begingroup$ Have you actually tried this? In my experience, this performs much worse than you would expect, specifically for events that are not repeated absolutely identically. That means you can detect the exact impact you recorded, but not another impact that sounds identical but happened another time. The space that contains similar sounding events is quite large (depending on the signal) and it's not unusual to find two signals with nearly identical perceived sound that correlate very weakly. $\endgroup$ – Jazzmaniac Jan 9 '15 at 18:34
  • $\begingroup$ Lowest sampling rate? That is the worst possible idea. Processing a 48 KHz signal on a 3 Ghz vector processor is massive overkill, no need for false economy. This is especially true for short sounds like this: an impact may be 10 ms which would be only 80 samples @ 8 kHz. $\endgroup$ – MSalters Jan 19 '15 at 10:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.