Melhor bitrate de podcast por tipo de programa
| Tipo de programa | Canais | Bitrate | Arquivo de 1 hora |
|---|---|---|---|
| Fala solo, entrevistas | Mono | 64–96 kbps | 29–43 MB |
| Fala com trilhas de fundo ou vinhetas | Mono | 96–128 kbps | 43–58 MB |
| Programas com muita música ou sound design | Estéreo | 128–192 kbps | 58–86 MB |
| Master bruto que você guarda | Mono ou estéreo | WAV, 16 ou 24 bits | 635 MB ou mais (qualidade CD, estéreo) |
Passar de 192 kbps raramente ajuda um podcast: a maioria das pessoas ouve em fones de ouvido e alto-falantes de celular, e arquivos maiores custam espaço de hospedagem e dados móveis.
Padrão da indústria: 96–128 kbps CBR mono
Se quer a resposta curta: codifique seu podcast como MP3, 96–128 kbps, CBR, mono, 44,1 kHz. O Apple Podcasts e o Spotify aceitam esse formato, e qualquer app de podcast consegue reproduzi-lo.
| Configuração | Valor recomendado | Por quê |
|---|---|---|
| Formato | MP3 | Compatibilidade universal em todos os apps de podcast |
| Bitrate | 96–128 kbps | 96 para fala pura; 128 se houver segmentos musicais |
| Modo de bitrate | CBR (bitrate constante) | Navegação confiável, tamanho de arquivo previsível |
| Canais | Mono | Fala é mono; reduz o tamanho pela metade em relação ao estéreo |
| Sample rate | 44,1 kHz | Padrão do CD, compatibilidade máxima |
| Loudness | -16 LUFS | Padrão para plataformas de podcast |
Regra rápida: 96 kbps mono para programas só de fala. 128 kbps mono se o seu podcast tiver segmentos musicais relevantes (vinhetas de abertura/encerramento, música de fundo). Passar de 128 kbps em um podcast desperdiça armazenamento e banda sem ganho audível para a fala.
Por que CBR, e não VBR?
Para música, o VBR (bitrate variável) costuma ser preferido porque aloca mais bits a passagens complexas e menos ao silêncio, melhorando a qualidade por byte. Para podcasts, porém, o CBR é a escolha mais segura por várias razões práticas:
- Navegação confiável: arquivos CBR permitem aos players de podcast calcular qualquer posição temporal a partir do deslocamento em bytes. O VBR exige uma tabela de navegação separada (cabeçalho Xing/VBRI), e alguns apps de podcast mais antigos não lidam bem com ela — levando a tempos imprecisos ou saltos para a posição errada.
- Estimativa precisa de duração: feeds RSS incluem um tamanho de arquivo (enclosure length). Com CBR, os apps conseguem estimar a duração do episódio apenas pelo tamanho. O VBR inviabiliza isso sem analisar o cabeçalho do arquivo.
- Tamanhos previsíveis: com CBR é possível calcular o tamanho exato antes de codificar. A 96 kbps, cada minuto custa exatamente 720 KB. Isso facilita o planejamento de armazenamento na sua conta de hospedagem.
- Confiabilidade de streaming: o CBR transmite a uma taxa constante, o que é mais fácil para os algoritmos de buffer dos apps de podcast lidarem, especialmente em conexões móveis lentas.
A vantagem de qualidade do VBR sobre o CBR é mínima para conteúdo falado. A fala é muito menos complexa que a música, então o VBR economizaria bits sobretudo nos silêncios — onde a qualidade não importa. Os benefícios práticos do CBR superam o ganho marginal de eficiência do VBR para podcasts.
Por que mono para podcasts?
Um podcast com um único narrador é intrinsecamente áudio mono. A voz vem de uma única fonte e não carrega informação estéreo relevante. Codificá-la em estéreo dobra o tamanho do arquivo sem benefício audível.
- Mesmo tamanho, bits mais bem aproveitados: um episódio de 1 hora a 96 kbps tem cerca de 43 MB, seja em mono ou em estéreo. Em estéreo, esses bits cobrem dois canais quase idênticos; em mono, todos vão para a única voz.
- Arquivos menores: como o mono precisa de menos bits para a mesma qualidade, você pode passar de 128 kbps estéreo para 64–96 kbps mono e reduzir o tamanho do arquivo em 25–50 %.
- Melhor qualidade por bit: no mesmo bitrate, o mono aloca todos os bits a um só canal. A 96 kbps mono, cada segundo recebe 96 kbits de dados. A 96 kbps estéreo, cada canal recebe apenas ~48 kbits. A versão mono soa notavelmente melhor.
- Reprodução universal: o áudio mono sai igual dos dois alto-falantes/fones. Os ouvintes escutam a mesma coisa usando um fone ou os dois.
Programas de entrevista: mesmo entrevistas de duas pessoas geralmente são distribuídas em mono. Você poderia panoramizar apresentador e convidado para a esquerda e direita, mas isso cria uma experiência desagradável para quem usa só um fone. A maioria dos podcasters profissionais mixa todas as vozes ao centro e exporta em mono.
Sample rate: fique com 44,1 kHz
Para distribuição de podcasts, 44,1 kHz é o sample rate correto. Veja por quê:
- Padrão do CD: 44,1 kHz é o padrão de áudio digital desde 1982. Todo dispositivo, app e plataforma suporta sem reamostragem.
- Excede as necessidades da fala: a voz humana vai de cerca de 85 Hz a 8 kHz (com sibilância até ~12 kHz). 44,1 kHz captura frequências até 22,05 kHz — bem acima de qualquer coisa na fala.
- Compatibilidade máxima: alguns decodificadores MP3 antigos e sistemas embarcados podem não lidar corretamente com arquivos MP3 a 48 kHz. 44,1 kHz funciona em todo lugar.
- Nenhum benefício em subir mais: 48 kHz, 96 kHz ou sample rates maiores capturam frequências ultrassônicas que não existem na fala e que a codificação MP3 não preserva de qualquer forma.
Se sua gravação está em 48 kHz, defina 44,1 kHz nas configurações de exportação do seu editor. O conversor desta página mantém o sample rate do WAV, então um WAV de 48 kHz vira um MP3 de 48 kHz.
Planejamento de tamanho para hosts de podcast
Planos de hospedagem de podcast costumam ser limitados por armazenamento (p. ex., os planos da Libsyn são baseados em cota mensal de upload). Saber o tamanho dos seus arquivos com antecedência ajuda a escolher o plano certo e evitar excedentes.
| Duração | 96 kbps mono | 128 kbps mono | 128 kbps estéreo | 192 kbps estéreo |
|---|---|---|---|---|
| 15 min | 10,8 MB | 14,4 MB | 14,4 MB | 21,6 MB |
| 30 min | 21,6 MB | 28,8 MB | 28,8 MB | 43,2 MB |
| 1 hora | 43,2 MB | 57,6 MB | 57,6 MB | 86,4 MB |
| 2 horas | 86,4 MB | 115,2 MB | 115,2 MB | 172,8 MB |
Para um programa semanal publicando 4 episódios de uma hora por mês:
- 96 kbps mono: ~173 MB/mês — cabe em um limite de upload mensal de 250 MB
- 128 kbps mono: ~230 MB/mês — apertado dentro de 250 MB
- 192 kbps estéreo: ~346 MB/mês — requer um plano maior
Fórmula rápida: tamanho (MB) = bitrate (kbps) × duração (segundos) ÷ 8.000. Por exemplo, 96 kbps × 3.600 segundos ÷ 8.000 = 43,2 MB para um episódio de 1 hora.
Tags ID3 para podcasts
Tags ID3 são metadados embutidos no arquivo MP3. Os apps de podcast leem essas tags para exibir informações do episódio. Arquivos corretamente marcados parecem profissionais e ajudam os ouvintes a navegar pelo seu conteúdo.
- Título (TIT2): o título do episódio. Seja conciso — títulos longos são cortados nas interfaces dos apps de podcast.
- Artista (TPE1): o nome do seu podcast/programa.
- Álbum (TALB): o nome do seu podcast/programa (igual ao artista na maioria dos podcasts).
- Número da faixa (TRCK): número do episódio (ajuda na ordenação em alguns apps).
- Gênero (TCON): defina como "Podcast".
- Ano (TDRC): ano de publicação.
- Capa (APIC): arte do episódio ou do programa. Mantenha abaixo de 500 KB — imagens grandes inflam cada arquivo de episódio. Use JPEG a 1400×1400 ou 3000×3000 pixels comprimido à qualidade 70–80.
Embora os feeds RSS também carreguem esses metadados, tags ID3 embutidas garantem que a informação fique com o arquivo mesmo ao ser baixado separadamente ou compartilhado fora de um app de podcast.
Normalização para volume constante
A normalização de loudness garante que seu podcast toque em volume constante — sem saltos ou quedas repentinas que forcem o ouvinte a mexer no controle de volume.
A indústria do podcast consolidou -16 LUFS (Loudness Units Full Scale) como alvo:
- -16 LUFS: o padrão na maioria das plataformas de podcast. Alto o suficiente para ficar claro em ambientes ruidosos, baixo o suficiente para evitar distorção.
- -14 LUFS: usado pelo Spotify para música. Alguns podcasters miram esse valor para uma reprodução ligeiramente mais alta, mas sobra menos headroom.
- Limite de true peak: mantenha os picos em ou abaixo de -1 dBTP (decibéis True Peak). Isso previne artefatos de clipping por picos intersamples durante a codificação MP3 e a reconstrução DAC.
| Plataforma | Loudness alvo | Limite de true peak |
|---|---|---|
| Apple Podcasts | -16 LUFS | -1 dBTP |
| Spotify | -14 LUFS (normalização na reprodução) | -1 dBTP |
| YouTube | -14 LUFS | -1 dBTP |
| EBU R128 (radiodifusão) | -23 LUFS | -1 dBTP |
Aplique a normalização de loudness antes da codificação MP3, na sua etapa de edição/masterização. Normalizar depois da codificação pode introduzir perda de qualidade adicional. A maioria dos softwares de edição de podcast (Audacity, Hindenburg, Adobe Audition, Descript) inclui normalização de loudness como recurso padrão.
Consistência importa mais do que o número exato. Um podcast consistentemente em -18 LUFS soa melhor para o ouvinte do que um que oscila entre -12 e -22 LUFS de episódio a episódio. Escolha um alvo e mantenha-o em todos os episódios.
Como exportar um MP3 de podcast com essas configurações
Audacity
- Escolha Arquivo → Exportar áudio e defina o formato como MP3.
- Defina Canais como Mono e o sample rate como 44100 Hz.
- Defina Modo de taxa de bits como Constante e Qualidade como 96 ou 128 kbps e, em seguida, exporte.
O conversor desta página
Envie o WAV e escolha CBR 128 kbps, o menor bitrate constante oferecido aqui. O conversor mantém o número de canais e o sample rate do seu WAV, então exporte antes um WAV mono de 44,1 kHz se quiser um MP3 mono. Para 64 ou 96 kbps, use um editor como o Audacity.