Context
The project began at the hackathon of the Mechatronics, Energy & Intelligent Systems master's (University of Strasbourg, September 2025), in a team of four (Robin Gras, Noa Hisler, Sylvain Wanke and me), supervised by Dominique Knittel. The goal, automatically spot anomalous sound signals from rotating machines, which is the heart of predictive maintenance. We worked on unlabelled recordings under tight time limits, with rare and varied anomalies that cannot be learned one by one. The group finished 1st out of 10. I then picked the topic up again on my own, at home, to turn it into a genuinely usable piece of software, with cleaned data and a properly trained and validated model.
Approach / Solution
At the hackathon we explored several families of methods in parallel in MATLAB, cosine distance on averaged spectra, k-means, DTW, Isolation Forest, an autoencoder and deep models. The CNN + LSTM 1D model is the one that made the difference, clearly separating healthy signals from faulty ones, and it is what finally found the anomalous files. At home, I industrialised the whole thing into a desktop application (Python, PySide6, PyTorch, scikit-learn). You train the model, diagnose a signal, evaluate the performance (ROC curve, AUC) and calibrate the decision threshold. The app handles several machines, accepts all common audio formats (wav, mp3, phone recordings decoded via ffmpeg), records from the microphone, logs every diagnosis to track drift over time, generates PDF reports, and builds into a standalone executable with no Python installed. The protocol stays honest, the configuration is chosen on a labelled validation set alone, and performance is then measured on the test sets with no tuning on them.
Results
On the labelled validation, the model reaches an AUC of 0.956. Above all, the application detects 17 faults out of 17, where the group caught 13 out of 17 at the hackathon, a perfect recall across both challenges (5 anomalies out of 5 in Challenge 1, 12 out of 12 in Challenge 2). That perfect recall has a cost, a few false alarms (7 in Challenge 1, 4 in Challenge 2), because I set the threshold to never miss a fault. In predictive maintenance that is the right trade-off, and a slider lets you move it. Better to inspect a healthy machine than let a fault slip through. My takeaway, going from a hackathon prototype to a usable piece of software changes almost everything, clean data, a validated model, a calibrated threshold, a clear interface. What I could still do, grow the dataset since that is the real bottleneck, try other temporal architectures, and track the drift of a real machine over time.