Audio Classification for Equipment Monitoring

Experienced engineers already do this by ear

Every maintenance engineer with a few years in a plant can walk past a pump and say it does not sound right. Often they are correct weeks before anything shows up on a gauge. The problem is that the engineer cannot stand next to 80 machines on three shifts.

Acoustic monitoring tries to capture that skill. Microphones listen to equipment continuously, a model learns what normal sounds like, and deviations raise a flag. For machines where faults produce a change in sound, which is a lot of rotating and pneumatic equipment, it can be a low-cost early warning.

It is not magic, and in a noisy plant it can be very hard. Knowing which situation you are in before buying microphones saves a lot of money.

What sound can reveal

Anomaly detection versus fault classification

Two approaches exist, and choosing the wrong one is the most common mistake we see.

Fault classification trains a model to recognise specific named faults, such as 'bearing outer race defect'. It needs many labelled recordings of each fault, and most businesses do not have them, because machines fail rarely and nobody was recording when they did.

Anomaly detection learns only what normal sounds like for each machine and flags anything unusual. It needs a few weeks of recordings of healthy operation, which every site can collect. It cannot tell you exactly what is wrong, but it tells an engineer which machine to go and listen to. For most small and mid-sized operations that is the right starting point, and it fits with the wider approach in our post on predictive maintenance for smaller operations.

Over time, engineers' notes on what they found when they investigated become labels. After a year or two, you may have enough examples to add classification for the common faults.

Microphones, placement and noise

• Contact microphones attached to the machine body pick up structure-borne sound and ignore much of the room noise. They are closer to vibration sensors in practice.
• Air microphones are cheap and easy to fit but hear everything, including the forklift reversing past.
• Ultrasonic sensors are the right tool for air and gas leaks, whose signatures sit above human hearing.
• Placement should be consistent. Moving a microphone ten centimetres changes what normal sounds like and resets the baseline.
• Operating state matters. A machine sounds different at full load, idling and starting up. Feed the model the machine's running state from the control system if you can.

Background noise is the main enemy. If a neighbouring press stamps every four seconds, the model needs to learn that as normal, and that press's own maintenance schedule becomes a factor in your false alarm rate.

Sound or vibration?

Vibration analysis is the established method for rotating machinery, with decades of engineering practice behind it. Accelerometers bolted to bearing housings usually catch developing faults earlier and more reliably than airborne sound.

Audio still has a place. It is non-contact, so it suits equipment you cannot easily fit sensors to. One microphone can cover several machines in a small room. It is cheap to trial with a phone-quality recorder before committing. And for leaks, cavitation and anything that hisses, sound is the natural signal.

If the machine is critical and you can bolt a sensor to it, start with vibration. If you cannot, or if the fault hisses, start with sound.

Where processing happens

Raw audio is data-heavy. Streaming continuous high-sample-rate audio from 50 microphones to the cloud gets expensive and may not be possible on a factory network. The usual pattern is to compute audio features or run a small model on an edge device next to the machine, send only summaries and anomaly scores upstream, and upload short clips around any flagged event so an engineer can listen.

That also helps with privacy. Microphones in a workplace can pick up conversations, so discarding raw audio at the edge and never storing speech is both good practice and easier to explain to staff.

A low-risk way to trial it

1. Pick three machines with a history of sound-related faults
2. Record four weeks of normal operation with fixed microphones, logging machine state
3. Train an anomaly model per machine and review every flag with the maintenance lead
4. Keep a simple log of what engineers found when they checked
5. After three months, compare flags against actual faults and near-faults

When we run these trials at SpiderHunts, the key output is the false alarm rate the maintenance team will tolerate. A system flagging twice a week with one real problem a month can be worth it. A system flagging daily will be ignored by week three. The analytics side sits within our data science work, but the engineers' judgement shapes the thresholds.

Frequently asked questions