Converting audio formats for training: a checklist that catches the quiet failures

The interchange format, the order of operations, and the spot checks that catch the four conversion failures that actually happen.

Format conversion is the least interesting step in a data pipeline and one of the most common places to lose a dataset without noticing. The files still decode, the training still runs, and the problem surfaces later as an accuracy number a few points below expectation with no obvious cause.

What follows is a checklist: the interchange format, the order of operations, a batch recipe, and the spot checks that catch the four failures that actually happen.

Pick the interchange format first

WAV with 16-bit PCM is the right format for data read during every training epoch: universally supported, no decode cost beyond the read, and no ambiguity about what is inside. FLAC is the right format for the archive: lossless, typically 40 to 60 percent smaller than the equivalent WAV, and fast to decode.

Do not store the training copy in a lossy format unless the lossy condition is the point. Compressed formats cost decode time in every epoch, and more importantly their decoders differ. Encoder delay padding at the start of the file, pre-echo behavior, and stereo handling all vary between decoders and versions, which means two machines can produce different features from the same file.

Never encode a lossy file twice

A second generation of lossy encoding adds artifacts on top of artifacts, and the second generation is the one that shows up as a word error rate bump, because the first generation was already in the audio you tested with. Decode the compressed source to PCM once, do every other operation in PCM, and if a lossy deliverable is required, encode it once from that PCM at the end.

The same rule applies to any loop that reads and writes compressed audio, including quick scripts for trimming or gain. Write the intermediate as WAV, not as MP3.

The order of operations

Decode, downmix to mono, trim, resample, normalize level, write. Downmix first so the resampler filters one channel instead of two. Trim before resampling, because trimming reduces the work the resampler does and because the anti-aliasing filter rings briefly at file boundaries, and that ringing belongs in the silence you are about to remove.

Write the output with every parameter explicit. In soundfile, pass the samplerate and the subtype, for example subtype equal to PCM_16. Leaving the subtype to the default is how a float WAV twice the expected size gets written, and how a 24-bit file ends up inside a corpus that assumed 16.

A batch recipe

Four habits that keep a large conversion run honest.

  • Single file with everything explicit: sox input.flac -r 16000 -c 1 -b 16 output.wav rate -v 16000, where rate -v selects the high-quality resampler.
  • A whole directory in parallel: list the source files with find, pipe the list through xargs -0 -P 8, and run sox once per file. Eight processes is a reasonable default on a laptop and easy to raise on a server.
  • sox also has a guard option that reduces gain when the output would clip. Treat it as a safety net and still check peaks afterward.
  • Keep the source files. Conversion is cheap to redo. Re-collecting is not.

Spot checks that catch the real failures

Four failures account for most of the damage: a file converted at the wrong ratio, an output that clipped, a file that came out silent or truncated, and a lossy source whose duration shifted by the encoder padding.

  • Headers: walk the output directory and assert rate, channel count, and subtype on every file. Count the failures rather than stopping at the first.
  • Peaks: count files whose maximum absolute sample is at or above 0.999, then inspect those by hand. A clip introduced by conversion is a defect, not a property of the source.
  • Empties: flag files under 0.1 seconds or below -60 dBFS. These are usually truncated uploads or a decode that failed without an error.
  • Durations: compare input and output duration. For lossless sources the difference should be under a few milliseconds; for lossy sources allow up to about 100 milliseconds for encoder padding.
  • Re-decode a five percent random sample and compare it with the pre-conversion PCM. For lossless sources that is an exact comparison; for lossy sources compare average spectra instead.

More insights

Submit a sourcing request

Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline — not a range. If we cannot source it well, we will tell you that instead.

  • Pilot batch before the full run, so problems surface early.
  • Consent documentation delivered with the data.
  • No medical or clinical data. No recorded telephone calls.

We reply within two business days. Your details are used only to answer this request. See our privacy policy.

Contact

Talk to a human

Send a specification and we will come back with a real number and timeline.

Submit a sourcing request

Or email hello@linguacorpus.com