Find lost packets in a recording

When a call or a stream loses packets and the player does not conceal it, the audio has a hole in it: a few tens of milliseconds of digital silence in the middle of a word. Loudness, noise and spectrum are all fine, which is why nothing else in the engine sees it. The chain profile of POST /v1/analyze/profile counts those holes. It is a paid preset, like every profile except basic.

curl https://audiolab.tools/v1/analyze/profile \
  -H "Authorization: Bearer $AUDIOLAB_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/call.wav", "profile": "chain"}'

What comes back

Lens	What it is
chain.dropoutCount	The number of abrupt gaps of digital silence, 8 to 500 ms, inside sound.
chain.dropoutSec	Their total length in seconds.
chain.dropoutMaxMs	The longest one in ms, null when there is none. One lost packet is usually 20 ms; 60 ms or more is several in a row.

All three are validated. A recording under 2 s gets no reading.

How it decides

A gap counts when it is digital silence (every sample under half a 16-bit step, which a room or a microphone never gives), lasts 8 to 500 ms, and cuts the sound: in the 5 ms before and after it the level is within 20 dB of the active level of the recording. A natural pause, or the gate of a noise suppressor, lets the sound die away first and does not count. A gap at the very start or end of the file does not count either.

How far to trust it

Tested on 13 October 2026 on data the measure was not developed on, with the criteria written down before (PREREG-DROPOUT.md in the engine repository):

• On 160 constructed recordings of read speech with 11,337 gaps cut in, 8,411 of which cut sound: it found 99.8 percent of those, and 99.9 percent of the 8,406 gaps it reported were real (a gap counts when its start and length are within 2 ms of the one that was cut). The count was within 5 percent, or one gap, in all 160 recordings.
• No false alarm in 1,615 recordings without gaps: 40 clean, 40 with natural pauses of digital silence, and 1,535 recordings of synthetic voices in 32 situations (noise, reverberation, telephone band, clipping, fast speech).
• On simulated packet loss (20 ms packets set to zero, 47 recordings) it found all 1,539 gaps that cut sound, and every gap it reported was real.

What it cannot see

• It is a lower bound. Of the 2,554 gaps made in the packet-loss test, 1,539 cut sound. The rest fell in pauses or quiet passages, where a loss cannot be told from a pause, and they are not counted.
• A loss the player concealed (repeated, interpolated or filled with comfort noise) leaves no gap.
• Noise added after the loss fills the gap.
• The silence a codec puts in pauses is not a loss: 48 recordings through a low bit-rate telephone codec held 1,936 runs of exact zeros, none with sound on both sides, and none was counted.
• It was not tested on real calls with a known amount of loss.

The echo and slapback measure is not offered

The registry also has chain.slapbackDelayMs, chain.slapbackLevelDb and chain.slapbackScore: the delay and level of a delayed copy of the sound. They are not offered through the API or the MCP server, and the answer leaves them out.

The test says why. The measure found every constructed copy, on the right delay and level (100 percent, the delay within 0.03 ms). But it also reported a copy in 27 percent of the recordings that had none, almost all of them synthetic voices (53 percent for one voice, up to 100 percent for three accented ones), against 0 of 40 recordings of real speech. A measure that reports what is not there is worse than no measure, so it stays out until a second test on new data meets the criteria. Nothing was adjusted after the first one.

Related

• Pitch and voice quality
• Read the audio before you transcribe
• The lenses and their status