Reduce MP3 File Size on Mac (Bitrate, Mono and Length)

We encoded one 60-second stereo clip at five constant bitrates. The WAV original was 10,584,078 bytes.

The formula is simple: kbps times 1,000, divided by 8, times seconds. At 128 kbps a 60-second file is 960,000 bytes plus a small header, which matches what we measured. A one-hour podcast at 128 kbps is about 58 MB; at 64 kbps about 29 MB. Because the size follows the bitrate so closely, the content hardly matters for constant-bitrate files. For what each bitrate sounds like, read audio bitrate explained.

macOS cannot do this from Terminal: afconvert reads MP3 but does not write it. Your built-in option is the Music app:

1. Music > Settings > Files > Import Settings. Set Import Using to MP3 Encoder and pick a bitrate.
2. Add the file to your library, select it, then File > Convert > Create MP3 Version.

Music adds the track to your library and leaves the original alone. For a one-off, that is fine. For many files, use ffmpeg from Homebrew:

ffmpeg -i in.mp3 -b:a 128k out.mp3

Our WAV to MP3 guide compares the methods in more depth, and batch converting audio covers folders.

Not literally. MP3 is lossy, and re-encoding decodes the file and encodes it again, adding a second round of approximation. We saw one useful fact: encoding a 320 kbps MP3 down to 128 kbps produced a file with the same byte count as encoding the WAV straight to 128 kbps (960,932 bytes both times). The size was not hurt by the extra step. The sound is a separate matter.

So the honest advice is: keep the original if you still have it, and encode from that. If you only have the MP3, drop the bitrate once and stop. Going from 320 to 192 kbps is hard to hear on most speakers. Going below 96 kbps for music is where listeners notice.

Only if you also lower the bitrate. We encoded the clip as mono and as stereo at 64 kbps and 128 kbps. Each pair had the identical size: 480,488 bytes at 64 kbps and 960,932 at 128 kbps. Bitrate decides the size, not channel count.

The saving comes from the choice it allows. A mono voice recording at 64 kbps has all 64 kbps for one channel, while stereo at 64 kbps splits the budget across two. Stereo at 128 kbps becomes mono at 64 kbps with half the size and, for speech, no practical loss. That is why interviews and voice notes should go mono.

ffmpeg -i in.mp3 -ac 1 -b:a 64k out.mp3

It can be, because VBR spends bits only where the audio needs them. On our fixture, ffmpeg’s VBR settings gave these results:

These figures come from synthetic noise, which is not like music, so the averages will differ on your files. The takeaway is that VBR sizes are unpredictable in advance, while constant bitrate lets you plan a file for an upload cap.

Trimming is lossless for MP3 if you copy the stream instead of re-encoding it. We cut the 320 kbps clip to 30 seconds this way and got 1,202,721 bytes, half the original, with no re-encode:

ffmpeg -i in.mp3 -t 30 -c copy out.mp3

In QuickTime Player you can do the same with Edit > Trim, though it exports to M4A rather than MP3. For spoken audio that must be smaller still, see how to compress an audio file on Mac, where Opus and AAC beat MP3 at low bitrates.

For one file, the Music app or one ffmpeg line is enough, and both are free. If you can use M4A, QuickTime does trimming without any install. Smol is not the answer for lossless trimming either.

Smol earns $29 (once, one Mac) when you have a folder to shrink: drop in MP3s, WAVs and M4As together, set a bitrate from 16 to 512 kbps and, if you want, a sample rate, and get _compressed copies next to the originals with nothing uploaded. See the best audio converter for Mac or pricing.