Compressing Audio and Video for Podcasters

Five hosts, five meters. This table decides whether the rest of this page applies to you.

Libsyn spells out the arithmetic: its hour estimates “assume audio encoded at 128 kbps” and the plan is metered in MB. Halve your bitrate and you double your episode count on the same plan. Nothing else in podcasting maps an encoder setting to a bill that cleanly.

Two per-file ceilings worth knowing. Podbean caps a single media file at 3 GB and a single image at 2 MB, which is the tighter one in practice. Transistor recommends audio files “no larger than 200 MB” while its pricing page says 1,000 MB and its help article says 2,000 MB. Both are official and they disagree; treat 200 MB as the number that matters.

Some hosts re-encode you anyway. Buzzsprout: “When you upload a file to Buzzsprout, we will optimize the file based on industry best practices for spoken word podcasts, which is 96k Mono. If your file is in stereo, then that optimization could affect your sound quality.” If your show has music beds, that decision is being made for you.

Apple publishes a table, and it is the most useful starting point in the category because it distinguishes mono from stereo rather than quoting one number.

Apple’s audio requirements page is unambiguous about the goal: “your audio content should be encoded or compressed in a format that results in the smallest file size possible.” It recommends the container too: “For RSS feeds, we strongly recommend using AAC instead of MP3. When choosing AAC, we recommend using the MP4 format over the ADTS format because MP4 allows for the most-efficient streaming usage and accurate seeking.”

Spotify sets a floor rather than a range: MP3 “with bitrates between 96 and 320 Kbps are supported” (supported file formats), and its Podcast Delivery Specification v1.10 (May 2025) recommends “either high bitrate (128kbps+) MP3 … or MP4 with AAC-LC” with “A maximum duration of 12 hours (roughly 2GB @ 320 Kbps)”. Keep stereo only if the show is scored or has more than one voice in the field.

Smol’s audio range is 16 to 512 kbps and 8,000 to 192,000 Hz, and asking for a rate gives you that rate: 192 kbps produced a stream measuring 192,533 bps. Its audio defaults are AAC, high quality, stereo, and metadata preserved. Never convert upward: that same request produced a file larger than its AAC source. Measurements in batch converting audio on Mac.

Apple states them exactly, in a sentence containing a warning most people miss. From A Podcaster’s Guide to RSS: “Artwork must be a minimum size of 1400 x 1400 pixels and a maximum size of 3000 x 3000 pixels, in JPEG or PNG format, 72 dpi, with appropriate file extensions (.jpg, .png), and in the RGB colorspace. Confirm your art does not contain an Alpha Channel. These requirements are different from the standard RSS image tag specifications.”

Apple does not publish a maximum artwork file size anywhere. We checked the artwork guide, all three art templates, the artwork policies page and the troubleshooting page. Dimensions, format, dpi, colourspace and alpha are specified; bytes are not. Anyone quoting you an Apple artwork byte limit is inventing it.

Two colour traps. Apple’s artwork troubleshooting page lists “Colorspace not supported” as a rejection reason: “Apple currently only supports image files that use RGB colorspace.” A cover exported from a print-oriented template in CMYK will bounce. So will a PNG with transparency: “Show Covers cannot contain transparency and should not contain an alpha channel.”

It matters, it is separate from the RSS artwork, and it is where a compression pass can quietly break your episode. Directories take artwork from the feed. Apple delivers episode art through the <itunes:image> tag, not from ID3, so the picture inside the MP3 is not what shows in Apple Podcasts. It is what shows in a listener’s file manager and in any player reading the download rather than the feed.

Both platforms care about its size. Spotify asks you to keep it small: “If you’re uploading MP3 files, we recommend keeping embedded artwork, ID3v2 tags, and other metadata as small as possible.” Apple Podcasts Connect rejects uploads over it outright, with the error “The size of the metadata block containing an embedded picture exceeds the maximum block size”. Apple does not publish what that maximum is.

Which makes a 3,000 × 3,000 PNG a poor choice to embed even though it is the right choice for the feed. Embed a small JPEG, publish the large one. Behaviour we measured across four routes, documented in converting M4A to MP3 on Mac:

For episode audio, the third row is the tool. Free, and one line:

ffmpeg -i episode-master.wav -c:a aac -b:a 96k -ac 1 \
  -c:v copy -map_metadata 0 episode.m4a

We are not going to dress our behaviour up. If the embedded picture matters, that is the better tool today, and the rest of this page is about the jobs around the episode rather than the episode itself.

Carefully, because the two ends of the pipe want opposite things. The feed must carry the byte size: RSS 2.0 says of <enclosure> that “length says how big it is in bytes” (RSS 2.0 specification), and Apple restates it as “the file size in bytes”. Change the file and that value changes with it, which your host normally handles.

Then the conflict. Spotify’s Delivery Specification v1.10 states that “only changing the image or audio binaries will not change the files at Spotify; Unless these files change name and/or path in the metadata, no new download will be made by Spotify.” Podbean replaces a media file “using the same file name” specifically “To preserve the episode statistics”, and Captivate says analytics “won’t be affected”. Same-filename replacement keeps your numbers and stops Spotify re-fetching.

One rule is not negotiable either way. Apple: “It is very important that each episode have a unique GUID and that it never changes, even if an episode’s metadata, like title or enclosure URL, do change.” So re-compress future episodes freely, and treat a back-catalogue re-encode as a conversation with your host rather than a Sunday batch job.

Duration constrains you long before file size does, and the published numbers are less consistent than you would hope.

The Instagram row is the one to design around: a three-minute ceiling on recommendation decides how you cut the clip, not how you encode it.

For what an encode costs, our guide to compressing video on Mac measured a 30,704,510-byte 1080p source clip (Big Buck Bunny, © Blender Foundation, CC-BY 3.0) down to 6,111,954 bytes at Smol’s default H.265 settings in 24.1 s at VMAF 93.83, and 3,201,900 bytes at web quality. QuickTime’s Export As → 1080p produced 13,666,490 bytes at VMAF 81.96: faster, and meaningfully worse.

One honest note on our video encoder: it is software x265, not VideoToolbox. That is why 24 seconds for a ten-second clip, and why quality per byte beats a hardware export. For speed on a long recording, ffmpeg with hevc_videotoolbox is the right trade. CRF is covered in reducing video file size without losing quality and screen captures in compressing a Mac screen recording.

Four cases, and the first is the big one.

Episode audio where the embedded cover matters. Use ffmpeg -c:v copy. Free, keeps the picture byte for byte, and the better tool for this job until we fix ours.

Your host is metered in hours or downloads. Blubrry and Buzzsprout bill hours; Transistor and Captivate bill downloads. Compressing an episode does not shorten it, so a smaller file saves bandwidth, not your invoice.

Mastering, levelling, noise removal or loudness targeting. Apple wants −16 dB LKFS with true peak under −1 dB FS. That is Auphonic, Logic, Audition or Descript. We do not touch the dynamics of your audio.

Your host re-encodes anyway. If you accept Buzzsprout’s 96k mono, uploading a carefully encoded 128 kbps stereo file means two lossy passes instead of one. Upload the best master the plan allows and let it convert once.

Where a local app earns the $29: the artwork, not the audio. A cover that clears Podbean’s 2 MB image cap while staying 3,000 × 3,000, RGB and alpha-free; a small embedded copy generated separately from the large feed copy; forty social clips from a season; and the video a guest sent you before it goes into an editor. Nothing is uploaded, which matters for episodes under embargo. Smol is $29 once.

The sibling vertical pages: web developers, photographers, real estate listings and legal and HR teams.