Coder Legion - Recent posts tagged detection

How to Reduce WAF False Positives by Classifying the Block First

Sun, 25 Oct 2026 02:25:24 +0000

A blocked legitimate request is a false positive. Cutting those blocks is useful only if the same change still stops the attacks you deployed the firewall to catch. SafeLine is a self-hosted web application firewall that filters and monitors HTTP traffic between a web application and the Internet, using policies to separate malicious requests from safe ones (https://docs.waf.chaitin.com/en/home). The supplied documentation does not describe a false-positive exception form, a per-field allow command, or a numeric sensitivity setting you can edit. What it does describe is a reverse-proxy placement, a console attack list with a detail view, several controls that can deny visitors for reasons other than an injection payload, and a published evaluation that reports different false-positive rates for Balance and Strict. This checklist uses only those facts.

Classify the event before you change policy

SafeLine is an HTTP and HTTPS reverse proxy developed on nginx. It receives traffic for the original site, removes malicious attack traffic, and forwards the remaining traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). When a test or a user hits a blocking page, open the web console attack list and click detail. That is the documented place to see what was recorded. A blocking page alone does not tell you whether the deny came from a web-attack policy, a rate limit, a challenge, or an authentication check.

Confirm the protected application is the one you think it is. Adding an application requires a domain, hostname, or IP, a listen port, an SSL option for HTTPS, and the upstream address SafeLine will use to reach the origin. The domain then has to resolve to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If DNS still points at the origin, or the upstream is a stale address, the console will not be a reliable picture of user traffic. Fix that routing first. Lowering detection will not repair a proxy that is not in path.

Separate attack denies from control denies

The product home page lists more than one way a visitor can be stopped. Treating every deny as a signature false positive leads to the wrong fix.

Web-attack defense is aimed at classes such as SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). A detail record in one of those classes, on a request the application must accept, is the usual meaning of a detection false positive.

Other documented controls deny clients that may be legitimate:

IP-based rate limiting throttles traffic that exceeds defined limits. The stated uses are DoS attacks, brute-force attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). A busy user or a health check can cross a limit that was set for abuse.
A CAPTCHA challenge is described as allowing human users while blocking crawlers and bots (https://docs.waf.chaitin.com/en/home). A client that cannot complete the challenge will be blocked even if the URL contains no attack payload.
An authentication challenge blocks visitors who do not enter the password (https://docs.waf.chaitin.com/en/home). That is an access gate, not a statement that the request was an exploit.
Dynamic protection, when turned on, encrypts HTML and JavaScript on each visit (https://docs.waf.chaitin.com/en/home). The docs do not call this a false-positive control. After you enable it, verify that the pages users need still work, instead of assuming encryption is unrelated to support tickets.
A web access control list is named as a core capability (https://docs.waf.chaitin.com/en/home). The supplied pages do not publish rule syntax, so this checklist does not invent an allow entry.

Write the class down in one sentence before you touch configuration. A search query blocked as SQL injection is a detection question. A checkout refresh blocked after the rate limit is a limit question. An API client blocked by CAPTCHA is a challenge question. Each one has a different next step.

Read Balance and Strict as a published tradeoff

The effect-evaluation table is the only false-positive measurement in the supplied sources. It uses 33,669 samples for each row (https://docs.waf.chaitin.com/en/home):

SafeLine Balance: detection 71.65 percent, false positive 0.07 percent, accuracy 99.45 percent.
SafeLine Strict: detection 76.17 percent, false positive 0.22 percent, accuracy 99.38 percent.

The same table prints ModSecurity Level 1 at 69.74 percent detection and 17.58 percent false positive, and the CloudFlare row labeled Free at 10.70 percent detection and 0.07 percent false positive. Those are the figures printed on that page. They are not a procedure for editing your own rules, and they are not a forecast for your application.

On that sample set, Strict detects more and also shows the higher false-positive rate. Balance shows the lower false-positive rate, 0.07 percent, and a lower detection rate than Strict. If the detail view shows ordinary application text being classed as an attack, and your priority on this published comparison is the lower false-positive figure, Balance is the row that matches that priority. If missing attacks matters more than the gap between 0.07 percent and 0.22 percent false positives, Strict is the row that matches that priority. Neither row means false positives are gone.

Operator checklist

Reproduce one blocked journey. Open the attack list and click detail. Record the class of the event. If there is no attack detail, do not invent a signature bypass.
Check domain, port, SSL, and upstream against the real origin, and check that the domain resolves to the SafeLine host. Correct a proxy miss before you discuss detection.
If the detail is a rate limit, CAPTCHA, or authentication result, adjust the question to that control. Turning off web-attack inspection will not explain a password challenge, and leaving a tight limit on a busy path will keep blocking people who never sent an exploit.
If the detail is a web-attack class on traffic you must allow, choose Balance or Strict using the published detection and false-positive pair. Record which figure you are optimizing for.
After any change, replay the documented samples against your own domain: a union-select SQL injection, an image-handler XSS payload, a path traversal toward /etc/passwd, a code-injection payload, and an XXE doctype (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A blocking page means that sample was defended. If those samples now succeed, coverage dropped. That is not a false-positive fix.
Replay a known-good journey in the same window: a normal page load, a form post with everyday punctuation, and a repeat request that should stay inside your rate limit. If dynamic protection is on, confirm HTML and JavaScript still behave for that journey, because the feature re-encrypts them on each visit.
Keep the detail note with the decision. A later reviewer should be able to see why Balance or Strict was chosen, and which control, if any, was the real source of the deny.

The deploy guide is not a tuning guide. It specifies Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, a minimum of 1 CPU core, 1 GB memory, and 5 GB disk, plus an ssse3 CPU check (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Those requirements tell you whether the instance can run. They do not set a false-positive budget. Environment values such as the console port, image tag, and Postgres password are install settings, not detection settings. Do not add unofficial scripts to suppress a parameter the console has already classified.

FAQ

How do I tell a false positive from a normal block?

Match the detail view to a request the application is supposed to accept. A web-attack class on that request is a false-positive candidate. A rate-limit, CAPTCHA, or password result can be unwanted, but it is a control outcome, not proof that attack detection misfired.

Will Balance mode remove false positives?

No. On the published 33,669-sample table, Balance shows a 0.07 percent false-positive rate, and Strict shows 0.22 percent. Lower is not zero, and the table is not your production log.

Should every path use CAPTCHA and authentication?

Not as a false-positive remedy. CAPTCHA is for separating human users from crawlers and bots. Authentication challenge blocks visitors who do not enter the password. Use them where that behavior is what you want. Applying both on every path will deny clients that web-attack detection would have forwarded.

Where is the blocked request explained?

In the web console attack list. Click detail to see the recorded event after the blocking page appears (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Can the install steps configure fewer false positives?

No. Installation covers the host requirements, the compose file, environment variables, starting the stack, and resetting the administrator account (https://docs.waf.chaitin.com/en/GetStarted/Deploy). False-positive decisions belong in the review checklist above: classify the detail, fix proxy setup, then choose between the published Balance and Strict figures and retest both attack samples and known-good journeys.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

How to Reduce WAF False Positives With a Cause Checklist

Sun, 25 Oct 2026 02:24:52 +0000

A false positive is not one event. On a reverse-proxy web application firewall, a blocking page, a captcha, a password prompt, and a throttled client can all look the same to the person who filed the ticket. Reducing false positives starts by naming which outcome you actually saw, then checking it against published detection data and the controls that were enabled. This checklist stays inside what the SafeLine documentation states. It does not assume an allowlist syntax, a custom exception API, or a tuning command that the cited guides do not describe.

SafeLine sits in front of the application as an HTTP and HTTPS reverse proxy. Clients reach the firewall first. It filters and monitors traffic, then forwards traffic it treats as safe to the upstream application. The product documentation describes that decision as policy: a set of rules that separate malicious HTTP traffic from safe traffic. Documented attack coverage includes SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, brute force, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). If a legitimate request contains a string that resembles one of those patterns, a detection block is possible. That is the narrow meaning of a semantic false positive. Every other interruption needs a different check.

Separate detection blocks from intentional controls

The same documentation lists controls that interrupt clients on purpose. IP-based rate limiting throttles traffic that exceeds defined limits, including denial-of-service patterns, brute-force attempts, and traffic surges. A captcha challenge is meant to admit human users and block crawlers and bots. An authentication challenge requires a password, and visitors who do not enter it are blocked. Dynamic protection encrypts HTML and JavaScript on each visit when that control is turned on (https://docs.waf.chaitin.com/en/home). None of those behaviors is described as a detection false-positive setting. If a checkout client, a monitoring probe, or a partner integration fails, confirm whether rate limiting, captcha, authentication, or dynamic encryption is enabled before you treat the event as a signature mistake.

Use a three-way label on every ticket:

Detection false positive: a normal request was classified as an attack such as SQL injection, XSS, or path traversal.
Control interruption: the client hit a rate limit, a captcha, or a password challenge.
Content change: dynamic protection rewrote HTML or JavaScript, which can surprise a client even when the request was not blocked as an attack.

Write that label into the ticket before anyone debates signatures. A later change in detection posture will not fix a password challenge, and turning off a challenge will not fix a real injection match.

Read Balance and Strict as a tradeoff, not a slogan

The effect evaluation on the product home page is the documented quantitative evidence for false positives. It uses 33,669 samples for each row. SafeLine Balance is listed at 71.65 percent detection, 0.07 percent false positives, and 99.45 percent accuracy. SafeLine Strict is listed at 76.17 percent detection, 0.22 percent false positives, and 99.38 percent accuracy. In the same table, ModSecurity Level 1 is listed at 69.74 percent detection and 17.58 percent false positives, and CloudFlare Free is listed at 10.70 percent detection and 0.07 percent false positives (https://docs.waf.chaitin.com/en/home).

Read those rows as a tradeoff, not as a promise about your own routes. Strict detection is higher, and the published false-positive rate is also higher. Balance keeps the published false-positive rate at 0.07 percent, the same figure shown for CloudFlare Free in that table, with lower detection than Strict. Accuracy is slightly higher for Balance than for Strict in the published table. If the goal is specifically to reduce false positives, the documented comparison points toward the Balance row rather than the Strict row. The guides cited here do not describe a console path or a command for switching those labels, so do not invent one. Treat the table as the decision input. Do not assume a documented switch exists until you can see one in your own deployment.

Do not extend the table either. It does not report latency, bypass rates on your application, or results for a custom rule pack. If you need a number the page does not publish, leave it unstated.

Confirm the attack list belongs to the right application

A false-positive review is useless if the record belongs to a different site. The application guide says SafeLine is a web application firewall developed based on nginx. It receives traffic for the original website, cleans malicious attack traffic, and forwards safe and reliable traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). When you add an application you set Domain, Port, an SSL option for HTTPS apps, and Upstream. Domain can be a domain name, a hostname, or an IP address. After that, you resolve the entered domain to the IP address of the server where SafeLine is located.

Before you call a block a false positive, check four facts:

The domain or hostname on the request matches the application entry.
The listening port, and the SSL option for HTTPS, match how clients actually connect.
Upstream is the real address of the original application, not a stale host.
The attack-list entry you opened is for that same application, and you opened detail rather than judging from the summary line alone.

The application guide also shows what a successful defense looks like. Sample probes for SQL injection, XSS, path traversal, code injection, and XXE should produce a blocking page, and the console attack list should show the event. Open detail for the specific record (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Use those samples only on a host you are authorized to test, and replace the example domain with your own, so you know the shape of a true positive. A legitimate URL that lacks those payloads and still appears in the attack list is the record worth keeping.

Run the checklist without undocumented features

Work in this order. Stop when the cause is explained.

Save the full request: method, path, query string, the headers you are allowed to store, and the response the user saw.
Label it as a detection block, a rate limit, a captcha, an authentication challenge, or a dynamic-protection side effect. Only the first label is a semantic false positive.
Open the attack list and the detail view. If there is no detection record, do not force the event into the detection bucket.
Compare the payload with the documented attack examples. A union-select string, an onerror handler, a traversal sequence, a code-injection string, or an XXE doctype is not a false positive just because a tester sent it on purpose.
If the request is ordinary application traffic and it was detected, note the published Balance versus Strict false-positive gap before you ask for a broader bypass.
If the interruption came from rate limiting, captcha, or authentication, change the question. Ask whether that control should apply to this client. The documentation defines what those controls do. It does not define a per-URL exception language in the pages cited here.
After any posture change you can actually confirm, re-test one known-bad sample and one known-good business URL. You want the bad sample blocked and the good URL absent from the attack list.

This sequence reduces false positives by refusing to mix causes. It also avoids promising an integration, a rule dialect, or a whitelist feature that these sources do not provide. If a review needs an exception mechanism, say that the cited guides do not document one, and keep the evidence pack: request, detail view, control state, and which published row you were comparing.

Does a lower false-positive rate always mean better protection?

No. In the published evaluation, Balance shows 0.07 percent false positives and 71.65 percent detection. Strict shows 0.22 percent false positives and 76.17 percent detection. Accuracy is 99.45 percent for Balance and 99.38 percent for Strict (https://docs.waf.chaitin.com/en/home). Lower false positives in that table come with lower detection. Pick the row that matches the risk you accept, and do not describe either row as universally better.

How do I tell a detection block from a challenge or a rate limit?

Check the user-visible result and the console record together. A detection event should appear in the attack list, and detail should describe that event (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A captcha, a password prompt, or throttling matches the documented captcha challenge, authentication challenge, or rate limiting behavior (https://docs.waf.chaitin.com/en/home). If the console has no attack detail, treat the case as a control interruption until evidence says otherwise.

Should I send the sample attack URLs to a live customer site?

Use them only on an application you are authorized to test, and replace the example domain with your own, as the guide instructs (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Their job is to show what a blocking page and an attack-list entry look like. They are not a false-positive test. A probe that contains a union select or a path-traversal sequence is expected to be blocked.

What if I cannot find an allowlist or exception command?

Do not invent one. The cited home page and application guide describe proxy setup, attack defense, rate limiting, captcha, authentication challenge, dynamic protection, and the Balance versus Strict evaluation. They do not document a false-positive exception syntax. Reduce noise by classifying the event, reviewing attack detail, and choosing the published row whose false-positive rate matches your goal.

What should the next reviewer keep so the debate is not repeated?

Keep the request URL, the control that was enabled, whether attack detail existed, and the published figures you used: sample count 33,669, Balance false positives 0.07 percent, and Strict false positives 0.22 percent (https://docs.waf.chaitin.com/en/home). Also keep the application domain, port, SSL choice, and upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That pack is enough to decide whether the next step is a posture review or a control-scope review.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

SafeLine website: https://ly.cyberserval.tech/MqhYdmI
Demo: https://demo.waf.chaitin.com:9443/statistics
Official docs: https://docs.waf.chaitin.com/en/home
GitHub: https://github.com/chaitin/SafeLine
Pro offer: https://cyberserval.tech/landing/lto

Real-Time Speaker Diarization

Mon, 28 Sep 2026 10:06:57 +0000

Algorithms, web implementation and applications in drone detection by the acoustic fingerprint of their motors

This article presents the principles and practical implementation of speaker diarization – the automatic identification of the person speaking at a given moment in a continuous audio stream. Starting from the Fourier transform, the Mel scale and the MFCC coefficients, we explore classical and modern speaker identification algorithms, as well as the challenges of implementing them in the browser using the Web Audio API. In the second part, we show that the same set of techniques, applied to the signals emitted by the electric motors of unmanned aerial vehicles (UAVs/drones), can form the basis of an acoustic drone detection and identification system – a field with applications in security, air traffic management and critical infrastructure protection.

1. INTRODUCTION

In any conversation involving several participants – from a medical consultation to a board meeting or a journalistic interview – the question “who spoke?” is just as important as “what was said?”. Speaker diarization is the task of segmenting an audio stream into homogeneous regions attributed to a single speaker, answering the question “who speaks when?” without assuming prior knowledge of the identity of the people involved [1].

The field has evolved dramatically over the last decade: while in the 2000s systems relied on Gaussian mixture models (GMM) and the BIC distance, today deep neural architectures produce speaker embeddings (x-vectors, d-vectors) with performance exceeding human discrimination ability under noisy conditions [2, 3]. Nevertheless, efficient implementation in resource-constrained environments – browser, embedded systems, edge computing – remains an open challenge of immediate practical interest.

This article has a twofold purpose:

to present, in sufficient technical detail, the mathematical and algorithmic foundations of speaker diarization, with an emphasis on implementability in JavaScript using the Web Audio API; and
to show that the same acoustic feature extraction pipeline can be adapted for detecting and identifying drones by the sound signature of their motors – an active research field with applications in national security, urban planning and airspace protection [4, 5].
FROM WAVEFORM TO FINGERPRINT: AUDIO SIGNAL PROCESSING

2.1 The Fourier transform and the frequency domain

The raw audio signal is a sequence of acoustic pressure values sampled at a fixed rate (typically 44,100 Hz for consumer audio). Although the time-domain waveform contains all the information, it is not suitable for extracting discriminative speaker features. The Discrete Fourier Transform (DFT) – and its efficient implementation, the FFT – projects the signal into the frequency domain, revealing the distribution of energy across sinusoidal components.

In practice, the analysis is performed on short windows (typically 20–40 ms), with overlap (10–15 ms), yielding a time-frequency representation called a spectrogram. Each window is multiplied by a window function (Hamming, Hann) to reduce the effect of spectral leakage at the window edges.

2.2 The Mel scale and the filterbank

Human perception of pitch is not linear with respect to physical frequency: the ear discriminates low frequencies more finely than high ones. The Mel scale, proposed by Stevens, Volkmann and Newman in 1937, approximates this non-linearity:

A mel filterbank consists of M triangular filters distributed uniformly on the Mel scale, applied to the FFT power spectrum. The energy of each filter is log-compressed (to compress the dynamic range, similarly to the auditory system), yielding a vector of M values representing the mel spectrum of the current window. Typical values are M = 26 or 40.

2.3 Mel-Frequency Cepstral Coefficients (MFCC)

The MFCC coefficients, introduced by Davis and Mermelstein in 1980 [6], are obtained by applying the Discrete Cosine Transform (DCT) to the log-energies of the mel filterbank. The DCT decorrelates the components (since the mel filterbanks overlap), condensing the vocal information into the first 12–13 coefficients:

The coefficient c₀ (k=0) corresponds to the total energy of the frame and is often excluded from the feature vector for speaker identification, since it reflects the loudness of speech rather than the identity of the speaker. The MFCC vectors c₁–c₁₃ capture the characteristics of the vocal tract – the shape of the oral cavity, its length, the position of the tongue – stable features of vocal identity.

The complete feature vector for a frame often also includes the delta coefficients (Δ-MFCC, the temporal derivative) and delta-delta coefficients (ΔΔ-MFCC), which capture the temporal dynamics of speech. To these are sometimes added the fundamental frequency (pitch, F₀) – estimated by autocorrelation on the time-domain signal – and the spectral centroid, which measures the “brightness” of the voice.

Key point: The performance of any voice identification system depends critically on the quality of feature extraction. Cepstral Mean Normalization (CMN) – subtracting the session mean from each MFCC vector – reduces the influence of channel characteristics (microphone, room acoustics). L2 normalization (projection onto the unit sphere) is a robust, temporally stable alternative that allows the Euclidean distance to be used as a consistent comparison metric.

3. SPEAKER IDENTIFICATION AND DIARIZATION ALGORITHMS

3.1 Gaussian Mixture Models (GMM-UBM)

The classical approach, dominant in the 2000s, models the distribution of each speaker’s MFCC vectors with a Gaussian Mixture Model (GMM). A Universal Background Model (UBM) trained on a large corpus of speakers is adapted by Maximum A Posteriori (MAP) estimation to the data of each specific speaker – yielding a personalized GMM at low computational cost [7]. Identification is performed by a likelihood ratio test against the UBM.

The limitations of GMM-UBM are its sensitivity to channel variations and the need for at least a few tens of seconds of training data per speaker. These limitations motivated the development of methods based on latent subspaces.

3.2 I-vectors and Factor Analysis

Dehak et al. (2011) [2] proposed representing a speaker session as a low-dimensional vector (typically 400) – the i-vector – which simultaneously encodes speaker identity and channel variables in a total variability subspace. The model assumes that the GMM supervector can be written as the sum of a background supervector and a total variability term: , where T is the total variability matrix and w is the session’s i-vector.

Classification is performed with Linear Discriminant Analysis (LDA) or Probabilistic LDA (PLDA), which separate intra-speaker variability from inter-speaker variability. I-vectors dominated the NIST Speaker Recognition Evaluation (SRE) competitions for almost a decade.

3.3 X-vectors and Deep Neural Networks

Deep neural architectures have redefined the state of the art in speaker identification. Snyder et al. (2018) [3] propose x-vectors: a DNN model trained for speaker classification on windows of a few seconds, from whose intermediate layers compact embeddings (typically 512-dimensional) are extracted. A statistical aggregation layer (mean + standard deviation pooling) allows processing of variable-length sequences.

X-vectors, combined with PLDA and data augmentation (added noise, simulated reverberation), reduced the identification error rate by 50–70% compared to i-vectors on standard benchmarks. More recent models – ECAPA-TDNN, ResNet-based speaker models – achieve even higher performance, with an EER (Equal Error Rate) below 1% on clean datasets [1, 8].

3.4 Diarization vs. Verification vs. Identification

Three related tasks must be distinguished: (1) Speaker verification – is person X the one speaking? (binary classification); (2) Speaker identification – which of N known speakers is speaking? (multi-class classification); (3) Speaker diarization – segmenting the audio stream into regions attributed to speakers without prior knowledge of their identity, with the number of speakers unknown a priori [1].

A typical diarization pipeline includes:

voice activity detection (VAD),
feature extraction,
clustering (k-means, spectral clustering, or DBSCAN on embeddings),
optionally re-segmentation with HMM or Viterbi.

The standard evaluation metric is the DER (Diarization Error Rate), the sum of the missed speech, false alarm and speaker confusion rates.

4. BROWSER IMPLEMENTATION: WEB AUDIO API AND NEAREST-CENTROID

4.1 The Web Audio API and the constraints of the browser environment

The Web Audio API [9] natively provides, in the browser, access to the microphone stream via getUserMedia(), signal processing with AnalyserNode (real-time FFT, configured via fftSize = 2048), and precise timing via AudioContext. Implementation in JavaScript imposes significant constraints compared to server-side systems: the lack of explicit SIMD for matrix operations, single-threaded execution on the main thread (although Web Workers and AudioWorklets partially alleviate this), and a latency of ~16 ms imposed by requestAnimationFrame.

These constraints make it impossible to run large DNN models (x-vectors, ECAPA-TDNN) directly in the browser without ONNX Runtime Web or TensorFlow.js – and even with these frameworks, real-time inference on models with millions of parameters is only marginally feasible on modest hardware. The practical alternative is a lightweight classifier: nearest-centroid with a Euclidean metric in the L2-normalized feature space.

4.2 The real-time feature extraction pipeline

The practical implementation processes frames of 2048 samples (≈46 ms at 44.1 kHz) on each requestAnimationFrame cycle. Only frames with RMS > θ (a configurable energy threshold) are included in the collection buffer of the current utterance – a simplified voice activity detection that is nevertheless effective under low-noise conditions.

At the end of an utterance (detected when speech recognition stops or via a silence timer), the raw MFCC vectors of the collected frames are averaged, and the mean is L2-normalized – yielding the L2 fingerprint of the current utterance:

This order – averaging the raw vectors, followed by normalization – is critical. Per-frame normalization followed by averaging causes vector cancellation: the mean of vectors on the unit sphere may be a vector of near-zero norm, devoid of discriminative power. Normalizing the raw mean produces a stable centroid, reproducible for the same speaker.

4.3 The nearest-centroid classifier with adaptive threshold

Each detected speaker is associated with a centroid – the L2-normalized (and re-normalized) mean of the last K fingerprints. A new utterance is identified by its Euclidean distance to each known centroid:

If the minimum distance exceeds a threshold θ, a new speaker is declared. The optimal threshold is , where is the Euclidean distance between the two known centroids – this is calibrated automatically after the first two speakers are detected. Before calibration, the initial threshold θ₀ = 0.5 works reasonably in the L2-normalized space, where typical intra-speaker distances are 0.05–0.25 and inter-speaker distances 0.5–1.4.

A further improvement: after K₀ = 5 utterances from the first speaker, the threshold is recalibrated from the observed intra-speaker variance: , where is the mean Euclidean distance of the samples from their centroid. This makes the system adaptive to the type of voice and the acoustic conditions of the room.

5. DRONE DETECTION BY ACOUSTIC FINGERPRINT

5.1 The acoustic signature of UAVs

Multirotor unmanned aerial vehicles (quadcopters, hexacopters, etc.) produce a characteristic sound signal, determined by three main sources:

the rotation of the brushless electric motors, which generates tones at the switching frequency of the ESC controllers and their harmonics;
the aerodynamic sound of the propellers – air-cutting noise (blade passing frequency, ) and blade-tip turbulence;
the structural resonance of the frame.

The BPF is the dominant and distinctive frequency: a typical quadcopter (DJI Phantom 4) with 2-blade propellers and RPM ≈ 8,000–10,000 produces a BPF ≈ 267–333 Hz. Models with different configurations (hex, octo, multiple blades) have distinct, identifiable spectral fingerprints [4, 5].

Unlike the human voice – wide band 80–8,000 Hz, variable formant structure – the sound of a drone motor is quasi-periodic, with energy concentrated in the BPF and its harmonics (2×BPF, 3×BPF...). This makes identification easier under ideal conditions, but more fragile to RPM variations (which depend on the maneuver being executed) and to urban environmental noise.

5.2 Transferring voice identification techniques to UAVs

Jeon et al. (2017) [4] demonstrated that a deep neural network trained on mel spectrograms of drone sounds can detect the presence of a drone with >95% accuracy at distances of up to 80 m in semi-controlled environments. Al-Emadi et al. (2019) [5] extended the approach to identifying the specific model (DJI Phantom vs. Parrot Bebop vs. background), using MFCC and CNN, obtaining 98% accuracy on the test set.

The parallel with speaker identification is direct: instead of the vocal tract, the acoustic signature is determined by the motor + propeller configuration; instead of formants, we track the BPF and its harmonics. The technical pipeline:

FFT → mel filterbank → MFCC → L2 normalization → nearest-centroid or DNN classifier

transfers almost without modification, with a few domain-specific adjustments:

Frequency band of interest: 100–4,000 Hz (vs. 80–8,000 Hz for voice);
FFT window size: 4,096–8,192 samples for better frequency resolution at low BPFs;
Number of mel filters: 32–64 (more, in order to capture the fine harmonics);
Augmentation with synthetic pitch-shifting to cover RPM variations.

5.3 Multi-microphone acoustic detection and localization

One advantage of acoustic detection over radar or LiDAR is the low cost of the sensors. A microphone array allows not only detecting presence, but also estimating the direction of arrival (DOA) through beamforming or MUSIC (Multiple Signal Classification). The time difference of arrival (TDOA) between pairs of microphones, combined with triangulation, can localize the drone in 3D space.

Emerging commercial systems (DroneShield, Dedrone – although predominantly based on RF and video) integrate acoustic detection as an additional layer, especially for small drones with a low radar signature. Recent research explores distributed microphone networks, processed at the edge computing level with centralized aggregation – an architecture that benefits directly from the lightweight feature extraction techniques discussed in Section 4.

5.4 Challenges and limitations

The main challenges of acoustic drone detection are:

Urban noise – road traffic, air conditioning, wind – spectrally overlapping with the BPF frequencies;
RPM variation depending on the maneuvers executed, which shifts the BPF by ±30%;
The maximum effective range, limited to 50–100 m in urban conditions (vs. 200–300 m in rural environments);
Detection latency – a rapid-response system requires inference under 200 ms, which limits model complexity.

The same challenges exist, by analogy, in voice identification in noisy environments: overlapping speech, variable background noise, emotional variations in vocal pitch. The solutions developed in ASR and speaker recognition – noise data augmentation, adaptive beamforming, robust VAD based on spectral energy – are directly applicable to acoustic UAV detection.

6. COMPARATIVE EVALUATION AND FUTURE DIRECTIONS

6.1 Lightweight vs. DNN: when is nearest-centroid sufficient?

The nearest-centroid classifier in the L2-MFCC space is viable in scenarios with a small number of speakers (2–4), relatively controlled acoustic conditions and latency requirements under 50 ms (execution in the browser or on ARM Cortex-M4+ microcontrollers). On the VoxCeleb1 dataset (7,000+ speakers), nearest-centroid with MFCC yields an EER of approximately 15–20%, compared to 1–3% for DNN models. The gap narrows significantly when the number of speakers is small and training data is abundant [1, 3].

For drone detection, where the number of models to identify is small (tens, not thousands) and the acoustic signature is more stable than the human voice, nearest-centroid MFCC achieves performance comparable to CNN models on benchmarks with SNR > 10 dB [4].

6.2 Integrating pre-trained models via ONNX Runtime Web

A promising direction for improving browser performance without sacrificing accessibility is the use of ONNX Runtime Web with WebAssembly (and, where available, WebGPU). Small models of the SpeakerNet or audio MobileNet type, exported in ONNX format, can run inference for a 2-second frame in under 100 ms on mainstream hardware, paving the way for lightweight x-vectors directly in the browser.

Similarly, pre-trained drone detection models (CNNs on 1–2 second mel spectrograms, with ~500K parameters) are small enough for ONNX Web deployment, with potential use in security applications accessible to the general public (e.g. mobile apps for citizens reporting aerial intrusions).

6.3 Privacy and ethical considerations

Voice identification systems raise legitimate privacy questions: collecting voiceprints constitutes processing of biometric data under the GDPR and similar regulations. Implementations that process exclusively locally (browser, edge) and do not transmit audio data or fingerprints to a server offer stronger guarantees than cloud solutions. The privacy-by-design principle recommends: local processing, volatile fingerprints (reset when the session closes), and explicit user consent.

In the drone domain, acoustic detection does not raise the same privacy issues as video surveillance, but national regulations on the interception of communications and airspace monitoring require clear legal frameworks for the operators of detection systems.

7. CONCLUSIONS

Speaker diarization – the automatic identification of the person speaking in an audio stream – relies on an elegant mathematical pipeline:

FFT → mel filterbank → MFCC → L2 normalization → nearest-centroid or DNN classification.

Browser implementation with the Web Audio API is feasible for scenarios with two to four speakers, provided that a few critical details are respected: excluding c₀ from the MFCC vector, averaging the raw vectors before normalization, and adaptive calibration of the decision threshold.

The same pipeline, with minor adjustments to the filterbank and analysis window parameters, proves effective for detecting and identifying drones by the acoustic fingerprint of their motors. The technical convergence between the two domains opens opportunities for knowledge transfer, shared datasets and unified multi-task architectures.

As UAVs proliferate in urban and peri-urban airspace, lightweight acoustic detection systems, deployable on low-cost edge devices, will become an essential complementary element of the aerial security ecosystem – and the knowledge accumulated in speech processing represents technical capital that transfers directly to this new field of applications.

REFERENCES

[1] Park, T.J., Kanda, N., Dimitriadis, D., Han, K.J., Watanabe, S., & Narayanan, S. (2022). "A review of speaker diarization: Recent advances with deep learning." Computer Speech & Language, 72, 101317. https://doi.org/10.1016/j.csl.2021.101317

[2] Dehak, N., Kenny, P.J., Dehak, R., Dumouchel, P., & Ouellet, P. (2011). "Front-End Factor Analysis for Speaker Verification." IEEE Transactions on Audio, Speech, and Language Processing, 19(4), 788–798. https://doi.org/10.1109/TASL.2010.2064307

[3] Snyder, D., Garcia-Romero, D., Sell, G., Povey, D., & Khudanpur, S. (2018). "X-Vectors: Robust DNN Embeddings for Speaker Recognition." Proc. ICASSP, Calgary, Canada, pp. 5329–5333.

[4] Jeon, H., Kim, Y., Kim, D., Kim, J., & Kim, J. (2017). "Empirical Study of Drone Sound Detection in Real-Life Environment with Deep Neural Network." Proc. 25th European Signal Processing Conference (EUSIPCO), Kos, Greece, pp. 1858–1862.

[5] Al-Emadi, S., Al-Ali, A., Mohammad, A., & Al-Ali, A. (2019). "Audio-Based Drone Detection and Identification Using Deep Learning." Proc. 2019 15th International Wireless Communications & Mobile Computing Conference (IWCMC), pp. 459–464.

[6] Davis, S.B., & Mermelstein, P. (1980). "Comparison of Parametric Representations for Monosyllabic Word Recognition in Continuously Spoken Sentences." IEEE Transactions on Acoustics, Speech, and Signal Processing, 28(4), 357–366. https://doi.org/10.1109/TASSP.1980.1163420

[7] Reynolds, D.A., Quatieri, T.F., & Dunn, R.B. (2000). "Speaker Verification Using Adapted Gaussian Mixture Models." Digital Signal Processing, 10(1–3), 19–41. https://doi.org/10.1006/dspr.1999.0361

[8] Anguera, X., Bozonnet, S., Evans, N., Fredouille, C., Friedland, G., & Vinyals, O. (2012). "Speaker Diarization: A Review of Recent Research." IEEE Transactions on Audio, Speech, and Language Processing, 20(2), 356–370. https://doi.org/10.1109/TASL.2011.2125954

[9] Smus, B. (2013). Web Audio API: Advanced Sound for Games and Interactive Apps. O'Reilly Media. ISBN: 978-1-449-33268-5.

[10] MDN Web Docs. (2024). "Web Audio API." Mozilla Developer Network. https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API