Audio formats
Audio formats come in two kinds: lossy, which throw part of the signal away and never give it back, and lossless, which shrink the file while keeping the original samples exactly. Neither is better than the other; an archive wants lossless and playback wants lossy.
- Lesson 4 of 10
- Beginner
- Free, no signup
Lossy and lossless, two right jobs
Lossy: MP3, AAC, Opus
- Part of the signal is thrown away and never comes back
- Up to 80 to 95 percent smaller
- For playback, publishing and anything that gets downloaded
- Re-encoding it stacks the damage up
Lossless: WAV, FLAC
- Gives back exactly the original samples
- FLAC around 40 to 50 percent smaller, WAV not compressed at all
- For recording, editing, mastering and archives
- Every export from it starts from zero again
Neither is better than the other. The mistake is keeping the archive lossy or shipping the playback file lossless.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
Lossy and lossless: what exactly separates them
A lossless codec makes the file smaller and hands back exactly the samples it was given, byte for byte. A lossy codec makes no such promise: it throws away the part of the signal that a model of human hearing says is least audible, and that part never comes back. MDN's audio codec guide says the same and puts a size on the saving: a lossy codec compresses by up to 80 to 95 percent, a lossless one by around 40 to 50 percent.
That gap is large, and it explains why both families exist. One podcast episode in a lossless format runs to several hundred megabytes and nobody downloads it. The same episode lossy is a few dozen megabytes and you will not hear the difference on a phone and a pair of earbuds.
Turn the direction around, though, and everything changes. A file that has been compressed lossily once has lost that information for good. You can make a WAV out of it later and the file will get bigger, but what was discarded does not return. A big WAV does not mean a high quality WAV, and that one sentence prevents most of the mistakes in this area.
What sample rate, bit depth and bitrate mean
Sound in air is a continuous wave and a computer does not understand continuous, so the wave is photographed at regular intervals. How many of those photographs happen per second is the sample rate: 44100 means forty four thousand one hundred times a second. How precise each photograph is is the bit depth: at 16 bits, each sample takes one of 65536 possible levels.
Those two numbers together fix the size of uncompressed audio, and the arithmetic is easy. One second of stereo at 44100 and 16 bits is 44100 times 16 times 2, which is 1411200 bits per second. That is why a WAV is big: it compresses nothing and simply writes those samples one after another. In the section on our own experience we show this with a real file.
Bitrate is the third number and it belongs to the compressing codecs. It says how many bits the codec may spend per second. MDN puts MP3's range at 32 to 320 kbps, and Opus's own page gives its range as 6 to 510 kbps. Opus starts that low because it was designed for speech as well as music, not only music.
And one rule that saves money and space: raising the sample rate or the bit depth above what the recording actually captured only makes the file bigger. Quality comes from the source, not from the number you type on export.
How sound becomes a file
-
1
A wave in the air
Continuous and infinitely fine. A computer does not understand this.
-
2
Microphone
Turns the wave into an electrical signal. The final quality is capped right here.
-
3
Sampling
Sample rate: how many times a second the wave is photographed.
-
4
Quantising
Bit depth: how precisely each sample is written down.
-
5
Encoding and the file
Bitrate and format: this is where it is decided whether anything gets thrown away.
The three numbers in this lesson are set at the three middle steps of this chain. None of them makes up for the recording itself: an echoing room echoes at any sample rate.
The five formats that actually get used
The columns below are read from MDN's audio codec guide and, for Opus, from the project's own page.
| Format | Kind | Licensing | Browser support | Where it belongs |
|---|---|---|---|---|
| MP3 | Lossy | Patents expired; in the United States as of April 2017 | All major browsers | When the destination takes MP3 and nothing else |
| AAC | Lossy | No licence needed to stream or distribute; codec developers need one | Depends on the operating system's own support; Chrome only inside MP4 | The audio inside video |
| Opus | Lossy | Fully open and royalty-free, an IETF standard as RFC 6716 | Chrome, Firefox, Edge, Safari 11 and later | Speech and web playback, and anywhere latency matters |
| WAV | Uncompressed | Free | Everywhere | Recording and moving audio between applications |
| FLAC | Lossless | Fully open and royalty-free | Chrome, Firefox 51 and later, Safari 11 and later | Archives and the master copy |
Two of these columns make more decisions than the rest. First licensing, which explains why Opus and FLAC can go into any project with no legal question attached. Second latency, which is not a column but is in MDN's text: Opus runs between 5 and 66.5 milliseconds, the lowest of the general-purpose codecs. For a voice call or a live stream that single number finishes the argument.
If you can only support one lossy format, MDN's own recommendation is AAC. That does not contradict what we said above: AAC is the safe pick when you do not know what is on the other end, and Opus is the better pick when you do.
What a podcaster, an editor and an archive each need
Three people with three needs, and between them they cover almost every case.
A podcaster records in WAV and publishes in MP3, and between those two there should be no other lossy file. WAV because nothing is lost while recording and editing, MP3 because the podcast platform list still asks for it. If the destination accepts Opus you get a smaller file at the same quality; but read that from the platform's own documentation rather than from memory.
A video editor usually has no choice and puts in whatever the container accepts: AAC inside MP4, Opus inside WebM. The thing easily forgotten is that audio has a bitrate too and takes its share of the final file. For speech, a lower bitrate and one channel instead of two cuts the size noticeably and nobody notices.
An archive has the simplest rule of all: keep anything that would be expensive to make again in a lossless form. FLAC was built for exactly that, and MDN names archiving music as its use. If you have raw WAV files and you are running out of space, converting them to FLAC loses nothing at all; in the section on our own experience we show that with a test.
The four jobs that pick the audio format for you
The cells have no axes: each cell is a job, with its answer written beside it.
-
Podcast and speech
Record in WAV, publish in MP3. Opus if the destination accepts it.
-
Audio inside video
AAC inside MP4, Opus inside WebM. The container narrows the choice.
-
Archive and master
FLAC, or the original WAV if you have the space. Never lossy.
-
Playback on the web
Opus is the smallest and has the lowest latency; MP3 is the safest fallback.
These four cells settle the format, not the bitrate. The bitrate number has to come from the destination's own spec.
Why you should not re-export a lossy file as lossy
Every time a lossy file is encoded, the codec decides what to throw away. If the input has already been through that step once, the second decision is being made about something that has already been discarded from. The result accumulates and it is not reversible.
In practice this happens quietly and nobody notices: you drop an MP3 into the editor, make one cut, and export MP3 again. Or you pull the audio out of a video, which is AAC to begin with, and convert it to MP3 for a podcast. Both of those are perfectly doable, and both add one more round of discarding.
The right way is the archive rule again. Keep one lossless copy, do all the editing on it, and take every lossy export straight from that copy. If you are forced to work from a lossy file, at least arrange for it to be encoded once more rather than three times.
The fast path, with AI
What separates a professional podcast from a home one is usually not the microphone; it is loudness that stays consistent between episodes. The usual route is to hit a Normalize button in the editor, which only lifts the loudest peak and has nothing to do with perceived loudness. The professional route is to measure integrated loudness and correct it, and ffmpeg has the loudnorm filter for exactly that, describing itself as an EBU R128 implementation. Its two-pass form is precisely where a language model earns its keep: the first pass prints the measured values as JSON and the second pass has to take those same values verbatim. That mechanical filling in is the step humans get wrong.
- First pass, measure. One line: ffmpeg -i in.wav -af loudnorm=print_format=json -f null - which prints measured_I, measured_TP, measured_LRA and measured_thresh, and writes no file.
- Take the target from the destination's own documentation, not from a number you read somewhere. If the destination has published nothing, loudnorm's own defaults stay in place: integrated loudness minus 24, true peak ceiling minus 2, loudness range 7. You can see them yourself with ffmpeg -h filter=loudnorm.
- Fill the recipe below with the first pass JSON and the destination target. The model must build the second pass command with those measured values and encode the final output to the delivery format in the same command, so the file is not encoded twice.
- Measure again at the end. Run the same first pass command on the output; the number should land on the target. If it has not, that usually means the source had a very wide dynamic range and a human decision is needed, rather than forcing the number around a second time.
Copy-ready recipe
Role: audio engineer. Your job is to build the second loudnorm pass command exactly. Do not produce any number; use only the numbers that appear in the JSON below or in the destination target.
Destination target:
{write the number here if the destination has published one, otherwise write "not published" so the filter's own defaults stay}
Delivery format and spec:
{e.g. stereo MP3 for a podcast host | AAC inside MP4 for video | Opus for the web}
First pass JSON output:
{paste the JSON here}
Answer in this order:
1. Give one ffmpeg command that takes all four measured values verbatim from the JSON and keeps linear on.
2. In that same command, encode the output straight to the delivery format. Do not create an intermediate file.
3. Under the command, say in one line what each option does.
4. If the measured loudness is far from the target, say how much gain that takes and warn that the noise floor rises by the same amount.
5. Also write the command to measure the output file again, so I can check it myself.Before you trust the output: Levelling loudness is not quality. An echoing room still echoes afterwards, and lifting a thin recording lifts its noise floor with it. And never do two things: do not normalise the archive copy, only the delivery copy; and do not run the loudnorm output back through the filter, because every pass is one more encode.
AI in this kind of work
Unlike image formats, audio is an area where AI has genuinely changed something: transcription, speech cleanup and text to speech all work today. But format choice is still arithmetic rather than a model's taste, and where it all goes wrong is the tools that claim to turn bad audio into good audio.
Tools that actually help
- ElevenLabs For text to speech and dubbing. A ranking of its models, weighted by whether they actually read Persian, is on this site. The export control clause in their own terms of use names Iran, so there is no official signup or payment from Iran.
- Claude For building the ffmpeg filter chain and filling the measured values into the second loudnorm pass, because its explanation can be checked against the filter documentation. Iran is not on Anthropic's supported-countries list.
- FFmpeg Not an AI tool, and deliberately on the list. Measuring loudness, converting formats and making speech mono are all one command line each and need no model at all.
- RGB The access and payment layer for Iran, kept separate from the tools themselves.
Where it backfires
Audio "enhancement" tools do what their image counterparts do: they do not bring back what was never recorded, they put the most plausible guess in its place. For a teaser that hardly matters. For an interview, a client testimonial, a recorded meeting or any file meant to serve as a record, the enhanced version is no longer the original recording, and the file naming has to make clear which one is the master and which one was processed. The second risk runs the other way: re-encoding does not remove an AI audio watermark. Google writes of SynthID that its audio watermark cannot be altered by common modifications such as adding noise, MP3 compression or changing the speed of the track. And the third risk is not technical but ruins everything: cloning a real person's voice without their written permission. That is a contract question before it is a technical one, and the answer has to be obtained before the recording, not after publication.
Sources: MDN: Web audio codec guide Opus Interactive Audio Codec Google DeepMind: SynthID ElevenLabs Terms of Use
Where this advice stops
Format is the last decision, not the first. The room, the microphone and the distance from mouth to microphone affect the result more than the codec choice almost every time, and no format saves audio recorded in an echoing room. Lossless does not mean better sounding either; it means recoverable. If you cannot hear a difference on the destination device, you do not need a lossless file for delivery and you are only spending bandwidth. And like any page carrying a browser support list, this table's columns were read from their sources on the date printed at the top and should be read from those sources again today.
From our own work
We measured two of this lesson's claims on this server, with ffmpeg 6.1.1, on the date printed at the top of this page. First the WAV arithmetic: we made a thirty second file at 44100, 16 bits, two channels, and it came out at 5292078 bytes, while 44100 times 16 times 2, divided by 8, times 30 is 5292000. The entire file, apart from 78 bytes of header, is that arithmetic and nothing else. Second, what "lossless" means: we converted the same file to FLAC, MP3, Opus and AAC, then decoded all five back to raw samples and took an md5. WAV and FLAC both returned 1671d60e646f0e771bbf874a6a5db852, byte for byte identical. The three lossy files returned three different md5s. It is the one test here that needs no ears and gives a definite answer.
Real follow-up questions
What is the difference between MP3 and WAV?
WAV compresses nothing and keeps the samples exactly as recorded, so it is big and it is right for recording and editing. MP3 compresses lossily and throws part of the signal away for good, so it is small and it is right for publishing. The correct path runs from the first to the second and never the other way.
Is Opus better than MP3?
Technically Opus is younger, royalty-free, starts at far lower bitrates and has the lowest latency of the general-purpose codecs. But MP3 plays practically everywhere and some platforms still accept nothing else. If you control the destination, Opus; if you do not, MP3.
What bitrate should I use for a podcast?
The number is set by the spec of wherever you upload the file, not by a general rule. But two things are almost always true: speech needs a far lower bitrate than music, and a single voice should go out mono rather than stereo, because stereo doubles the size without adding anything.