How to transcribe a WAV file to text, and why the size is not the quality

To transcribe a WAV file to text, drop it on the home page. The browser decodes it, mixes it to mono, resamples it to 16 kHz and writes out the words, and nothing is uploaded. What surprises people about WAV is the size. An hour of CD-quality stereo runs to about 635 million bytes, and a studio recording can be three times that. None of that weight turns into accuracy: a 2 GB session file and a 115 MB mono file reach the speech model in the same shape.

The size of a WAV file is arithmetic you can do yourself

A WAV normally holds linear PCM: uncompressed samples written out one after another, with no encoder deciding what to keep. MDN’s container guide puts it in one line, that WAV “contains uncompressed PCM audio, delivering the highest fidelity at the cost of larger file sizes”. Because nothing is compressed, the size is a multiplication:

bytes = sample rate x (bit depth / 8) x channels x seconds

The header adds a few dozen bytes and can be ignored. An hour of CD-quality stereo is 44,100 x 2 x 2 x 3,600, or 635,040,000 bytes, which your file manager will call 635 MB or 605 MB depending on whether it counts in millions or in multiples of 1,024. The same hour at 16 kHz 16-bit mono is 115,200,000 bytes. That gap matters more than it looks, and the next section is why.

Everything above 16 kHz mono is discarded before the model reads a sample

The speech model never sees your WAV. The file is decoded in slices, averaged down to one channel and resampled to 16,000 samples per second, and only that stream reaches the model, in windows of about a minute. The MP3 post walks through the same pipeline step by step.

The 16 kHz figure is not a corner we cut. The paper behind OpenAI’s open-source Whisper model states it directly: “All audio is re-sampled to 16,000 Hz, and an 80-channel log-magnitude Mel spectrogram representation is computed on 25-millisecond windows with a stride of 10 milliseconds.” A 16,000 Hz stream carries frequencies up to 8,000 Hz and nothing above.

So take the 96 kHz 24-bit stereo file and the plain 16 kHz mono one. The first is eighteen times the size of the second, and after decoding both are 16 kHz mono. The difference went to sample rate the model has no input for, bit depth it does not read, and a second channel that was averaged into the first. The file was bigger. The transcript is not.

Lossy formats fail the other way round, by letting the encoder throw away too much. With WAV nothing was thrown away, which is why people assume the transcript must be better.

Where WAV files come from, and what an hour of each weighs

Field recorders are the main source of very large WAVs. Zoom’s H4essential, to take one published spec, records “WAV 44.1/48/96 kHz, 32-bit float mono/stereo”, and at the top setting an interview fills a card fast. Desktop editors are the second source: Audacity’s WAV export defaults to “Signed 16-bit PCM, which is CD quality”. Dictation kit in clinics and law firms may be set for speech rather than music, so check its sample rate rather than assuming 44.1 kHz.

Only the last row is genuinely worse, and not because it is small. An 8 kHz recording never carried anything above 4,000 Hz, and resampling it up invents no detail. That is the one case where a file’s numbers predict a weaker transcript.

A very large WAV is a handling problem rather than an accuracy problem

The format has a hard ceiling. A RIFF file stores its length in a header field Microsoft’s documentation describes as “a 4-byte value”, which caps a WAV at 4 GB. Audacity states the same limit and publishes the durations behind it: about 6 hours 45 minutes of 16-bit stereo, 13 hours 31 minutes in mono, 4 hours 30 minutes at 24-bit stereo, with the advice to stay at “slightly lower limits to afford some head-room”. Recorders that reach it split the take into numbered parts, so transcribe each and join the text afterwards.

Our end of it does not care about the size at all. The file is read in slices, decoded in a worker and discarded as it goes, so only about a minute of audio is held at a time and memory stays flat whether the file is 40 MB or 2 GB. The real cost of a huge WAV is elsewhere: copying it off a memory card, storing it, and the wait before the first window decodes.

Converting before transcribing is worth it in three cases and pointless otherwise

Pointless: converting a WAV to MP3 so it will “go through” more easily, downsampling 96 kHz to 44.1 kHz, or shrinking the file to speed up an upload that never happens.

Worth doing:

• The file has to travel. A 2 GB WAV is awkward to email or archive, and a 16 kHz mono export cuts it by a factor of eighteen while removing nothing the model would have read.
• The WAV does not decode. That is the container problem below, and converting to plain PCM is the fix.
• You are keeping the audio too. Export as WAV again, not a lossy format, if it might be edited later.

If you have not recorded yet, what moves accuracy is microphone distance and room noise, not sample rate. The recording habits post goes through them, and the hub on converting audio to text covers the routes for any format.

WAV is a container, and not every WAV holds PCM

WAV is derived from the Resource Interchange File Format, a wrapper around chunks: a “fmt “ chunk naming the audio format, a “data” chunk holding it. What that header names does not have to be PCM. MDN is blunt about it: “The WAV codec registry can be found at RFC 2361; however, because nearly all WAV files use linear PCM, support for the other codecs is sparse.” Its table lists LPCM as supported in browsers, while ADPCM, GSM 06.10, MP3 inside WAV and mu-Law are not.

So a WAV out of an old phone system, a call logger or a legacy dictation package can be a file the browser refuses to decode, despite the extension. If a WAV fails where an MP3 from the same source works, that is the likely reason. Export it again as 16-bit PCM from a desktop editor.

Transcribe WAV to text without uploading the file

Open the home page, drag the WAV onto it or pick it with the file button, and text starts appearing after the first window rather than at the end. On the first run the browser downloads the model, whisper-base.en, about 200 MB, and caches it, so later files start immediately. Export TXT, SRT or VTT; the export formats post covers which one you want.

Where this stops. It runs on desktop Chrome or Edge with a working WebGPU adapter, so Firefox, Safari and phones are not supported yet, and it is English only. No export carries speaker labels, whichever channel a voice arrived on. The base model gets names, technical terms, heavy accents and noisy rooms wrong more often than a larger one would, a trade-off covered in model sizes. Read it through before relying on it.

Nothing leaves the tab, which is what makes size a non-issue rather than a bandwidth bill, and you can check that yourself in the network panel. If a 2 GB WAV has been sitting on a card since the interview, drop it on the home page.

Frequently asked questions

Does a WAV transcribe more accurately than an MP3 of the same recording? Usually not by anything you would notice, since both are reduced to 16 kHz mono first. The WAV has an edge only when the MP3 sits at a very low bitrate, where the encoder blurs the consonants that separate similar words.

Is there a size limit on the WAV I can transcribe? Not at our end, since there is no upload and the file is read in slices. The limit is in the format: a WAV cannot exceed 4 GB, roughly 6 hours 45 minutes of 16-bit stereo at 44.1 kHz.

Should I convert a 24-bit 96 kHz WAV down before transcribing it? Not for the transcript. Convert it if you need to send or archive the file, in which case 16 kHz mono keeps everything the model uses at about one eighteenth of the size.

My WAV will not decode. What now? The extension says WAV, but the header may name a codec such as ADPCM or mu-Law that browsers do not decode. Export it again as 16-bit PCM from a desktop audio editor and try once more.

Sources, checked 15 September 2026

• https://arxiv.org/html/2212.04356 - Radford et al., section 2.2, on resampling to 16,000 Hz and the Mel spectrogram
• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Containers - MDN: WAVE derives from RIFF, holds “uncompressed PCM audio”, the RFC 2361 note, and the table where LPCM is supported but ADPCM, GSM 06.10, MP3 and mu-Law are not
• https://learn.microsoft.com/en-us/windows/win32/xaudio2/resource-interchange-file-format--riff- - Microsoft on RIFF chunks and fileSize as “a 4-byte value”
• https://manual.audacityteam.org/man/size_limits_for_wav_and_aiff_files.html - Audacity: the 4 GB limit and its durations
• https://manual.audacityteam.org/man/wav_export_options.html - Audacity: “Default is Signed 16-bit PCM, which is CD quality”
• https://zoomcorp.com/en/us/handheld-recorders/handheld-recorders/h4essential/ - Zoom H4essential: “WAV 44.1/48/96 kHz, 32-bit float mono/stereo”