Schema lock
Label set, taxonomy, and edge-case policy fixed with your team before anyone annotates. Verbatim-versus-clean, disfluency handling, and overlap conventions are decided here, where they are cheap to change.
AUDIO + SPEECH ANNOTATION
Your model is only as accurate as the transcript it learned from
Transcription, diarisation, forced alignment, events, emotion, and intent for ASR, voice, and speech-LLM teams. 150+ languages, kappa-gated, EEA-resident.
- 150+ languages
- Human QA
- EEA-resident
ANNOTATED CLIP
ANNOTATION, NOT COLLECTION
You bring the audio. We return the labels.
Annotation of speech you already hold: call-center archives, meeting recordings, in-cabin and field audio, voice-assistant logs. If you still need to capture or record the speech itself, that is a collection engagement, and our collection teams run it separately.
You bring
- Call-center recordings
- Meetings and interviews
- Broadcast and media
- Field and in-cabin audio
- Voice-assistant logs
We return
- Verbatim and clean transcripts TextGrid / JSON
- Speaker turns (diarisation) RTTM
- Word and phone timestamps CTM
- Sound and acoustic events CSV
- Intent, slots, and entities JSON
- GDPR Articles 6, 7, 9
- EU AI Act Article 10
- EEA-resident, Norway
- 30-day erasure SLA
WHAT WE ANNOTATE
Every layer of the signal, on one time axis
Nine annotation layers over the same audio: what was said (transcription, forced alignment, language ID, named entities), who said it (diarisation, emotion), and what else the model must ignore or act on (voice activity, sound events, intent and slots). One clip, every layer, time-aligned.
Beyond the clip: dataset services for speech-LLM and governance
- RLHF and preference data Response rating, preference comparison, and human evaluation for speech and audio model outputs.
- Spoken-QA and instruction sets Spoken question-answer pairs and instruction-response data for speech-LLM and audio-foundation training.
- PII redaction and de-identification Personal and special-category spans marked for removal, with a re-identification review on the result.
- Anti-spoofing and synthetic-audio labels Real-versus-synthetic, replay, and voice-conversion attack labels for voice-biometric and deepfake detection.
- Speech-to-speech and translation pairs Aligned source-target speech and post-edited translation across 300+ language pairs.
HOW WE LABEL
Every project clears the same six gates
Most label-quality problems are decided before annotation starts, in the schema and the guideline. We lock both with your team, then measure inter-annotator agreement on a calibration round and start production once it clears your kappa threshold.
Versioned guideline
Task definitions, segmentation rules, and ambiguity handling written down and version-controlled. The guideline is versioned and forms part of your EU AI Act Article 10 provenance record.
Calibration round
A pilot batch on a shared subset, labelled blind by multiple annotators. We measure inter-annotator agreement and timestamp tolerance, then refine the guideline where annotators disagreed.
Agreement gate
Production starts once the calibration round clears the kappa and timestamp tolerance agreed for your tasks. Targets are kappa at or above 0.8 for objective labels, 0.6 to 0.75 for subjective ones.
Production with adjudication
Annotation runs on self-hosted CVAT and Label Studio inside EEA infrastructure. Gold items are seeded throughout, and every annotator disagreement escalates to senior adjudication.
QA and delivery
Human QA is applied according to the agreed acceptance and sampling plan. The per-task agreement report, GDPR Article 30 processing records, signed DPA, and sub-processor list ship with the labels.
Six gates. Agreement is measured before production starts.
FORCED ALIGNMENT
Words locked to the waveform, within plus or minus fifty milliseconds
Loose word boundaries are invisible in a transcript and fatal in a TTS or lipsync model. We align word and phone timestamps to a plus or minus fifty millisecond tolerance, deliver them as TextGrid or CTM, and keep disfluencies marked rather than silently dropped, because the model has to learn them too.
token start – end ±50 ms
the 0.20s – 0.42s
model 0.50s – 0.92s
uh disfluency 0.96s – 1.10s
fails 1.14s – 1.46s
here 1.50s – 1.78s
WHERE MODELS BREAK
The conditions your model meets that your data missed
Production audio is far-field, telephony-band, in-cabin, overlapping, code-switched, and accented. A model trained on clean close-talk speech meets all of it on day one. Coverage across these conditions, annotated consistently, closes more of the gap than another thousand hours of easy data.
Full depth production depth, full QA
Routine covered, routinely annotated
On request sampled, smaller corpora
Not offered not a standing capability
Coverage tiers are representative of standing annotation capability, not audited
percentages. CleanReverberantBabble noiseMusic bgCode-switchAccented Close-talk mic Far-field array Telephony 8 kHz In-cabin VoIP / compressed
150+ languages, 50+ countries, native-speaker annotators across every condition above
HOW WE PROVE IT
We show the numbers, then co-define your targets
We do not sell an accuracy number. We report the metric types, word error rate against an expert reference, diarisation error rate, and inter-annotator agreement, then co-define the targets with your team and prove them on a calibration round before production.
90%
usable at delivery
>=0.80 inter-annotator agreement, objective labels
We report the metric types and co-define the thresholds with your team. No accuracy is sold as a guarantee.
THE ARTICLE 9 QUESTION
Voice is special-category only when it identifies
Most speech annotation treats voice as ordinary personal data under a GDPR Article 6 basis with Article 7 consent. Only speaker identification, using voice features to recognize a specific person, crosses into Article 9 biometric special-category, which triggers Article 9(2)(a) explicit consent and a DPIA. We assign every task its lawful basis before annotation starts, so your DPO inherits the analysis instead of reconstructing it.
Annotation task GDPR Art. 6 basis Consent DPIA
Transcription (verbatim / clean) Art. 6(1)(b) / (f) Art. 7 consent No
Forced alignment / timestamps Art. 6(1)(f) Art. 7 consent No
Diarisation (who spoke when) Art. 6(1)(f) Art. 7 consent Case-by-case
Sound-event / emotion / intent Art. 6(1)(f) Art. 7 consent Case-by-case
Speaker identification (voiceprint) ART 9 Art. 6(1) + Art. 9(2)(a) Explicit consent Yes
This describes YPAI processing posture, not legal advice. Final lawful basis is defined per engagement with your DPO.
WHAT SHIPS WITH EVERY BATCH
The audit trail ships with the labels
Every batch returns your client-schema outputs alongside the governance records of how the labels were made: the agreement report, the EU AI Act Article 10 data record, the signed DPA, and the sub-processor list.
File Type Document Availability
transcripts/*.TextGrid SCHEMA Transcripts (verbatim + clean) Aligned tiers, disfluencies marked.
Public diarization/*.rttm SCHEMA Speaker diarisation Who-spoke-when segments in RTTM.
Public alignment/*.ctm SCHEMA Word and phone timestamps Forced alignment in CTM.
Public events/*.csv REPORT Sound and acoustic events Onset and offset with class labels.
Public nlu/intent-slot.json SCHEMA Intent, slots, and entities NLU labels and named entities.
Public qa/iaa-report.pdf REPORT Inter-annotator agreement report Kappa, WER and DER, gold-set results.
Public governance/art10-record.pdf PDF EU AI Act Article 10 data record Provenance and bias-examination notes.
Pre-contract guidelines.md POLICY Versioned annotation guideline Task definitions and edge-case policy.
Public DPA.pdf CONTRACT Signed DPA + sub-processor list GDPR Article 28 processor terms.
Pre-contract COVERAGE AND WORKFORCE
A vetted contributor network under one EEA jurisdiction.
150+
Languages annotated
210,000+
Vetted contributors
Human QA
Per agreed acceptance and sampling plan
Acceptance unit
Defined with your team before production
50+
Countries
30-day
GDPR Article 17 erasure SLA
SCOPE A PILOT
Send us one hour of representative audio
Tell us the tasks, the languages, and the volume. We return a labelling plan, the relevant lawful-basis mapping, and a calibration approach. Deeper scoping happens in the reply.
AUDIO AND SPEECH ANNOTATION
Frequently asked questions
No. Voice becomes Article 9 biometric special-category only when it is processed to uniquely identify a person, such as voiceprint or speaker-identification tasks. Transcription, diarisation, alignment, and event labelling run under a GDPR Article 6 basis with Article 7 consent. We assign every task its lawful basis before work begins and document it for your DPO, so the Article 9 obligations attach only where they actually apply.
Yes. We can run annotation inside your own EEA infrastructure or a controlled environment, so the audio stays inside your boundary. You get a vetted multilingual workforce, kappa-gated QA and senior adjudication, already built and calibrated.
Inside the EEA by default, from intake to erasure. YPAI is a Norwegian company; EEA-only sourcing is available on request, with data residency, subprocessors and transfer controls defined per project. Erasure runs on a 30-day GDPR Article 17 SLA, and the member-state processing region is negotiable per engagement.
Your schema first: client-schema JSON for whatever your pipeline ingests, plus the standards your tooling already expects, RTTM for diarisation, TextGrid for aligned transcripts and prosody, CTM for word and phone timestamps, and CSV for events. Compatible with self-hosted CVAT and Label Studio. The labels are your work product, owned by you.
Human annotation, with QA applied according to the agreed acceptance and sampling plan. Models assist the annotators, and the deliverable is expert human judgement.
YPAI delivers verbatim and clean transcription, speaker diarisation, named-entity tagging on transcripts, intent and sentiment labelling, prosody and emotion markup, language identification, code-switching segmentation, and clinical speech annotation. Domain-specific overlays (automotive command grammars, clinical vocabularies, financial entities) are added on top of the base transcription layer rather than re-running annotation from scratch.
YPAI annotates speech in 150+ languages and dialects, with native-speaker reviewers concentrated in European and Nordic markets and significant coverage of major Asian, Middle Eastern, and Latin American languages. Code-switched and dialect-heavy speech (Norwegian dialects, Arabic dialect continuum, Swiss German) is handled by reviewers recruited from the relevant region.
Yes. In-cabin automotive speech (multi-occupant, road noise, infotainment cross-talk), industrial floor recordings, contact-centre audio with line-noise, and clinical exam-room conversations are recurring formats. Annotators are calibrated against the actual acoustic profile of the deployment. See <a href="/voice-recognition-for-automotive/">automotive voice recognition</a> for the in-cabin speciality.
Word-error-rate targets are set per engagement against the acoustic profile and domain vocabulary. Clean read speech in tier-1 languages targets sub-2% WER on the audited sample; noisy in-cabin or clinical speech is scoped to a realistic ceiling based on the input quality. Acceptance criteria are written into the SOW and measured on a held-out QA slice.
Yes. Voice is biometric and special-category data under GDPR Article 9, so YPAI runs explicit-consent flows, lawful-basis documentation, and Article 35 DPIA scaffolding. Voice prints are not re-used across engagements and recordings stay inside EU residency. Subject-rights requests resolve via the <a href="/gdpr/request/">data request form</a>. The data-handling stance for clinical voice is documented under <a href="/data-solutions/ethical-framework/">ethical framework</a>.
Yes. The provenance bundle (collection date, locale, recruiter pool, consent identifier, device class, post-processing) is structured for Article 10 dataset governance. Bias documentation, representativeness analysis, and the data-cleaning record are part of the deliverable. The bundle slots into the customer Technical File.
Both. Customer-supplied recordings are accepted under a DPA that documents the lawful basis and consent chain. Annotation proceeds once the provenance check is complete. Net-new collections are common when the customer corpus does not match production acoustic conditions. The collection arm at <a href="/data-collection/">/data-collection/</a> handles the recording side.
START WITH ONE HOUR OF AUDIO
Bring us the audio. We return the labels, the metrics, and the records of how they were made. DPA included, NDA on request, EEA from intake to erasure.
Scope an annotation pilot Reply inside one EU business day EEA-resident, Norway