Google Chirp 3 is a multilingual automatic speech-recognition model that converts spoken audio into text. Google documents it as the Chirp 3 transcription model in its Speech-to-Text V2 family, with the model identifier chirp_3. Its purpose is recognizing recorded or streamed speech, with language detection and transcription-specific features. The resulting artifact is a transcript and the metadata supported by the selected recognition method, rather than generated speech or an open-ended assistant answer.
The producer distinguishes streaming recognition, synchronous recognition for short clips and batch recognition for longer recordings. Choose the mode according to the source audio and the required result. For a short voice note, a completed text response may be sufficient. For an interview or recorded call, a batch result with speaker information can be more useful. For live captions or a spoken-command interface, keep intermediate text distinct from the final recognition result and preserve the audio interval it describes.
Prepare audio in the encoding expected by the recognition implementation. Google’s Chirp 3 examples use automatically detected decoding for recorded files and explicit decoding for a raw streaming configuration. The associated V2 decoder reference lists WAV PCM or companded audio, FLAC, MP3, Ogg/WebM Opus and AAC in MP4, M4A or MOV containers, among its supported encodings. A container name does not replace the actual codec and sample configuration. Preserve clear speech and avoid severe clipping or unnecessary conversion that loses audible detail.
Chirp 3 can identify and transcribe the dominant language automatically, and a set of expected locales can narrow its recognition choices. Language availability differs by method and feature. The transcription language list is broader than the diarization list, so a language being recognized does not establish that every speaker or timing feature applies to it. Use the locale that matches the recording and retain code-switched names or specialist terms for review. A detected language label is part of the result, not evidence that all unusual words were recognized correctly.
Speaker diarization groups speech by voice in a single-channel recording. Google provides a batch-transcription example with speaker information per word. For an interview, retain those labels with the recognized text and compare speaker changes with the recording before attaching actual names or roles. Similar voices, interruptions and overlapping speech can make attribution difficult. Keep the channel arrangement of the source and the intended speaker-review task clear instead of treating a label as independently verified identity.
Timing is also method-specific. Streaming recognition provides utterance-level timestamps, while the maker’s file-recognition guidance describes optional word timing with a possible transcription-quality trade-off. Retain the metadata actually returned by the chosen method and review alignment alongside the wording. A captioning workflow needs both: readable recognized text and evidence that a timing boundary corresponds to the right sound. Google also warns that the returned word-level confidence value is not a true confidence score, so it should not be used to certify that a word is correct.
Speech adaptation supplies phrases and proper nouns that are likely to occur in the recording. The maker documents a dictionary of up to 1,000 phrases and recommends as few relevant entries as possible to avoid degrading recognition of other terms. For a technical presentation, prepare a short list of actual product names and abbreviations, then inspect them in the transcript. Biasing helps recognition consider a term; it does not establish that the term was spoken or replace a check against the audio.
The model provides automatic punctuation and capitalization, which the documented interface can disable. Google also describes a preview feature for custom transcription-format instructions, such as how a particular name or date should be written. Keep those instructions focused on formatting the recognized speech. A transcript that normalizes a date or capitalizes a brand still needs to preserve the spoken meaning. A summary, translation or factual analysis is a later use of the transcript, rather than something established by the recognition result itself.
The built-in denoiser is intended to reduce background music and environmental sounds such as rain or street noise. Google explicitly states that it cannot remove background human voices. Preserve that distinction when preparing a recording with overlapping conversation. Inspect noisy and quiet sections against the source instead of assuming a cleaner-looking transcript proves the interfering sound was removed. A useful result keeps uncertain passages identifiable for correction.
For streaming tasks, endpointing sensitivity changes when an utterance is treated as finished. The maker describes standard, short and supershort settings for increasingly brief expected speech. A faster setting can cut off a speaker who pauses mid-thought. Match the setting to natural dictation, a short sentence or a very brief command, and keep the final-result status with the transcript. For a finished file, review names, quantities, negations and speaker boundaries, then retain the chosen mode and source audio so the result can be checked or reused.
", "aboutText": "Google Chirp 3 is a multilingual automatic speech-recognition model that converts spoken audio into text. Google documents it as the Chirp 3 transcription model in its Speech-to-Text V2 family, with the model identifier chirp_3. Its purpose is recognizing recorded or streamed speech, with language detection and transcription-specific features. The resulting artifact is a transcript and the metadata supported by the selected recognition method, rather than generated speech or an open-ended assistant answer.\n\nThe producer distinguishes streaming recognition, synchronous recognition for short clips and batch recognition for longer recordings. Choose the mode according to the source audio and the required result. For a short voice note, a completed text response may be sufficient. For an interview or recorded call, a batch result with speaker information can be more useful. For live captions or a spoken-command interface, keep intermediate text distinct from the final recognition result and preserve the audio interval it describes.\n\nPrepare audio in the encoding expected by the recognition implementation. Google’s Chirp 3 examples use automatically detected decoding for recorded files and explicit decoding for a raw streaming configuration. The associated V2 decoder reference lists WAV PCM or companded audio, FLAC, MP3, Ogg/WebM Opus and AAC in MP4, M4A or MOV containers, among its supported encodings. A container name does not replace the actual codec and sample configuration. Preserve clear speech and avoid severe clipping or unnecessary conversion that loses audible detail.\n\nChirp 3 can identify and transcribe the dominant language automatically, and a set of expected locales can narrow its recognition choices. Language availability differs by method and feature. The transcription language list is broader than the diarization list, so a language being recognized does not establish that every speaker or timing feature applies to it. Use the locale that matches the recording and retain code-switched names or specialist terms for review. A detected language label is part of the result, not evidence that all unusual words were recognized correctly.\n\nSpeaker diarization groups speech by voice in a single-channel recording. Google provides a batch-transcription example with speaker information per word. For an interview, retain those labels with the recognized text and compare speaker changes with the recording before attaching actual names or roles. Similar voices, interruptions and overlapping speech can make attribution difficult. Keep the channel arrangement of the source and the intended speaker-review task clear instead of treating a label as independently verified identity.\n\nTiming is also method-specific. Streaming recognition provides utterance-level timestamps, while the maker’s file-recognition guidance describes optional word timing with a possible transcription-quality trade-off. Retain the metadata actually returned by the chosen method and review alignment alongside the wording. A captioning workflow needs both: readable recognized text and evidence that a timing boundary corresponds to the right sound. Google also warns that the returned word-level confidence value is not a true confidence score, so it should not be used to certify that a word is correct.\n\nSpeech adaptation supplies phrases and proper nouns that are likely to occur in the recording. The maker documents a dictionary of up to 1,000 phrases and recommends as few relevant entries as possible to avoid degrading recognition of other terms. For a technical presentation, prepare a short list of actual product names and abbreviations, then inspect them in the transcript. Biasing helps recognition consider a term; it does not establish that the term was spoken or replace a check against the audio.\n\nThe model provides automatic punctuation and capitalization, which the documented interface can disable. Google also describes a preview feature for custom transcription-format instructions, such as how a particular name or date should be written. Keep those instructions focused on formatting the recognized speech. A transcript that normalizes a date or capitalizes a brand still needs to preserve the spoken meaning. A summary, translation or factual analysis is a later use of the transcript, rather than something established by the recognition result itself.\n\nThe built-in denoiser is intended to reduce background music and environmental sounds such as rain or street noise. Google explicitly states that it cannot remove background human voices. Preserve that distinction when preparing a recording with overlapping conversation. Inspect noisy and quiet sections against the source instead of assuming a cleaner-looking transcript proves the interfering sound was removed. A useful result keeps uncertain passages identifiable for correction.\n\nFor streaming tasks, endpointing sensitivity changes when an utterance is treated as finished. The maker describes standard, short and supershort settings for increasingly brief expected speech. A faster setting can cut off a speaker who pauses mid-thought. Match the setting to natural dictation, a short sentence or a very brief command, and keep the final-result status with the transcript. For a finished file, review names, quantities, negations and speaker boundaries, then retain the chosen mode and source audio so the result can be checked or reused.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "8b191da7c804192da5ac797ad23bea85d2a96dcec6ec7d65aa6c1c8f6b73b1de", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "google/chirp-3Google Chirp 3 is a multilingual speech-recognition model for streaming, short recordings and longer batch transcription. It provides automatic language detection, punctuation, vocabulary adaptation and mode-dependent timing or speaker metadata. Its denoiser reduces background noise but cannot remove other voices.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Google Chirp 3 is a multilingual automatic speech-recognition model that converts spoken audio into text. Google documents it as the Chirp 3 transcription model in its Speech-to-Text V2 family, with the model identifier chirp_3. Its purpose is recognizing recorded or streamed speech, with language detection and transcription-specific features. The resulting artifact is a transcript and the metadata supported by the selected recognition method, rather than generated speech or an open-ended assistant answer.
The producer distinguishes streaming recognition, synchronous recognition for short clips and batch recognition for longer recordings. Choose the mode according to the source audio and the required result. For a short voice note, a completed text response may be sufficient. For an interview or recorded call, a batch result with speaker information can be more useful. For live captions or a spoken-command interface, keep intermediate text distinct from the final recognition result and preserve the audio interval it describes.
Prepare audio in the encoding expected by the recognition implementation. Google’s Chirp 3 examples use automatically detected decoding for recorded files and explicit decoding for a raw streaming configuration. The associated V2 decoder reference lists WAV PCM or companded audio, FLAC, MP3, Ogg/WebM Opus and AAC in MP4, M4A or MOV containers, among its supported encodings. A container name does not replace the actual codec and sample configuration. Preserve clear speech and avoid severe clipping or unnecessary conversion that loses audible detail.
Chirp 3 can identify and transcribe the dominant language automatically, and a set of expected locales can narrow its recognition choices. Language availability differs by method and feature. The transcription language list is broader than the diarization list, so a language being recognized does not establish that every speaker or timing feature applies to it. Use the locale that matches the recording and retain code-switched names or specialist terms for review. A detected language label is part of the result, not evidence that all unusual words were recognized correctly.
Speaker diarization groups speech by voice in a single-channel recording. Google provides a batch-transcription example with speaker information per word. For an interview, retain those labels with the recognized text and compare speaker changes with the recording before attaching actual names or roles. Similar voices, interruptions and overlapping speech can make attribution difficult. Keep the channel arrangement of the source and the intended speaker-review task clear instead of treating a label as independently verified identity.
Timing is also method-specific. Streaming recognition provides utterance-level timestamps, while the maker’s file-recognition guidance describes optional word timing with a possible transcription-quality trade-off. Retain the metadata actually returned by the chosen method and review alignment alongside the wording. A captioning workflow needs both: readable recognized text and evidence that a timing boundary corresponds to the right sound. Google also warns that the returned word-level confidence value is not a true confidence score, so it should not be used to certify that a word is correct.
Speech adaptation supplies phrases and proper nouns that are likely to occur in the recording. The maker documents a dictionary of up to 1,000 phrases and recommends as few relevant entries as possible to avoid degrading recognition of other terms. For a technical presentation, prepare a short list of actual product names and abbreviations, then inspect them in the transcript. Biasing helps recognition consider a term; it does not establish that the term was spoken or replace a check against the audio.
The model provides automatic punctuation and capitalization, which the documented interface can disable. Google also describes a preview feature for custom transcription-format instructions, such as how a particular name or date should be written. Keep those instructions focused on formatting the recognized speech. A transcript that normalizes a date or capitalizes a brand still needs to preserve the spoken meaning. A summary, translation or factual analysis is a later use of the transcript, rather than something established by the recognition result itself.
The built-in denoiser is intended to reduce background music and environmental sounds such as rain or street noise. Google explicitly states that it cannot remove background human voices. Preserve that distinction when preparing a recording with overlapping conversation. Inspect noisy and quiet sections against the source instead of assuming a cleaner-looking transcript proves the interfering sound was removed. A useful result keeps uncertain passages identifiable for correction.
For streaming tasks, endpointing sensitivity changes when an utterance is treated as finished. The maker describes standard, short and supershort settings for increasingly brief expected speech. A faster setting can cut off a speaker who pauses mid-thought. Match the setting to natural dictation, a short sentence or a very brief command, and keep the final-result status with the transcript. For a finished file, review names, quantities, negations and speaker boundaries, then retain the chosen mode and source audio so the result can be checked or reused.
POST /v1/audio/transcriptionsaudiotext| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits google/chirp-3 | Default— |
Fieldinput_audio | Typeobject | RequirementRequired | Values & limits | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, input_audio |
Parametermaterial_types | Contractaudio |
Parametermaterial_conditions | ContractThe example reads your actual nonempty PCM WAV file, encodes the complete file bytes as base64 and sends input_audio.format as wav. |
Lifecycle: synchronous_result_then_owned_library
GET /v1/media/tasks/{task_id} · exact task_id from an existing owned media record
GET /v1/media/assets/{asset_id}/content
GET /v1/media/assets
GET /v1/media/assets/{asset_id}
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Billing unit | Charge |
|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Billing unit— | Charge Input · Input tokens — / 1K tokens Output · Output tokens — / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| Configurationinput audio second | Rate schedule— | Billing unitper input audio second | Charge Input · input audio second $0.000533333333334 per input audio second |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_AUDIO_FILE:?Set the path to your actual PCM WAV recording}"\nexport AILOOT_AUDIO_FILE\npython3 - <<'PY_REQUEST'\nimport base64, io, json, os, wave\nfrom pathlib import Path\naudio = Path(os.environ['AILOOT_AUDIO_FILE']).read_bytes()\nif not (audio[:4] == b'RIFF' and audio[8:12] == b'WAVE'):\n raise SystemExit('Supply your actual PCM WAV audio file')\nwith wave.open(io.BytesIO(audio), 'rb') as recording:\n if recording.getcomptype() != 'NONE' or recording.getnframes() <= 0:\n raise SystemExit('Supply a nonempty PCM WAV recording')\nrequest = {'model': 'google/chirp-3', 'input_audio': {'data': base64.b64encode(audio).decode('ascii'), 'format': 'wav'}}\nPath('request.json').write_text(json.dumps(request, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/audio/transcriptions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o response.bin\n# Retain the complete original response, headers and actual X-Client-Request-ID.\n# Read existing owned records for recovery; do not resubmit an uncertain operation.\nComplete original response body, status and forwarded headers. No universal JSON shape, text field or task envelope is added by this handler.
GET /v1/media/tasks/{task_id}GET /v1/media/assets/{asset_id}/contentGET /v1/media/assetsGET /v1/media/assets/{asset_id}Keep every complete returned response, file and content part.
Retain the complete response and headers, every actual output, original returned identifiers and all usage fields. Recover the original operation without submitting creation again.
Retain the actual X-Client-Request-ID and complete response. Read the original owned assets and their exact signed content URLs; never resubmit an uncertain creation.
| Field | Type |
|---|---|
Fieldtext (when present) | Type |
Fieldusage (when present) | Type |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionThe JSON body or explicit canonical model ID is invalid. | Next stepRetain the response and correct the indicated request field. |
Response401 · authentication_error | ConditionThe Ailoot API key is invalid. | Next stepUse your authorized Ailoot API key. |
Response403 · permission_error | ConditionThe key group does not admit this method. | Next stepRetain the returned error details. |
Response404 · not_found_error | ConditionThe selected method has no admitted route. | Next stepRetain the returned error details. |
Response422 · price_unavailable | ConditionThe accepted tariff cannot obtain its required input quantity or bound. | Next stepRetain the response; use the input representation required by the accepted tariff. |
Response503 · | ConditionRequired storage, route, method price or reservation is unavailable. | Next stepKeep the complete original response. An uncertain reservation is not permission to resubmit. |
Response502 · server_error | ConditionThe original result, usage or settlement requires checking. | Next stepRetain the actual request ID and original response. Read the existing owned record; do not resubmit creation. |
Ailoot Ultra google/chirp-3
Use the method paths shown above.