Wind noise meter used to improve bird song recognition app.

Recently we had an email from a company who are developing a bird song recognizer who were having problems with wind noise corrupting recordings and giving inaccurate results.  The company,  iSpiny was interested in using our code for real time wind noise detection to indicate when high levels of wind noise would cause problems with their algorithm.  So while not directly related to audio quality it shows that our research has a wider possible application.  As we understand the wind noise detector is now being utilized within the mobile bird song recognizer app .  For more information see the following site;

http://www.spinysoft.co.uk/ispiny.html

if you are interested in using the algorithm with your own application there is the offline batch detector here,

https://github.com/kenders2000/WindNoiseDetection/

as well as a realtime method implemented for iPhone. (contact us for details)

 

Microphone wind noise – published in the Journal of the acoustical society of america paper

Our work into the perception and automated detection of microphone wind noise had been published in the Journal of The Acoustical Society of America. This paper discuss how wind noise is perceived by listeners, and uses this information to form the basis of s wind noise detector / meter for analyzing audio files you can access the Journal here:

Or if you don’t have access, the paper is will also be available here (the next couple of days)

http://usir.salford.ac.uk/id/eprint/32802

If you want to run the wind noise detection algorithm you can do so using the code here

https://github.com/kenders2000/WindNoiseDetection/

‘Pipgate’, Radio Four’s Pips, what happened?

‘The Pips’ are series six of short tone bursts transmitted on Radio 4, they are known as the Greenwich time signal and are intended to accurately mark the start of the hour. They have been transmitted since 1924, and originate from an atomic clock.

On the 21st July 2014 a listener wrote to the Radio 4 programme ‘pm’ to ask why the pips had been changed. The programme played the offending pips and the originals. (here is a link to the program, the item is at 28m 31s http://www.bbc.co.uk/programmes/b049y9pn)

Here is an ‘old’ pip:

and a ‘new’ pip,

You may think that ‘new’ pip sound harsher, by looking at the wave form and spectra we can begin to understand what has happened. Here are the two waveforms of the pips,

Waveforms of the two pips

Waveforms of the two pips

and the two spectra.

Frequency Spectra of the two pips

We can see from the spectra there are additional lines in the spectrum known as harmonics, comparing the two waveforms we can see that the ‘new’ pips appear to be similar to the older ones except that the peaks of the waveform have been flattened or ‘Clipped’ a little.

This clipping is a form of distortion, it occurs when the gain applied to the signal is to great or if there is a fault in a preamp and the amplifier is no longer able to properly replicate the signal at the input.  We can clearly hear the difference between the two signals and according to the concerned listener (and his cat) it has a very negative impact on the sound quality.  Denis Nolan, the network manager for radio 4, identified the fault as being due to a particular desk the signal was going through.

In our project we are writing an algorithm to perform a similar function to the upset listener, we don’t mean that our algorithm will write pithy letters to Eddie Mair, we want to build an algorithm to automatically detect when something like this has gone wrong and the sound is being distorted.  The way we are going about this is to simulate all sorts of types of faults on many different types of sounds, and then see if we can look for ‘features’ of the audio which seem to be very dependant on theses faults.  We can then build automated systems that look for occurrences of these features to locate them, and try and estimate how bad the error is from the features themselves.

You too choose two YouTubes…

In two previous blog posts we discussed a mixed picture of findings for the relationship between audio quality and real world usage/popularity of audio files on the website Freesound. In one of our Web experiments, Audiobattle, we found that the number of downloads for recordings of birdsong predicted independent ratings of quality reasonably well. In a follow up experiment, however, we found that this effect did not generalise well to other categories of sound – there was almost no relationship between quality ratings and the number of plays or downloads for recordings of thunderstorms or Church bells, for example.

For our next Web test, Qualitube, we reasoned that people might find it easier to compare samples if they were recordings of the same event. Continue reading

Wind noise detection open source program

We have a developed an algorithm which is able to measure the level of wind noise on your recordings. This algorithm is the result of research carried out for our project where we carried out perceptual studies about the effect of microphone wind noise on sound quality of recordings. We then developed an algorithm which was able to analyse audio files and detect wind noise and predict the level of degradation to audio quality.

This program is useful to people who may have a lot of audio files they want to quickly sort through to find versions of recordings without wind noise. Or if they want to quickly located regions in recordings which are free of problems. A possible application of this technology is to collect together many recordings of an out door concert and without having to listen to all recordings piece together the best quality files.

The program has been uploaded to GIThub, it is a command line program written in c/c++ and needs to be compiled first.

http://github.com/kenders2000/WindNoiseDetection/

from here you can download and compile the program to use in your own applications.

We would love to hear how you get along using the program and what you have been using it for. We will be expand the program to detect other common recording errors to

Handling noise

Handling noise occurs when a user brushes or knocks a recording device while recording is in progress.  There are two types of handling noises, rubbing type noises, as may occur as a device is brushed against clothing and more impulsive types of noise such as when a mic is dropped.

Here are is an example of handling noise.  The noises were recorded on an iphone and added to sounds taken from Freesound.

These type of sound can be highly disruptive, due to the proximity of the noise generating mechanism to the microphone diaphragm, these types of sounds can cause a significant reduction in signal to noise ratio.  It is our plan to design and implement a series of detection algorithms which can identify when these type of sounds may occur,  This can enable regions in sounds to be labeled automatically when this kind of problem occurs.

Institute of Acoustics: Sound Recording Techniques – Our presentation.

Today (Wed 26th March, 2014) Trevor is presenting some of our recent findings on the effect of distortion on perceived quality in music, as part of the Institute of Acoustics’ Sound Recording Techniques event.

Our talk is titled “How distortion affects the perceived quality of music: Psychoacoustic experiments” and slides for it can be found here (PowerPoint slides in .pdf format).

The Good Recorder iPhone app

Good news! Today sees the launch of the project’s first ever app – The Good Recorder. Absolutely free and available now via the iTunes store, or click here.

What is The Good Recorder?

Screenshot 2014-02-14 15.39.36The Good Recorder is a sound recording app (currently only for iOS 7 devices) designed to help users achieve high quality audio recordings by monitoring for common recording errors and providing feedback about them. Currently the app incorporates findings and algorithms from our previous work with wind noise. The plan is to further develop the app with auto-detection of handling noise and distortion as our research in these areas progresses. Continue reading

Wind noise recordings – Validating a Wind Noise Detector

Array of microphones used to capture wind noise

Array of microphones used to capture wind noise

After developing a microphone wind noise detector which is trained on simulated examples of wind noise (see my ICME conference paper),  rigorous proof of the algorithm’s success (or failure!) is required.  In fact the reviewers of this aforementioned paper suggested this.  To that aim I packed a car full with microphone stands, cables, preamps, and a number of recording devices and set off to collect some examples of wind noise.

The requirement for the location to collected these examples is that there is very low levels of background noise.  I found a location up upon Rivington Pike, north of Manchester.  There was a road which was closed for repair, ideal! as it means no traffic.  After a couple of false starts and some help from a kindly local man, I found a good location with, no road, rail, urban or air traffic noise.  I located a place away from trees, which can create a surprisingly loud level of rustling noise and set my microphones up.

Array of microphones used to capture wind noise

Array of microphones used to capture wind noise

Array of microphones used to capture wind noise

Array of microphones used to capture wind noise

I was using an Edirol R-44 to capture four channel of audio onto an SD card at 44.1 kHz sampling frequency.  I set up two measurement microphones, one with a wind shield, a sure SM58 dynamic microphone, a zoom H2 recorder and an iPhone taped to a stand.  Though one of my microphones sported a windshield, due to the particularly blustery conditions with 20 mph winds, wind noise was present on all recordings.  This made it all the more important that the background sound level was as low as possible as I intend to compute the wind noise level, assuming that the background noise level is negligible.

recording device used, 4 channels
recording device used, 4 channels
Calibration was carried out on the two measurement microphones by placing a calibrator on each, playing a 1 kHz tone at around 94dB and recording these sounds.  Now I can calibrate my recordings so that I can present data in the actual sound pressure levels recorded for these two microphones.  To calibrate the other devices is a little tricky, but a 1 kHz tone was played back over a loudspeaker at approx 1m distance and recorded on all devices simultaneously.  As I can now know the true sound pressure level from the calibrated measurement microphones, i can also compute the true level of this tone relative to the calibrated recordings and using this information calibrate the other microphones to within a few decibels.  To remove wind noise a narrow band-pass filter is applied centered on 1 kHz. Clearly there is some error due to the location of the microphones and and residual wind noise present within the pass-band, but this is not a significant problem.
Several hours later, and I am rather cold but have the data, now back to Salford set up my validation procedure.