Beste podcastbitrate per type show
| Type show | Kanalen | Bitrate | Bestand van 1 uur |
|---|---|---|---|
| Solo-praatprogramma's, interviews | Mono | 64–96 kbps | 29–43 MB |
| Praatprogramma met muziekbedden of jingles | Mono | 96–128 kbps | 43–58 MB |
| Shows met veel muziek of sounddesign | Stereo | 128–192 kbps | 58–86 MB |
| Ruwe master die je bewaart | Mono of stereo | WAV, 16- of 24-bit | 635 MB of meer (cd-kwaliteit, stereo) |
Hoger dan 192 kbps gaan helpt een podcast zelden: de meeste mensen luisteren via oortjes en telefoonspeakers, en grotere bestanden kosten hostingruimte en mobiele data.
Industriestandaard: 96–128 kbps CBR mono
Wil je het korte antwoord: codeer je podcast als MP3, 96–128 kbps, CBR, mono, 44,1 kHz. Apple Podcasts en Spotify accepteren dat, en elke podcast-app kan het afspelen.
| Instelling | Aanbevolen waarde | Waarom |
|---|---|---|
| Formaat | MP3 | Universele compatibiliteit in alle podcast-apps |
| Bitrate | 96–128 kbps | 96 voor pure spraak; 128 als er muzieksegmenten zijn |
| Bitrate-modus | CBR (constante bitrate) | Betrouwbaar navigeren, voorspelbare bestandsgrootte |
| Kanalen | Mono | Spraak is mono; halveert de bestandsgrootte ten opzichte van stereo |
| Sample rate | 44,1 kHz | CD-standaard, maximale compatibiliteit |
| Loudness | -16 LUFS | Standaard voor podcastplatforms |
Snelle regel: 96 kbps mono voor puur gesproken shows. 128 kbps mono als je podcast belangrijke muzieksegmenten heeft (intro-/outro-jingles, achtergrondmuziek). Hoger dan 128 kbps voor een podcast verspilt opslag en bandbreedte zonder hoorbaar voordeel voor spraak.
Waarom CBR en geen VBR?
Voor muziek wordt VBR (variabele bitrate) meestal verkozen omdat het meer bits toewijst aan complexe passages en minder aan stilte, wat de kwaliteit per byte verbetert. Voor podcasts is CBR echter de veiligere keuze om meerdere praktische redenen:
- Betrouwbaar navigeren: CBR-bestanden laten podcast-spelers elke tijdspositie berekenen op basis van de byte-offset. VBR vereist een aparte seek-tabel (Xing/VBRI-header), en sommige oudere podcast-apps verwerken die niet correct — wat leidt tot onnauwkeurige tijdsaanduidingen of springen naar de verkeerde positie.
- Nauwkeurige duurschatting: RSS-feeds bevatten een bestandsgrootte (enclosure length). Met CBR kunnen apps de afleveringsduur alleen op basis van de bestandsgrootte inschatten. VBR maakt dat onmogelijk zonder de header te parsen.
- Voorspelbare bestandsgroottes: met CBR kun je exacte bestandsgroottes berekenen vóór het coderen. Bij 96 kbps kost elke minuut precies 720 KB. Dat maakt opslagplanning voor je hostingaccount eenvoudig.
- Streaming-betrouwbaarheid: CBR streamt met constante snelheid, wat gemakkelijker is voor de bufferingsalgoritmen van podcast-apps, vooral op trage mobiele verbindingen.
Het kwaliteitsvoordeel van VBR boven CBR is minimaal voor gesproken content. Spraak is veel minder complex dan muziek, dus VBR zou vooral bits besparen tijdens stiltes — waar de kwaliteit er toch niet toe doet. De praktische voordelen van CBR wegen op tegen de marginale efficiëntiewinst van VBR voor podcasts.
Waarom mono voor podcasts?
Een podcast met één verteller is van nature mono-audio. De stem komt uit één bron en draagt geen zinvolle stereo-informatie. Hem als stereo coderen verdubbelt de bestandsgrootte zonder hoorbaar voordeel.
- Zelfde grootte, betere benutting van bits: een aflevering van 1 uur op 96 kbps is ongeveer 43 MB, in mono of in stereo. In stereo verdelen die bits zich over twee vrijwel identieke kanalen; in mono gaan ze allemaal naar die ene stem.
- Kleinere bestanden: omdat mono minder bits nodig heeft voor dezelfde kwaliteit, kun je van 128 kbps stereo naar 64–96 kbps mono gaan en de bestandsgrootte met 25–50 % verkleinen.
- Betere kwaliteit per bit: bij dezelfde bitrate wijst mono alle bits toe aan één kanaal. Bij 96 kbps mono krijgt elke seconde 96 kbits aan data. Bij 96 kbps stereo krijgt elk kanaal slechts ~48 kbits. De mono-versie klinkt merkbaar beter.
- Universele weergave: mono-audio komt identiek uit beide luidsprekers/oortjes. Luisteraars horen hetzelfde of ze nu één of twee oortjes gebruiken.
Interviewshows: zelfs interviews tussen twee personen worden doorgaans in mono gedistribueerd. Je zou host en gast naar links en rechts kunnen pannen, maar dat creëert een onaangename ervaring voor luisteraars met slechts één oortje. De meeste professionele podcasters mixen alle stemmen naar het midden en exporteren in mono.
Sample rate: blijf bij 44,1 kHz
Voor podcastdistributie is 44,1 kHz de juiste sample rate. Dit is waarom:
- CD-standaard: 44,1 kHz is sinds 1982 de digitale audiostandaard. Elk apparaat, elke app en elk platform ondersteunt het zonder resampling.
- Overtreft de spraakbehoefte: menselijke spraak loopt van ongeveer 85 Hz tot 8 kHz (met sisklanken tot ~12 kHz). 44,1 kHz legt frequenties tot 22,05 kHz vast — ver boven wat in spraak voorkomt.
- Maximale compatibiliteit: sommige oudere MP3-decoders en embedded systemen kunnen MP3-bestanden van 48 kHz mogelijk niet correct verwerken. 44,1 kHz werkt overal.
- Geen voordeel om hoger te gaan: 48 kHz, 96 kHz of hogere sample rates leggen ultrasone frequenties vast die niet in spraak bestaan en die MP3-codering toch niet bewaart.
Is je opname 48 kHz, stel dan 44,1 kHz in bij de exportinstellingen van je editor. De converter op deze pagina behoudt de sample rate van de WAV, dus een WAV van 48 kHz wordt een MP3 van 48 kHz.
Bestandsgrootteplanning voor podcasthosts
Podcasthostingpakketten zijn vaak beperkt in opslag (bijv. de plannen van Libsyn zijn gebaseerd op een maandelijkse uploadquota). Op voorhand je bestandsgroottes kennen helpt om het juiste plan te kiezen en overschrijdingen te voorkomen.
| Duur | 96 kbps mono | 128 kbps mono | 128 kbps stereo | 192 kbps stereo |
|---|---|---|---|---|
| 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 uur | 43,2 MB | 57,6 MB | 57,6 MB | 86,4 MB |
| 2 uur | 86,4 MB | 115,2 MB | 115,2 MB | 172,8 MB |
Voor een wekelijkse show die 4 afleveringen van een uur per maand publiceert:
- 96 kbps mono: ~173 MB/maand — past binnen een uploadlimiet van 250 MB per maand
- 128 kbps mono: ~230 MB/maand — past krap onder 250 MB
- 192 kbps stereo: ~346 MB/maand — vereist een groter pakket
Snelle formule: bestandsgrootte (MB) = bitrate (kbps) × duur (seconden) ÷ 8.000. Bijvoorbeeld: 96 kbps × 3.600 seconden ÷ 8.000 = 43,2 MB voor een aflevering van 1 uur.
ID3-tags voor podcasts
ID3-tags zijn metadata die in het MP3-bestand zijn ingebed. Podcast-apps lezen deze tags om afleveringsinformatie weer te geven. Correct getagde bestanden ogen professioneel en helpen luisteraars door je content te navigeren.
- Titel (TIT2): de afleveringstitel. Houd het bondig — lange titels worden in de UI van podcast-apps afgekapt.
- Artiest (TPE1): de naam van je podcast/show.
- Album (TALB): de naam van je podcast/show (hetzelfde als artiest voor de meeste podcasts).
- Tracknummer (TRCK): afleveringsnummer (helpt bij sortering in sommige apps).
- Genre (TCON): zet op “Podcast”.
- Jaar (TDRC): publicatiejaar.
- Hoesafbeelding (APIC): aflevering- of show-artwork. Houd het onder 500 KB — grote hoesafbeeldingen blazen elk afleveringsbestand op. Gebruik JPEG op 1400×1400 of 3000×3000 pixels, gecomprimeerd tot kwaliteit 70–80.
Hoewel RSS-feeds deze metadata ook dragen, zorgen ingebedde ID3-tags ervoor dat de informatie bij het bestand blijft, zelfs als het apart wordt gedownload of buiten een podcast-app gedeeld.
Normalisatie voor een consistent volume
Loudness-normalisatie zorgt dat je podcast op een consistent volume afspeelt — geen plotselinge uitschieters of wegzakkingen die luisteraars dwingen naar de volumeknop te grijpen.
De podcastindustrie heeft zich op -16 LUFS (Loudness Units Full Scale) als doelwaarde gesetteld:
- -16 LUFS: de standaard voor de meeste podcastplatforms. Luid genoeg om helder te blijven in lawaaiige omgevingen, zacht genoeg om vervorming te vermijden.
- -14 LUFS: door Spotify gebruikt voor muziek. Sommige podcasters mikken hierop voor iets luidere weergave, maar er blijft minder headroom over.
- True-peak-limiet: houd pieken op of onder -1 dBTP (decibel True Peak). Dit voorkomt clipping-artefacten door inter-sample-pieken tijdens MP3-codering en DAC-reconstructie.
| Platform | Doel-loudness | True-peak-limiet |
|---|---|---|
| Apple Podcasts | -16 LUFS | -1 dBTP |
| Spotify | -14 LUFS (normalisatie bij afspelen) | -1 dBTP |
| YouTube | -14 LUFS | -1 dBTP |
| EBU R128 (omroep) | -23 LUFS | -1 dBTP |
Pas loudness-normalisatie toe vóór de MP3-codering, tijdens je editing-/masteringstap. Normaliseren na codering kan extra kwaliteitsverlies introduceren. De meeste podcast-editingsoftware (Audacity, Hindenburg, Adobe Audition, Descript) bevat loudness-normalisatie als standaardfunctie.
Consistentie telt meer dan het exacte getal. Een podcast die consistent -18 LUFS is, klinkt beter voor luisteraars dan een die per aflevering tussen -12 en -22 LUFS slingert. Kies een doel en houd je eraan over alle afleveringen.
Een podcast-MP3 met deze instellingen exporteren
Audacity
- Kies Bestand → Audio exporteren en zet het formaat op MP3.
- Zet Kanalen op Mono en de sample rate op 44100 Hz.
- Zet de bitrate-modus op Constant en de kwaliteit op 96 of 128 kbps, en exporteer.
De converter op deze pagina
Upload de WAV en kies CBR 128 kbps, de laagste constante bitrate die hier beschikbaar is. De converter behoudt het aantal kanalen en de sample rate van je WAV, dus exporteer eerst een mono WAV van 44,1 kHz als je een mono MP3 wilt. Voor 64 of 96 kbps gebruik je een editor zoals Audacity.