Choose audio output for transcription by starting with the speech service's accepted inputs, then inspecting the actual file. A filename extension alone cannot tell you its codec, channel layout, or sample rate. Preserve usable source audio where possible, and verify any conversion before sending a larger workload.
This guide covers the handoff between media ingestion and transcription. It includes a local inspection command tested against a synthetic audio fixture. It does not claim that a transcription model was tested or that one format always produces better transcripts.
Write down the consumer requirements
Record the transcription service and model, accepted containers and codecs, maximum file size and duration, channel behavior, and upload method. These are separate constraints. A service might accept a format but require a different submission method for long recordings.
Keep those requirements beside your processing configuration. When a provider or model changes, review the input contract before assuming your previous settings remain suitable. For an existing recording, inspect what you have before converting it.
Separate container, codec, and sample rate
The container organizes media streams; the codec describes how audio is encoded. Sample rate describes the number of audio samples per second, while channel count describes separate audio channels. Treat them as individual properties in your validation record.
Changing an extension does not convert the audio. Likewise, increasing a declared sample rate cannot restore information absent from the recording. A larger output is not evidence of a more accurate transcript.
Google's Speech-to-Text best practices recommend matching explicit decoding configuration to the source and avoiding unnecessary resampling. Its guidance also distinguishes separately recorded speakers from voices already mixed together. Follow the documentation for the service you actually use; these recommendations are not a universal configuration for every provider.
Inspect a local file with ffprobe
With FFmpeg tools installed, run this command on a local file you are authorized to process. Replace audio.wav with its path:
ffprobe -v error -select_streams a:0 -show_entries stream=codec_name,sample_rate,channels:format=duration,size -of json audio.wav
The command selects the first audio stream and emits selected metadata as JSON. See the official ffprobe documentation for stream selection and output options. It reads metadata; it does not transcribe or transform the file.
We ran this inspection on a locally generated one-second mono WAV fixture at 16,000 Hz. The selected stream reported pcm_s16le, sample rate 16000, and one channel; the format duration was 1.000000. That verifies the inspection example on that fixture only, not compatibility with a transcription API or speech quality.
If no audio stream appears, stop and investigate. If the source has multiple audio tracks, inspect them before choosing one: the first track may not contain the language or recording you want. Missing metadata should remain unknown rather than becoming a guessed value.
Convert only to satisfy a concrete requirement
Use conversion when the consumer cannot accept the existing representation or when a measured operational constraint justifies it. Preserve the original artifact or a recoverable reference, and record the transformation applied.
| Situation | Next decision |
|---|---|
| Existing encoding is accepted | Evaluate the original before introducing conversion |
| Encoding is unsupported | Select a supported output and validate it |
| Separate speaker channels exist | Check the service's channel handling before mixing |
| File exceeds a submission limit | Check long-audio support or design segments with recorded offsets |
| Recording contains distortion | Inspect the source; format changes do not recover missing speech |
After conversion, repeat inspection and listen to representative passages. Check the start, middle, and end, plus any boundaries introduced by splitting. Keep segment offsets tied to the exact recording version if your application needs timestamps.
Keep ingestion and transcription outcomes separate
In a Tornado API workflow, retain the ingestion job ID and confirm delivery before handing the file to another service. The Python asynchronous job tutorial shows submission, bounded polling, and recovery using an existing ID.
A delivered file can still be rejected by a downstream service. Record the ingestion outcome separately from transcription acceptance and transcript quality. If access has expired, investigate the stored file and access mechanism before submitting the source again. The storage and retention guide explains that distinction.
Evaluate a representative sample
Select authorized recordings that reflect your expected languages, durations, speaker arrangements, and recording conditions. Check names and technical terms as well as ordinary speech. Record the transcription configuration and retain examples of both acceptable and unacceptable results.
Measure file acceptance and useful transcript output separately. A request completing successfully is not proof that its transcript meets your application's standard. Compare configurations on the same sample before making a general choice.
Also inspect the applicable ingestion usage basis: a smaller delivered audio file does not by itself establish a lower ingestion bill. Read the usage and costs guide before extrapolating.
Start with one authorized source and one intended transcription service. Inspect the delivered file, check its compatibility, and review the transcript before scaling. Use the first-workflow guide to establish the ingestion and delivery path first.