Where your audio goes: three routes

AudioLab.tools is run by AudioLaunch (KvK 54871204, Eindhoven, the Netherlands). Privacy questions: privacy@audiolab.tools.

If a recording contains a voice, it usually contains personal data of the speaker. In that case you are the controller of the recording and we are your processor. The browser route mostly keeps us out of that role, because we never receive the audio. For your account, billing and product analytics we are the controller ourselves; that is described in the privacy policy, not in the data processing addendum.

What goes where. The audio goes to the AudioLab API (audiolab.tools/v1). There are three ways in:

• A direct request with the file in the body.
• A URL that you give us; the API fetches the file itself, with protection against requests aimed at internal addresses.
• A signed upload for larger files: your client uploads the file to private storage with a one-time link tied to your account, and the API then reads it. The limit is 150 MB.

The MCP server is a thin client. The npm package @audiolabtools/mcp-server runs on your machine, but the measuring happens on the API. When you give it a local file path, it reads the file on your machine and uploads it to the EU-hosted API. Files up to 4 MB go in the request body; larger files, up to 150 MB, go over a signed upload. There is no offline mode.

Which service, which region.

• The functions that decode and measure audio run on Vercel in Frankfurt (region fra1).
• The database, authentication and the upload bucket are at Supabase in Frankfurt (AWS eu-central-1).
• Both providers are US companies. The data sits and is processed in the EU. For any access from the United States, the EU-US Data Privacy Framework and the standard contractual clauses (Commission Implementing Decision (EU) 2021/914, module 3, processor to sub-processor) are the basis.
• An audio request travels encrypted (TLS) through Vercel’s network to the functions in Frankfurt. A visitor outside the EU first enters at a node near them. We therefore say that processing and storage are in the EU, not that a request never touches a node outside it.

How long the audio stays.

• Direct request: the audio is decoded, measured and discarded inside the request. A WAV file is decoded in memory. A compressed file (MP3, FLAC, M4A and so on) is first written to the function’s temporary scratch space, which is deleted as soon as decoding is done, also when decoding fails; the function’s folder is temporary as well.
• Signed upload: the file sits in private EU storage. A sweep runs every 15 minutes and removes every file older than 45 minutes, so the longest a file can stay is 60 minutes, whether or not it was analysed. It is not deleted the moment its analysis finishes (since 22 September 2026), so that a second question about the same recording does not need a second upload.
• Function logs follow Vercel’s default retention for such logs: short, and without audio. We make no copy of our own.

What we do not do with it. We do not use your audio or your results for our own purposes: not to improve the engine, not to train models, not for advertising. We do not sell or share them. An uploaded file is readable only by the key that uploaded it.

What we keep. The API keeps no audio. Numbers and metadata are kept:

• For every API or MCP call we record the tool you used, the duration of the audio and a few headline measurements (integrated loudness, true peak, loudness range, crest factor, stereo correlation, a content-type label and tags, and for a target check the target and the verdict). This is used for your usage limits and account stats. These lines stay as long as your account exists; there is no automatic expiry.
• If a file has a name (because you analysed a URL, or saved a result), the name is stored with the numbers. A file name can identify a person. You can switch on anonymisation in your account; the name is then replaced by a code such as take-4f2a91c8.wav, the same code every time for the same file within your account, and the real name is not even sent to us. Files you upload through a signed link get a generated name.
• A report you share (/r/) is public to anyone who has the link, with measurement values and possibly a file name. It stays until you delete it or delete your account.
• Account data: your email address, plan, a hash of your API key (never the key itself) and usage counters. Deleting your account removes your keys, history and saved analyses; invoices stay for seven years because Dutch tax law requires it.
• If you save a run in the Voice AI QC view, we store the measured numbers, the limits you judged them by, the verdict and a label of your own, never the audio. If you share a stress-test report from the runner (--share), we store only the numbers of the report (error rates, intervals, criteria, the ids of the worst recordings and counts), never audio, transcripts or reference sentences; anything else in the report is dropped on arrival. Saved QC runs, shared stress-test reports, limit sets and live sessions stay until you delete them or delete your account. Each account can hold at most 500 runs and 500 reports.

Who else is involved. For your audio, two sub-processors:

• Supabase Inc.: database, authentication and the upload bucket, Frankfurt.
• Vercel Inc.: hosting of the site and the API; the functions that process audio run in Frankfurt.

Billing is our own processing, with Stripe Payments Europe (Ireland); Stripe never sees audio. The privacy policy lists more parties than the addendum because it also covers our own processing, such as billing and product analytics; the addendum lists only who processes your data on your behalf. We announce a new sub-processor at least 30 days in advance. You can object within that period and, if it is not resolved, end the agreement.

The data processing addendum. The addendum is part of our terms from the moment what you send contains personal data. You are the controller, we are the processor, and we process only on your instructions. We report a personal data breach without undue delay and at the latest within 48 hours of discovering it. On request we give you the information you need to show that we meet the addendum, and we cooperate with an audit by an independent expert, after reasonable notice and at your cost. You accept the terms and the privacy policy when you create an account or buy a plan. If you want a version signed by both parties, write to privacy@audiolab.tools.

When Route 1 is not suitable. Do not use this route:

• For recordings you have no lawful basis to send us. For special categories of data (Article 9, for example recordings made in care) you decide whether sending them is lawful, and you need a basis before you send them. AudioLab.tools has not been assessed for health data and holds no NEN 7510 or ISO 27001 certification.
• If your own rules require a processor agreement in a different form and that agreement is not yet in place. Use Route 2 or Route 3 instead.
• If your rules do not allow a processor whose parent company is in the United States. Our processing and storage are in the EU, but Supabase and Vercel are US companies. Route 2 or Route 3 avoids this.
• If you need audio to be gone faster than 60 minutes, or need a contractual zero-retention guarantee. The worst case for a signed upload is one hour.
• If you need a security certification. We do not claim one (security).
• For decisions that need a certified instrument. The measurements are not certified for legal, medical or broadcast-compliance decisions (terms).

What goes where. In the browser labs the audio is decoded by your browser’s WebAudio API and analysed as JavaScript on your own device. Your audio is never uploaded: the file is not copied or transmitted, and it is gone when you close the page. Microphone features work the same way. The outgoing check and the Calls check, the QC view (/voice-ai-check/qc), the live monitor (/live) and the stress-test report page are in this route too. The analysis can be audited in your browser’s developer tools.

The exception: HearLab live captions. HearLab’s live captions use the speech recognition built into your browser (the Web Speech API). In some browsers, Chrome among them, that feature sends the audio to an online speech service for transcription. That service belongs to the browser you chose and works under that browser’s terms. We receive nothing and give it no instructions, so it is not our sub-processor. Chrome 139 and later on desktop can keep recognition on the device when the page asks for it; the HearLab companion does not ask yet, and carries a notice that the audio may go to an online speech service. It starts the captions together with the level meter. If you want the audio to stay on your device, use HearLab’s scene recognition, which runs without speech recognition, or do not use the captions. The captions and check-ins you write stay in your browser’s localStorage (captions are restored if you return within seven days) and are not sent to us.

Which service, which region. For the analysis, none: it runs on your device. The pages themselves are served by Vercel. The only service that can receive audio in this route is the browser maker’s speech service, and only for HearLab captions.

How long, and what we keep. We receive no audio, so there is nothing of it to keep. Saving is a choice you make per result, and signing in alone saves nothing:

• If you are signed in and save a lab result, we keep the numbers and the file name (or the anonymised code), until you delete them or delete your account.
• If you save a run in the QC view, we keep the numbers, your limits, the verdict and a label, never the audio.
• If you press “Save this session” after a session on the live monitor while signed in, we keep a summary: the duration, the source, and the events with their type, time, numbers, reason and status. Never audio. It stays until you delete it or delete your account.

What does reach us in this route. The page itself runs product analytics: PostHog on its EU-hosted instance, without cookies and without writing anything to your device. It records page views, interactions with the interface (without the text of what you clicked, so a file name or a label you typed does not reach it) and JavaScript errors, and while you are signed in it labels these events with your account id, not your email address. Audio you analyse in the browser labs is never sent to PostHog.

Sub-processors. None for the audio. For the page and for saved results: Vercel and Supabase as above, and PostHog for analytics, which is our own processing and is described in the privacy policy.

The data processing addendum. Not needed for audio you analyse in the browser, because we do not receive it: the addendum itself says the browser labs are outside it. It applies to anything you send to the API or MCP server.

When Route 2 is not suitable.

• If you use HearLab’s live captions in a browser that sends audio to an online service, and the audio may not go to that service. Use scene recognition, or Route 3.
• If you need to analyse recordings in bulk, unattended or from a server. The browser needs a person and an open page; use Route 1 if the audio may go to the API.
• If your browser or a browser extension on a work machine is not under your control. The audio stays on the device, but you are responsible for what else runs on it.

Status. The sidecar @audiolabtools/live is being released on npm. This section describes what its code does; it is not a statement that you can install it today. A self-hosted or local setup of the whole service is not a standard product either; it is built per case, on request.

What goes where. The sidecar runs next to your own audio pipeline, on your own machine or server, and measures the audio there. The audio does not leave that system and is not sent to AudioLab. It sends nothing to AudioLab at all: it has no licence check and no update check. The only thing that can leave is an event: a name, a time, some numbers and a reason in plain words, for example “clipping, from 12:03:10 to 12:03:12”, never the audio and never a transcript. Events go only to the webhook you set, which is yours; they do not pass through AudioLab.

Identification is your choice. If an event refers to a stream, the stream id is a random code by default (s- followed by eight characters). It changes only if you set one yourself. A call id or a phone number can be personal data, because someone can link it back to a person, so use a code of your own that means nothing outside your systems.

Which service, which region, how long, what we keep, sub-processors. None of these apply to the audio or the events, because the sidecar sends nothing to us. We are then not a processor of that data. What your webhook receiver stores, and for how long, is your decision and your responsibility. If you also use Route 1 or Route 2 for other recordings, those routes keep their own rules. If a later version of the sidecar reports anything to AudioLab, this page will say exactly what, and whether the addendum then applies.

The data processing addendum. Not needed for audio and events that stay with you.

When Route 3 is not suitable.

• Until it is on npm.
• If you cannot run and maintain software next to your own pipeline.
• If you need the dashboards and the history that AudioLab keeps for hosted routes; events that stay with you do not appear there.
• If your webhook receiver is not itself covered by your own data protection arrangements.