Industriestandaard: 96–128 kbps CBR mono
Wil je het korte antwoord: codeer je podcast als MP3, 96–128 kbps, CBR, mono, 44,1 kHz. Dat is wat Apple Podcasts aanbeveelt, wat Spotify accepteert en wat vrijwel elk podcasthostingplatform verwacht.
| 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.
- 50 % kleinere bestanden: een aflevering van 1 uur bij 96 kbps mono is ~42 MB. Dezelfde aflevering bij 96 kbps stereo zou ~42 MB zijn, maar met de bitrate verdeeld over twee identieke kanalen, wat de kwaliteit per kanaal verlaagt.
- Apple’s aanbeveling: Apple Podcasts beveelt in zijn richtlijnen voor podcasters uitdrukkelijk mono aan voor gesproken podcasts.
- 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.
Als je opnamesoftware opneemt op 48 kHz (gebruikelijk bij video-georiënteerde DAW's), is de conversie naar 44,1 kHz tijdens MP3-codering automatisch en verliesvrij voor spraakinhoud. Moderne encoders verzorgen deze resampling transparant.
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,5 MB | 14 MB | 14 MB | 21 MB |
| 30 min | 21 MB | 28 MB | 28 MB | 42 MB |
| 1 uur | 42 MB | 56 MB | 56 MB | 84 MB |
| 2 uur | 84 MB | 112 MB | 112 MB | 168 MB |
Voor een wekelijkse show die 4 afleveringen van een uur per maand publiceert:
- 96 kbps mono: ~168 MB/maand — past in Libsyn’s basispakket (250 MB)
- 128 kbps mono: ~224 MB/maand — krap in het 250 MB-pakket
- 192 kbps stereo: ~336 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 (muziek) / -16 LUFS (spraak) | -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.