2026-2027 project development phase – Ausculta Acoustic Auscultation for Machines
Developing a listening app to diagnose machines and devices
https://kyleohare.com/sound-diagnosis/auscult-browser.html
The URL above is the test location for the project, file updated daily / weekly
AUSCULTA is currently a browser-based acoustic diagnostic tool: record or upload a mechanical/electrical sound (car, appliance, small engine, audio gear), and it either matches it against a library of known fault signatures or lets you teach it a new one. Single self-contained HTML file, ~4,000 lines, no build step, no backend — everything runs client-side via the Web Audio API. In the future the app will be converted to an app for mobile phones and devices with microphones that can run the software without limitations.
Storage & persistencelocalStorage as the primary store, with the File System Access API for auto-write-to-disk on Chrome/Edge. The library auto-loads from auscult-library.json via fetch() on page load, which is why it needs an actual HTTP server. It’s built-in library entries are designed to diagnose car/truck, appliances, small engines, and audio gear.
The sound fingerprint — 38 dimensions
This is the core of the matching system: 20 log-spaced frequency buckets (active-bin-only averaging, computed via bucketSpectrum) plus 18 scalar features — centroid, spectral flatness (geometric/arithmetic mean ratio, i.e. Wiener entropy), crest factor, impact rate, inter-onset interval CV, spectral spread, flux, rolloff, skewness, kurtosis, spectral crest, attack time, decay time (10dB-fall time from peak), three sub-band crest factors (low/mid/high), centroid stability (frame-to-frame stddev), attack-zone centroid, and centroid permutation entropy (ordinal-pattern Shannon entropy — volume-invariant temporal complexity, distinct from stddev-based stability).
Everything L2-normalized, applied at matching time rather than storage time. Each entry carries its own frequency range, acoustic pattern type (periodic-impact, tonal, broadband-noise, or irregular-transient), severity rating, likely causes, and recommended action — that data is what drives the heuristic half of the scoring (scoreEntry), separate from the learned kNN matching against real recorded examples. Actual sound files are not stored anywhere, just the fingerprints of the sound file to conserve overall space on server(s) or the mobile device.
Matching
Pure k=1 nearest-neighbor cosine similarity — verified through extensive leave-one-out testing that k=1 beats k=3 averaging for this data. Confidence-boost weighting scales with example count per label, plus a “borrowed heuristic” system where a custom label that text-matches a built-in entry inherits its heuristic.
Signal processing / selective hearing
Two-formant speech rejection, startup-transient rejection, turn-signal rejection, ambient noise-floor calibration and subtraction, and an optional AC mains hum filter (two cascaded BiquadFilterNode notches at 60/120Hz or 50/100Hz, high-Q to stay narrow) and live clipping/low-gain warnings during recording.
UI
Dual analog VU meters (SVG needle gauges for output level and peak frequency) with JS-driven angle interpolation rather than CSS transitions — were needed because some browsers decompose an SVG rotate() attribute into a transformation matrix for CSS-transition purposes and interpolate that instead of the angle, which breaks visibly on large swings of the VU meter needle. Paired digital LED bargraphs. Live spectrogram canvas with DPI-aware rendering and min-max range color normalization (a naive per-frame-max approach saturates to a solid color wash on any flat/broadband signal — fixed this session). Guided batch-teach flow added.
The accuracy (the largest portion of this app to make it of work)
A long list of more sophisticated alternatives were tested rigorously against the real library and didn’t beat it: weighted/proportional distance formulas, cross-correlation, DTW, Naive Bayes, tolerance envelopes, bitwise/chromaprint-style hashing, PCA, mutual information weighting, SVM (tested with a real library, ml-svm), ensemble blending (measurably worse than either method alone), and convex hull bounding (mathematically impossible for this library size — needs N+1 points per class in N dimensions).
Mahalanobis distance was the one exception worth noting: tied the baseline exactly at best-tuned regularization, never beat it. Random Forest showed a real edge on average but with enough seed variance and retraining-cost concerns that it wasn’t shipped. The consistent conclusion: with most machine problem labels sitting at 1-2 examples, that data sparsity is the actual bottleneck, not the matching algorithm. Currently the sound fingerprint library has about 130 examples which isn’t enough. Teaching the app more examples should make the app much more accurate and a powerful device for diagnosing car problems, appliances, etc.