Machine Fault Detection from Sound

An experienced maintenance technician can walk past a compressor and say "that doesn't sound right". The skill is real, but it doesn't scale: the technician has to be there, the plant has more machines than rounds, and the knowledge leaves when the person does. Machine fault detection from sound tries to capture part of that first judgement from a recording, so that someone who isn't an expert can collect it and a model can do the first listen.

This guide is the hub for that topic. It covers where acoustic screening sits among the other condition-monitoring methods, what Saina's mechanical specialist covers, a real example comparing the base model and the specialist, how to record, how to write the request, and the published evaluation with every limit that comes with it.

Where sound fits among the methods

Acoustic screening is one of several ways to watch a machine's condition, and it is the cheapest to start. Each method has a place:

• Human listening rounds. A person walks a route and listens, sometimes with a mechanic's stethoscope or a screwdriver to the housing. Free apart from time, and good for obvious changes, but it depends on who walks the route.
• Vibration sensors and analysis. Accelerometers on bearings and housings, read by a route-based data collector or by permanently mounted sensors, with spectra analysed by trained people or software. This is the established method for rotating equipment. It often catches faults before anyone can hear them, and a trained analyst can say which component is failing. It costs more and needs expertise to read.
• Ultrasound. Contact or airborne ultrasound instruments pick up sound well above human hearing, used for early bearing wear, lubrication, leaks and electrical discharge.
• Condition-monitoring vendors. Companies that sell wireless sensors (vibration, temperature, sometimes ultrasound or current) with analytics and alerts as a service. You get continuous data and someone else's expertise, for a subscription.
• Training your own anomaly detector. Record your machine's normal sound for a while, train a model on it, and flag anything that sounds different. This works without any fault examples and is specific to your machine, but you need the data, the time and someone to maintain it.
• General audio tagging models. Open models that tag everyday sounds. They can say "engine" or "mechanical fan", not whether a bearing is worn.
• A decision model with a machine specialist. Send a short recording, a sentence about the machine and typed questions; get a probability for each option. No fault data of your own needed to start, and you write the questions.

Sound from a phone is a cheap first check. It does not replace vibration analysis on critical assets, and it should not be the last word on any machine that matters.

What the mechanical specialist covers

A specialist is a version of a model trained further for one domain, selected per request with one field (Introducing Saina specialists explains the mechanism). The mechanical specialist runs on Saina Helm 2 Omni 0.8B: add "specialist": "mechanical" to a request that names "model": "saina-helm-2-omni-0.8b". It reads text and audio, not images.

It was trained on seven CC BY 4.0 datasets: rolling-element bearings (the University of Ottawa UORED set and a stethoscope-on-phone bearing set), a rotating-machine test rig (KAIST), induction motors (lab microphone and smartphones), one 3D printer (a VORON 0.2) and one industrial air compressor in a factory.

What it can name:

• Rolling-element bearings: inner race, outer race, ball or cage faults.
• Belts: a loose belt.
• 3D printers: extruder or toolhead problems.
• Electric motors: only whether the motor sounds healthy. The seven motor faults in its data sound almost the same in its 16 kHz input, so it was not trained to name them.
• Air compressors: only normal or abnormal. The compressor data has no fault names.

A real example: base model against specialist

The home page's Machine fault example uses a 10-second recording of an industrial air compressor (CC BY 4.0, Shaikh, Jawarkar, Ahmed), with a Model and Specialist menu so you can compare both. The state is "The clip is a recording of an industrial air compressor in its working factory environment." These are the real scores, recorded 2026-10-16 on the revisions in production, rounded:

The base model hears a compressor and calls it normal. The specialist hears the fault. On the second question it leans towards an inspection, but with 0.64 against 0.34 it is not sure between inspecting and stopping. In decision mode with the default threshold of 0.8, that answer would come back with no selection and reason: "below_threshold", which is the right outcome: a person decides between those two.

Two caveats. This clip comes from the same public compressor dataset the specialist was trained on, so it is a favourable case, not evidence about your compressor. And it is one example, not a benchmark result.

How to record

From the specialist's card:

• Phone held against or next to the housing. The training data includes phone and stethoscope recordings. Close is better than across the room.
• 1 to 10 seconds. Clips over 10 seconds are refused, never cut.
• Machine running steadily. Not starting, stopping or changing load during the clip, unless that is what you are asking about.

Practices that help comparison over time: the same spot on the housing each time (mark it), the same phone if you can, and a note of the operating state. Files go in the request as base64 data URLs: WAV, FLAC, MP3, Ogg or WebM, up to 10 MiB.

How to write the state and options

The card's advice is to name the machine and how it runs in the state, and to offer a healthy option plus only the conditions possible for that machine.

curl https://api.saina.run/v1/ask \
  -H "Authorization: Bearer $SAINA_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "saina-helm-2-omni-0.8b",
    "specialist": "mechanical",
    "mode": "decision",
    "threshold": 0.8,
    "state": "The clip is a recording of a rolling-element bearing on a conveyor drive shaft running at constant speed, recorded with a phone held against the bearing housing.",
    "audios": ["data:audio/wav;base64,UklGRi..."],
    "questions": {
      "normal": {"type": "yes_no",
                 "question": "Is the machine operating normally (no fault or anomaly audible)?"},
      "condition": {"type": "single_choice",
                    "question": "Which condition does the machine in this clip have?",
                    "options": {"healthy": null,
                                "inner": "Inner race bearing fault",
                                "outer": "Outer race bearing fault",
                                "ball": "Ball (rolling element) fault"}}
    }
  }'

Illustrative; the shape follows the API docs, and the base64 string is cut short. For a motor, ask only the normal question: the specialist doesn't name motor faults, and offering them invites a guess. For a compressor, normal or abnormal is all the data supports. "healthy": null is a valid option with no description; the key is the label.

What to do with the answers: an accepted "no" goes to a technician check, an answer below threshold goes to a person (re-record, or listen), and an accepted "yes" is logged. How to flag uncertain AI decisions covers that branch.

The published evaluation, and its limits

The specialist's card reports 1,165 held-out clips (2,274 questions) from the seven training sources, each source counted once in the average: 88% for the specialist against 30% for the base model. By source:

These figures come with limits that matter as much as the numbers:

• Few machines. These are lab and workshop recordings of a small number of machines: a few motors, bearings and test rigs, one 3D printer, one compressor. Expect lower accuracy on other machines, mounts and rooms, and check it on your own recordings before relying on it.
• Machines outside its training data. On MIMII (fans, pumps, valves and slide rails) the specialist detects faults worse than the base model: 50% against 70%. For those machine types, test both, and expect the base model to do better.
• Machines only. With the specialist on, general audio accuracy drops from 69.4% to 56% on the base model's 21-source benchmark. Leave the field out for anything that isn't a machine.
• Nothing above 8 kHz. Audio is read at 16 kHz, so higher-frequency sound, where some early bearing defects first show, is not heard.
• Motors and compressors. Healthy or not for motors; normal or abnormal for compressors. No fault names for either.
• A screening aid. It is not a substitute for inspection, vibration analysis or a qualified technician, and not for safety-critical shutdown decisions.

Running it on site

The specialist is published as a complete model on Hugging Face (run-saina/saina-helm-2-omni-0.8b-mechanical, Apache 2.0) and loads on its own with saina 0.6.0 or later. A self-hosted server lists it in SAINA_MODELS beside or instead of the base model, pinned to a revision, so recordings stay on your network. Because a specialist is deployed separately from its model, a base model update doesn't change the specialist you tested.

Try it

Open the live demo, pick Machine fault, and switch the Specialist menu between none and Mechanical to hear the difference yourself (no account; 5 free runs). In the console, the Compressor fault preset takes your own recording. For other audio, such as speech, sound events and instruments, see the audio classification API guide.

Related posts

• Introducing Saina specialists
• Audio classification API
• Acoustic predictive maintenance: a practical routine
• Bearing fault detection from sound