Signals is a private audio-recognition platform. It lets you build a catalog of the audio your product needs to recognize — ads, jingles, broadcast segments, in-store spots — and then recognize that audio directly on a device, without sending any recording to the cloud.

If you've ever used an app that identifies a song playing in the room, you already understand the core idea. Signals brings that same capability to your own content, and it runs the match locally so your listening data never has to leave the device.

The problem it solves

Most audio recognition works by streaming captured sound to a server, which compares it against a central database and sends an answer back. That's fine when you have a reliable connection and don't mind the audio leaving the device — but it breaks down in a lot of real situations:

A retail location with spotty Wi-Fi still needs to confirm what played on its speakers.
A broadcast monitor has to keep matching even when the network drops.
A mobile app wants instant results without a round trip to a server.
A product team simply doesn't want raw microphone audio traveling to a third party.

Signals is built for exactly these cases. Recognition happens on the device, offline, in milliseconds.

How it works

The workflow has two clean halves: building a catalog in the cloud, and matching against it on the device.

1. Build the catalog. You upload your source audio and video into a project. Signals prepares each file and generates a compact fingerprint database — a .acrf file — from your current media. Rebuild it whenever your content changes.

2. Match on the device. You ship that database, plus the native matcher, inside your product. The matcher loads the catalog fully into memory and listens to short buffers of microphone audio. When it finds a match, it returns two things: the sound ID (which creative was recognized) and the offset (where in that creative the captured audio begins).

The key design decision is that catalog generation and on-device matching use the same fingerprint engine. Every hash lines up, so what you build is exactly what gets recognized — no drift between the two sides.

What makes it different

Fully offline at match time. No cloud lookup, no database queries, no audio ever leaving the device.
Fast. The catalog sits in memory beside the matcher, so results come back without a network round trip.
Compact and portable. One catalog file runs on phones and edge hardware, not just servers.
Governed, not chaotic. The runtime is private, but the catalog side still has the controls a real team needs: organizations and projects, owner/admin/member/viewer roles, and scoped API keys for automating uploads and builds in CI.

Detection modes

Signals supports three ways to recognize audio:

Offline detection — available now. The catalog and matcher run locally on a mobile, edge, or Linux device.
Online detection — available on request, for products that prefer cloud-assisted or centrally managed matching.
Live channel detection — currently in beta, for continuously monitoring broadcast, streaming, or other always-on audio.

Who it's for

Broadcasters verifying what aired. Retail media networks confirming in-store playback. Measurement and attribution teams. And product builders embedding recognition into Android apps or connected devices, where latency, bandwidth, and data ownership all matter.

In short: Signals gives your product ears — without giving up control of your data.

Want me to adapt this? I can produce a shorter marketing blurb, a docs-style intro page, an Astro page for the marketing site (e.g. /what-is-signals), or trim it to a specific word count.

slug	signals
threads	2

Signals

Signals

What Is Signals?

try

GetVak - Support

Signals

Signals

What Is Signals?

try