Standard del settore: 96–128 kbps CBR mono
Se vuoi la risposta breve: codifica il tuo podcast come MP3, 96–128 kbps, CBR, mono, 44,1 kHz. È ciò che consiglia Apple Podcasts, ciò che accetta Spotify e ciò che si aspetta praticamente ogni piattaforma di hosting di podcast.
| Impostazione | Valore consigliato | Perché |
|---|---|---|
| Formato | MP3 | Compatibilità universale in tutte le app di podcast |
| Bitrate | 96–128 kbps | 96 per sola voce; 128 se sono presenti segmenti musicali |
| Modalità bitrate | CBR (bitrate costante) | Navigazione affidabile, dimensione del file prevedibile |
| Canali | Mono | La voce è mono; dimezza la dimensione rispetto allo stereo |
| Sample rate | 44,1 kHz | Standard del CD, compatibilità massima |
| Loudness | -16 LUFS | Standard per le piattaforme di podcast |
Regola rapida: 96 kbps mono per show solo parlato. 128 kbps mono se il tuo podcast ha segmenti musicali significativi (jingle di intro/outro, musica di sottofondo). Andare oltre 128 kbps in un podcast spreca spazio e banda senza beneficio udibile per la voce.
Perché CBR e non VBR?
Per la musica il VBR (bitrate variabile) è generalmente preferito perché assegna più bit ai passaggi complessi e meno al silenzio, migliorando la qualità per byte. Per i podcast, invece, il CBR è la scelta più sicura per diverse ragioni pratiche:
- Navigazione affidabile: i file CBR permettono ai player di podcast di calcolare qualsiasi posizione temporale a partire dall'offset in byte. Il VBR richiede una tabella di seek separata (header Xing/VBRI), e alcune app di podcast più vecchie non la gestiscono bene — causando tempi imprecisi o salti a posizioni sbagliate.
- Stima accurata della durata: i feed RSS includono una dimensione del file (enclosure length). Con CBR le app possono stimare la durata dell'episodio dalla sola dimensione. Il VBR rende impossibile tutto ciò senza analizzare l'header del file.
- Dimensioni prevedibili: con CBR puoi calcolare la dimensione esatta prima della codifica. A 96 kbps ogni minuto costa esattamente 720 KB. Questo semplifica la pianificazione dello spazio sul tuo account di hosting.
- Affidabilità in streaming: il CBR trasmette a velocità costante, più facile da gestire per gli algoritmi di buffering delle app di podcast, specialmente su connessioni mobili lente.
Il vantaggio qualitativo del VBR sul CBR è minimo per contenuti parlati. La voce è molto meno complessa della musica, quindi il VBR risparmierebbe bit soprattutto durante i silenzi — dove la qualità non conta comunque. I benefici pratici del CBR superano il guadagno marginale di efficienza del VBR per i podcast.
Perché mono per i podcast?
Un podcast con un singolo narratore è intrinsecamente audio mono. La voce proviene da una sola fonte e non porta informazioni stereo significative. Codificarla in stereo raddoppia la dimensione del file senza alcun beneficio udibile.
- File del 50 % più piccoli: un episodio di 1 ora a 96 kbps mono è ~42 MB. Lo stesso episodio a 96 kbps stereo sarebbe ~42 MB, ma con il bitrate diviso su due canali identici, riducendo la qualità per canale.
- Raccomandazione di Apple: Apple Podcasts consiglia esplicitamente il mono per podcast parlati nelle sue linee guida per podcaster.
- Migliore qualità per bit: a parità di bitrate, il mono alloca tutti i bit a un unico canale. A 96 kbps mono, ogni secondo riceve 96 kbit di dati. A 96 kbps stereo, ogni canale riceve solo ~48 kbit. La versione mono suona notevolmente meglio.
- Riproduzione universale: l'audio mono esce identico da entrambi gli altoparlanti/auricolari. Gli ascoltatori sentono la stessa cosa usando un solo auricolare o entrambi.
Show di interviste: anche le interviste a due persone sono tipicamente distribuite in mono. Potresti panoramicare host e ospite a sinistra e a destra, ma ciò crea un'esperienza sgradevole per chi usa un solo auricolare. La maggior parte dei podcaster professionisti mixa tutte le voci al centro ed esporta in mono.
Sample rate: resta a 44,1 kHz
Per la distribuzione di podcast, 44,1 kHz è il sample rate corretto. Ecco perché:
- Standard del CD: 44,1 kHz è lo standard dell'audio digitale dal 1982. Ogni dispositivo, app e piattaforma lo supporta senza ricampionamento.
- Supera le esigenze della voce: la voce umana va da circa 85 Hz a 8 kHz (con sibilanti fino a ~12 kHz). 44,1 kHz cattura frequenze fino a 22,05 kHz — ben oltre qualunque contenuto vocale.
- Compatibilità massima: alcuni decoder MP3 più vecchi e sistemi embedded possono non gestire correttamente i file MP3 a 48 kHz. 44,1 kHz funziona ovunque.
- Nessun beneficio salendo più in alto: 48 kHz, 96 kHz o sample rate maggiori catturano frequenze ultrasoniche che non esistono nella voce e che comunque la codifica MP3 non preserva.
Se il tuo software di registrazione cattura a 48 kHz (comune nelle DAW orientate al video), la conversione a 44,1 kHz durante la codifica MP3 è automatica e senza perdite udibili per contenuti vocali. I codificatori moderni gestiscono questo ricampionamento in modo trasparente.
Pianificazione delle dimensioni per gli host di podcast
I piani di hosting per podcast sono spesso limitati dallo spazio (es. i piani di Libsyn si basano su una quota di upload mensile). Conoscere in anticipo le dimensioni dei tuoi file aiuta a scegliere il piano giusto ed evitare sforamenti.
| Durata | 96 kbps mono | 128 kbps mono | 128 kbps stereo | 192 kbps stereo |
|---|---|---|---|---|
| 15 min | 10,5 MB | 14 MB | 14 MB | 21 MB |
| 30 min | 21 MB | 28 MB | 28 MB | 42 MB |
| 1 ora | 42 MB | 56 MB | 56 MB | 84 MB |
| 2 ore | 84 MB | 112 MB | 112 MB | 168 MB |
Per un programma settimanale che pubblica 4 episodi da un'ora al mese:
- 96 kbps mono: ~168 MB/mese — sta nel piano base di Libsyn (250 MB)
- 128 kbps mono: ~224 MB/mese — appena entro il piano da 250 MB
- 192 kbps stereo: ~336 MB/mese — richiede un piano più grande
Formula rapida: dimensione (MB) = bitrate (kbps) × durata (secondi) ÷ 8.000. Ad esempio, 96 kbps × 3.600 secondi ÷ 8.000 = 43,2 MB per un episodio di 1 ora.
Tag ID3 per i podcast
I tag ID3 sono metadati incorporati nel file MP3. Le app di podcast leggono questi tag per mostrare le informazioni dell'episodio. File ben taggati appaiono professionali e aiutano gli ascoltatori a navigare tra i tuoi contenuti.
- Titolo (TIT2): il titolo dell'episodio. Mantienilo conciso — i titoli lunghi vengono troncati nelle UI delle app di podcast.
- Artista (TPE1): il nome del tuo podcast/show.
- Album (TALB): il nome del tuo podcast/show (uguale all'artista per la maggior parte dei podcast).
- Numero traccia (TRCK): numero dell'episodio (aiuta l'ordinamento in alcune app).
- Genere (TCON): imposta su "Podcast".
- Anno (TDRC): anno di pubblicazione.
- Copertina (APIC): artwork dell'episodio o dello show. Mantienilo sotto 500 KB — copertine grandi appesantiscono ogni file episodio. Usa JPEG a 1400×1400 o 3000×3000 pixel compresso a qualità 70–80.
Anche se i feed RSS veicolano questi metadati, i tag ID3 incorporati garantiscono che le informazioni rimangano con il file anche se scaricato separatamente o condiviso al di fuori di un'app di podcast.
Normalizzazione per un volume costante
La normalizzazione di loudness assicura che il tuo podcast venga riprodotto a volume costante — senza balzi o cali improvvisi che costringano gli ascoltatori a toccare il volume.
Il settore dei podcast si è assestato su -16 LUFS (Loudness Units Full Scale) come obiettivo:
- -16 LUFS: lo standard per la maggior parte delle piattaforme di podcast. Abbastanza forte da essere chiaro in ambienti rumorosi, abbastanza basso da evitare distorsioni.
- -14 LUFS: usato da Spotify per la musica. Alcuni podcaster puntano a questo valore per una riproduzione leggermente più forte, ma lascia meno headroom.
- Limite di true peak: mantieni i picchi a o sotto -1 dBTP (decibel True Peak). Ciò previene artefatti di clipping da picchi inter-sample durante la codifica MP3 e la ricostruzione DAC.
| Piattaforma | Loudness target | Limite di true peak |
|---|---|---|
| Apple Podcasts | -16 LUFS | -1 dBTP |
| Spotify | -14 LUFS (musica) / -16 LUFS (parlato) | -1 dBTP |
| YouTube | -14 LUFS | -1 dBTP |
| EBU R128 (broadcast) | -23 LUFS | -1 dBTP |
Applica la normalizzazione di loudness prima della codifica MP3, durante la fase di editing/mastering. Normalizzare dopo la codifica può introdurre ulteriore perdita di qualità. La maggior parte dei software di editing per podcast (Audacity, Hindenburg, Adobe Audition, Descript) include la normalizzazione di loudness come funzione standard.
La coerenza conta più del numero esatto. Un podcast costantemente a -18 LUFS suona meglio agli ascoltatori rispetto a uno che oscilla tra -12 e -22 LUFS da un episodio all'altro. Scegli un obiettivo e mantienilo su tutti gli episodi.