jeg skrev nylig et langt innlegg om mp3-kodingsinnstillingene til de beste hundre podcastene på iTunes-listene. Et av mine forslag var veldig kontroversielt: folk På Reddit var uenige om det er greit å bruke VBR-koding i podcaster.
jeg ble overrasket over heftigheten som folk insisterte PÅ AT VBR er dårlig. «Den skal ikke brukes!»»Hold deg unna VBR.»Det var ingen mangel på folk som foreslo å unngå VBR, men lite i veien for substans bak disse påstandene.
jeg satt ut for å samle alle argumentene mot VBR at jeg kunne finne, og forsket hver for å finne ut om det var mulig å bekrefte påstandene bak hver av dem.
Først, men litt bakgrunn.
for å spare deg for klikket, gir jeg litt rask bakgrunn. I EN MP3 har du en bitrate. Bithastigheten er antall biter det tar å lagre ett sekund av lyd. En 128KBPS MP3-fil tar 128 kilobits å lagre ett sekund av lyd. Hvis du har en 128KBPS MP3-fil som er ti sekunder lang, vil det ta 1280 kilobits å lagre filen. Enkel.
SLIK FUNGERER CBR, Eller Konstant BitRate. Hele filen har en bitrate. Ulempen med dette er at ikke all lyd er skapt like. Noen lyd krever færre biter å lagre (si et øyeblikks stillhet). Noen lyd krever mer. Å ha en bitrate betyr at du potensielt kaster bort biter som lagrer lydfidelitet som du ikke trenger. DET er der VBR, Eller Variabel BitRate, kommer inn.
VBR tillater biter av filen som skal kodes på ulike bithastigheter. Den andre av nær stillhet kan klemme seg ned til 40kbps, mens et sekund med musikk kan hoppe opp til 160kbps. Gjort riktig, kan dette gi svært betydelige besparelser i størrelse.
hva er argumentene mot VBR?
I Stedet for å slå rundt bushen, la oss hoppe inn og se på argumentene mot VBR og teste gyldigheten av hver.
VBR bryter søker i mange apps.
Dette er sant, og jeg kaller dette spesielt i innlegget mitt:
med EN CBR fil, hoppe fremover eller bakover er enkelt fordi du kan beregne nøyaktig hvor du skal hoppe til. Med VBR kan hoppe fremover ti sekunder bety å hoppe opp til 1280 kilobit — men det kan være for mye hvis kvaliteten senkes innen de ti sekundene.
I Hovedsak kan Du ikke vite hvor du skal hoppe til i filen for å begynne å spille på en bestemt tidskode, fordi i stedet for å være en enkel multiplikasjon, må du kjenne bitratene til all lyden som fører opp til den tidskoden.
det finnes måter å unngå dette på. For lenge siden skapte folk en rekke standarder som tillater metadata å være innebygd I MP3, slik at dekodere kan finne ut hvor de skal søke. Jeg kunne skrive mer om dette, men det er et poeng fordi nesten ingen implementerer standarden.
det er verdt å merke seg at beløpet som tidskoden er av, vokser etter hvert som du kommer videre i filen. I begynnelsen av lydfilen er det lite sannsynlig at kvaliteten ble tapt i det hele tatt, og forskjellen kan bare være noen få millisekunder. Etter noen minutter vil det imidlertid vokse til sekunder. Etter en time og opp, kan det bli vokse til et minutt eller mer.
noen podcaster er svært korte. Tenk På Minnepalasset, som vanligvis har episoder mindre enn 15 minutter. Jeg ville være mer enn overrasket over å høre at søker i EN VBR-kodet T. M. P. episode var av med mer enn noen få håndfuller sekunder ved slutten av filen. (Jeg vil måle dette, men det er umulig å gjøre riktig uten tilgang til rå kildelyd)
Andre podcaster krever egentlig ikke en robust søkefunksjon. Asmr podcaster, podcaster med liten dialog eller uten dialog i det hele tatt, og podcaster med tankeløs jabber som vertene sier, spiller videospill, trenger ikke muligheten til å søke nøyaktig til en bestemt tidskode. Dette er en avveining som et ikke-null antall podcaster er villige til å gjøre.
Relativ søking er også i stor grad upåvirket AV VBR-koding. Podcasten Min Bror Min Bror og Meg bruker VBR-koding, og det er mulig å hoppe fremover med tretti sekunder og tilbake med ti sekunder med meget god nøyaktighet. Det er en god grunn til dette teknisk: på samme måte som å søke fra begynnelsen av en fil, er det lite sannsynlig at kvaliteten faller veldig mye i løpet av den lille tiden du hopper over. Hoppe fremover med tretti sekunder kan bety faktisk hoppe fremover med, si, trettien sekunder. Mengden unøyaktighet bestemmes av mengden lyd du hopper forbi, som med relativ søking er vanligvis ganske liten.
VBR gjør faktisk ikke filer mindre.
dette er halvt sant. VBR vil produsere filer av nesten lik STØRRELSE TIL CBR hvis gjennomsnittlig bitrate PÅ vbr filen er den samme som den faste bitrate PÅ CBR filen. VBR vil også produsere filer som er like store som EN CBR-fil hvis den aldri endrer bithastigheten (dvs.koderen velger aldri å senke kvaliteten, for eksempel med tilfeldig støy).
Unntatt saken der filen inneholder bare tilfeldig støy (hvorfor publiserer du det i podcasten din uansett?) forskjellen i størrelse har den åpenbare advarselen OM AT vbr-filen vil ha en lik eller større lydkvalitet generelt enn CBR-filen.
Vurder dette: du har en ti sekunders fil. Første halvdel er nær stillhet, og andre halvdel er high-fidelity musikk. Hvis VI koder dette SOM CBR ved 128kbps, blir det 1280kb. Hvis VI koder DET SOM VBR, og koderen hypotetisk koder første halvdel ved 64kbps og andre halvdel ved 192kbps, vil filstørrelsen fortsatt være 1280kb, og gjennomsnittlig bitrate er fortsatt 128kbps. Sammenligning av kvaliteten, men vi finner VBR filen høres mye bedre, siden stillheten bruker bare biter som den trenger og flere biter ble viet til musikken.
ved å justere giverens innstillinger, kan du effektivt redusere gjennomsnittlig bitrate for DIN VBR-kodede fil slik at kvaliteten omtrent samsvarer med den tilsvarende CBR-kodede filen. I teorien vil dette føre til en samlet reduksjon i filstørrelsen. Hvis DU velger vbr innstillinger uten å vite hva du gjør, skjønt, kan du lett ende opp med å benekte noen filstørrelse fordel du ville utlede fra å bruke VBR til å begynne med.
VBR-filer viser ikke riktig varighet.
som standard nei, en vbr filens varighet vil bli beregnet av sin byte lengde, noe som resulterer i en overvurdering(av samme grunn som søker ikke fungerer). Dette er lett utbedret, skjønt: bare å spesifisere lydvarigheten I ID3-kodene ved hjelp av en TLEN ramme vil fikse varigheten. Noen dekodere leser ikke rammen TLEN riktig, men de er få og langt mellom og blir nesten aldri brukt med appene og enhetene noen kan konsumere en podcast fra.
Kodere som Adobe Audition genererer ødelagte vbr-kodede filer.
Dette er noe jeg fant nevnt online på en rekke steder, sporing tilbake til et innlegg På Adobes fora. Uten å lese detaljene, er det enkelt å lage en SKY AV FUD rundt dette problemet. Det viser seg at dette er direkte relatert til det siste kravet om varighet: Audition var ganske enkelt ikke (angivelig) å legge til TLEN – dataene.
Oppdatering: jeg vil gjerne merke meg at jeg ikke har kunnet gjengi dette problemet Med Adobe Audition. Det kan være at et problem eksisterte i en tidligere versjon, men det ser ikke lenger ut til å være tilfelle. Jeg har oppdatert denne delen for å mer eksplisitt si at jeg ikke tror det er et problem Med Adobe Audition. Takk til @ audiblychuck På Twitter for å nå ut.
jeg vil gjøre argumentet om at dette er podcasterens ansvar, ikke et problem for lytteren. DET er enkelt Å legge TIL ID3-tagger, Og Audition er ikke den eneste hesten i dette løpet. Bak kulissene bruker Audition Fraunhofer MP3-koderen. Innlegget På Adobes fora refererer også Til Audition CS6, utgitt i 2012; jeg ville være overraskende hvis en nyere versjon løste problemet.
selv Om Adobe ikke løste dette, anbefaler mange innlegg på internett verktøy (MP3val, MP3Diag, etc.) som oppdager og løser dette problemet. Ffmpeg og LAME legger begge riktig TIL RIKTIG ID3-tag, noe som betyr at de fleste andre lydredigeringsprogrammer vil fungere riktig som standard.
Nesten alle moderne mp3-dekodere krever ikke EN TLEN ID3-tag for å bestemme riktig varighet av EN VBR MP3-fil.
VBR fungerer ikke med enkelte enheter.
det er anekdotiske bevis for å støtte dette. Jeg fant En HackerNews kommentarer tråd om enheten støtte. Her er roten kommentar av diskusjonen, snakker om en opplevelse fra over et tiår siden:
Som det viser seg, lytter ikke alle med en moderne enhet. Når vi prøvde VBR et betydelig antall mennesker ikke kunne lytte fordi DERES mp3 spille maskinvare / programvare av valget ikke støtter VBR filer riktig. De skjønte ikke at dette var problemet. De klaget bare på at filen var ødelagt mens den fungerte bra for alle andre.
En kommentator hadde et problem med Deres EigerMan F20:
min favoritt feil om dette var på en _ancient_ MP3-spiller jeg hadde (en EigerMan F20), som støttet VBR MP3s … ufullstendig. Det støttet ikke dekodingsområder med visse bithastigheter, så det ville bare stille hoppe over dem, noe som førte til ekstrem forvirring fra min side.
En annen kommentator hadde bedre hell med Sin Nomad Jukebox 3:
jeg er ganske sikker På At Min Nomad Jukebox 3 støttet VBRs fint, og det kommer opp på 14 år nå.
en bruker på hydrogenaudio hadde uflaks med EN DVD-spiller i 2006:
MIN DVD-spiller (Samsung HD-860) spiller ikke mp3 vbr-filer. Den er ca 2 år gammel og kommer til OG MED MED EN HDMI-utgang.
En annen kommentator i samme tråd hadde problemer med bilen sin:
min venn kjøpte en ny 2008 Pontiac G5 (dette er i utgangspunktet Grand Am, men de har siden omdøpt Den Til G5) og den kom med en fabrikkinstallert mp3-CD-kompatibel dekk. Enheten vil spille VBR filer helt fint, men vi har oppdaget at alle rammer i mp3 må kodes på 128kbps eller høyere.
jeg vil ikke fortsette å kopiere og lime inn innlegg om biler og MP3-spillere fra over et tiår siden. De fleste enhetene som folk nevner, ville ikke engang kunne holde en full podcast episode fra 2017!
min forskning på resten av nettet ga lignende resultater. Jeg kunne ikke finne en eneste rapport om en enhet laget de siste ti årene som ikke klarte å spille VBR-filer, og dette overrasker meg ikke. En uncited krav På Wikipedia stater:
per desember 2006, enheter som støtter BARE CBR kodede filer er i stor grad foreldet, som de aller fleste moderne bærbare musikkenheter og programvare støtte vbr kodede filer.
uten bevis for det motsatte, tror jeg ikke enhetskompatibilitet er et gyldig argument mot VBR.
hvis du har opplevd vbr-kompatibilitetsproblemer med en enhet, vil jeg gjerne høre om det. Vennligst nå ut!
Firefox støtter IKKE VBR.
Dette er ikke lenger sant. Firefox støtter VBR-filer. Jeg testet meg selv på både macOS og Windows 10. Firefox bruker vertsplattformens lyddekoder til å spille MP3 i stedet for å samle sin egen MP3-dekoder. På Windows slutter filen angivelig å spille midtstrøm på Grunn av tidskodeproblemene som er omtalt ovenfor. Dette synes ikke lenger å være tilfelle i det hele tatt. Filen spilles helt fint, uten avkorting og ingen søke problemer.
fagfolk sier ikke å bruke VBR.
jeg ble henvist til en podcast myndigheter og andre fagfolk for deres råd om hvorfor å unngå VBR. Jeg var interessert i argumentene som disse folkene fremsatte.
Update: i skrivende stund, en bug i min analyse kode feilaktig identifisert 15 podcaster i iTunes topp 100 podcaster som bruker VBR. I sannhet bruker bare EN VBR-koding. Dette nummeret ble sitert i min korrespondanse Med Rob Walch.
Den første personen jeg ble fortalt å komme i kontakt med, Er Rob Walch, som er NÅVÆRENDE VP for podcaster relations På Libsyn. Jeg sendte ham en e-post, og han svarte med en link til et blogginnlegg. Her er en utdrag fra det innlegget:
VBR er en gammel tech / hack som ble opprettet for å gjøre MP3 musikkfiler mindre og var populær tilbake i glanstid fildeling. I dag er det ikke behov for it — tilgjengelig båndbredde og lagring i dag er mye annerledes enn 15 og 20 år siden. MEN ENDA viktigere ISO-standarder FOR MP3 krever ikke spillere støtter det.
i henhold til standarden (ISO/IEC 11172-3:1993) Seksjon 2.4.2.3
«for å gi minst mulig forsinkelse Og kompleksitet, er dekoderen ikke nødvendig å støtte en kontinuerlig variabel bitrate når i lag i ELLER II. Layer III støtter variabel bitrate ved å bytte bitrate indeksen. Men i fritt format er fast bitrate nødvendig.»
og
«For Lag II er ikke alle kombinasjoner av total bitrate og modus tillatt.»
derfor ville de FLESTE Layer II-kodere ikke ha blitt skrevet MED VBR i tankene, Og Layer II VBR er en hack. Det fungerer for begrensede tilfeller. Å få det til å fungere i samme grad SOM MP3-stil VBR vil være en stor hack.
Kort SAGT ER VBRS dag i lys og massebruk langt bak oss — tilbake på slutten av 1990-tallet og pre-podcasting.
Alle disse argumentene er de samme som vi har dekket ovenfor, med en håndfull unntak. For En hevder Rob at båndbredde og lagring er billig. Dette er sant, men podcast listenership har også eksplodert de siste årene (selv siden hans innlegg i 2014). Internasjonalt, spesielt i fremvoksende markeder, er båndbredde dyrt for lytteren, noe som kan være en barriere for å øke lytterskapet utenfor USA.
han siterer OGSÅ mpeg ISO spec, men sitatene han trekker ut er feiltolket. MP3 står for «MPEG – 2 Audio Layer 3, «så sitatet» Layer III støtter variabel bitrate ved å bytte bitrate index, «egentlig betyr» MP3 støtter variabel bitrate.»Etter min forståelse kan du ikke være MP3-kompatibel og ikke støtte VBR (per spec). Det andre sitatet om «Layer 2» refererer TIL MPEG – 2 Audio Layer 2, som er en annen kodek fra MP3 helt og er irrelevant for diskusjonen.
jeg svarte med disse kommentarene og spurte om han hadde data for å underbygge disse påstandene. Svaret jeg fikk var litt … salt.
Matt,
Ærlig-artikkelen tittelen sa alt — det første og siste ordet PÅ VBR.
VBR er død-alle som presser på det, kjemper bare mot vindmøller.
CBR = bra
VBR = dårlig
det er virkelig så enkelt-ikke prøv å gjøre mer ut av dette-VBR er ikke fullt støtte av spillere og standarder.
hvis DU prøver Å presse FOR VBR-så til slutt vil du se tilbake på denne e-posten og ønsker du bare lyttet til meg. 🙂
Og fulgt raskt av
Hei Matt,
hvis du tenkte på å bruke VBR eller bruker VBR, Og etter at du har lest artikkelen min, er du ikke overbevist om å endre — du må virkelig virkelig lese dette:
http://theoatmeal.com/comics/believe
Det er en bitter ironi i hans svar, som jeg lar deg finne når du leser Matthew Inmans fine stripe om backfire-effekten. Jeg presset ham igjen for å gi detaljer, og fikk en annen kjølig svar:
Lykke til på din søken.
jeg anser VBR et dødt problem og ruller øynene når det kommer opp. Som er grunnen til innlegget jeg laget.
det virker hvert par år det hever sitt stygge hode.
Ikke sikker på hva 15% du så-sist gang jeg sjekket toppen viser det var 0%
http://podcast411.libsyn.com/will-increasing-your-bit-rate-equal-more-listeners
Se dette innlegget.
På dette punktet – det er mitt siste svar PÅ VBR.
For mye å gjøre for å kaste bort tid på dette-innlegget jeg laget gir deg all den informasjonen du trenger hvis du ser på det objektivt.
jeg anbefaler virkelig at du går videre TIL CBR, og du vil ikke ha noen problemer.
det koblede innlegget gjentar Bare Robs mantra: «VBR = dårlig.»Uten å peke på objektive fakta for å sikkerhetskopiere påstandene han gjør, kan Jeg ikke si At Robs meninger om saken holder mye vann.