jeg skrev for nylig et langt indlæg om MP3-kodningsindstillingerne for de øverste hundrede podcasts på iTunes-diagrammerne. Et af mine forslag var meget kontroversielt: folk på Reddit var uenige om, hvorvidt det er okay at bruge VBR-kodning i podcasts.
jeg blev overrasket over den heftighed, hvormed folk insisterede på, at VBR er dårlig. “Det skal ikke bruges!””Hold dig væk fra VBR.”Der var ingen mangel på folk, der foreslog at undgå VBR, men lidt i vejen for stoffet bag disse påstande.
jeg satte mig for at samle alle argumenterne mod VBR, som jeg kunne finde, og undersøgte hver for at afgøre, om det var muligt at verificere påstandene bag hver af dem.
først dog noget baggrund.
for at gemme dig klik, vil jeg give nogle hurtige baggrund. I en MP3 Har du en bitrate. Bithastigheden er antallet af bits, det tager at gemme et sekund af lyd. En 128kbps MP3-fil tager 128 kilobits til at gemme et sekund af lyd. Hvis du har en 128kbps MP3-fil, der er ti sekunder lang, tager det 1280 kilobits at gemme filen. Simpel.
Sådan fungerer CBR eller konstant bithastighed. Hele filen har en bitrate. Ulempen ved dette er, at ikke al lyd er skabt ens. Nogle lyd kræver færre bits til at gemme (sige et øjebliks stilhed). Nogle lyd kræver mere. At have en bitrate betyder, at du potentielt spilder bits, der gemmer lydkvalitet, som du ikke har brug for. Det er her VBR eller variabel BitRate kommer ind.
VBR tillader klumper af filen, der skal kodes på forskellige bitrates. Det andet af næsten stilhed kan klemme ned til 40kbps, mens et sekund af musik kan hoppe op til 160kbps. Udført korrekt kan dette give meget betydelige besparelser i størrelse.
- hvad er argumenterne mod VBR?
- VBR pauser søger i masser af apps.
- VBR gør faktisk ikke filer mindre.
- VBR-filer viser ikke den korrekte varighed.
- kodere som Adobe Audition genererer ødelagte VBR-kodede filer.
- VBR virker ikke med bestemte enheder.
- Firefoks understøtter ikke VBR.
- de professionelle siger ikke at bruge VBR.
hvad er argumenterne mod VBR?
i stedet for at slå rundt om bushen, lad os hoppe ind og se på argumenterne mod VBR og teste gyldigheden af hver.
VBR pauser søger i masser af apps.
dette er sandt, og jeg kalder det specifikt ud i mit indlæg:
med en CBR-fil er det nemt at springe frem eller tilbage, fordi du kan beregne præcis, hvor du skal hoppe til. Med VBR kan spring over ti sekunder betyde at springe op til 1280 kilobits — men det kan være for meget, hvis kvaliteten sænkes inden for de ti sekunder.
i det væsentlige kan du ikke vide, hvor du skal hoppe til i filen for at begynde at spille på en bestemt tidskode, for i stedet for at være en simpel multiplikation, skal du kende bitraterne for al lyd, der fører op til den tidskode.
der er måder at undgå dette på. Længe, længe siden, folk skabt en række standarder, der tillader metadata, der skal indlejres i MP3, så dekodere til at finde ud af, hvor de skal søge at. Jeg kunne skrive mere om dette, men det er et vigtigt punkt, fordi næsten ingen implementerer standarden.
det er værd at bemærke, at det beløb, hvormed tidskoden er slukket, vokser, når du kommer længere sammen i filen. I begyndelsen af lydfilen er det usandsynligt, at kvaliteten overhovedet blev droppet meget, og forskellen kan kun være et par millisekunder. Efter et par minutter vil det dog vokse til sekunder. Efter en time og op, kan det få vokse til et minut eller mere.
nogle podcasts er meget korte. Overvej Memory Palace, som generelt har episoder mindre end 15 minutter. Jeg ville være mere end overrasket over at høre, at seeking i en VBR-kodet tmp-episode var slukket med mere end et par håndfulde sekunder ved slutningen af filen. (Jeg ville måle dette, men det er umuligt at gøre korrekt uden adgang til den rå kilde lyd)
andre podcasts kræver ikke rigtig en robust søgefunktion. ASMR podcasts, podcasts med lidt dialog eller uden dialog overhovedet, og podcasts med mindless jabber som værter, sige, spille videospil alle behøver ikke evnen til præcist at søge til en bestemt tidskode. Dette er en afvejning, som et ikke-nul antal podcasts er villige til at lave.
relativ søgning påvirkes også stort set ikke af VBR-kodning. Podcasten Min bror min bror og jeg bruger VBR-kodning, og det er muligt at springe fremad med tredive sekunder og tilbage med ti sekunder med meget god nøjagtighed. Der er en god grund til dette teknisk: ligesom at søge fra begyndelsen af en fil, er det usandsynligt, at kvaliteten falder meget i løbet af den lille del af tiden, du springer forbi. At springe fremad med tredive sekunder kan betyde, at man faktisk springer fremad med, sige, etogtredive sekunder. Mængden af unøjagtighed bestemmes af mængden af lyd, du springer forbi, hvilket med relativ søgning normalt er ret lille.
VBR gør faktisk ikke filer mindre.
dette er halvt sandt. VBR producerer filer af næsten samme størrelse som CBR, hvis den gennemsnitlige bitrate for VBR-filen er den samme som den faste bitrate for CBR-filen. VBR producerer også filer, der er ens i størrelse til en CBR-fil, hvis den aldrig ændrer bithastigheden (dvs.koderen vælger aldrig at sænke kvaliteten, f. eks.
undtagen det tilfælde, hvor filen kun indeholder tilfældig støj (hvorfor offentliggør du det alligevel i din podcast?) forskellen i størrelse har den åbenlyse advarsel om, at VBR-filen generelt har en lige eller større lydkvalitet end CBR-filen.
overvej dette: du har en ti sekunders fil. Første halvdel er næsten stilhed, og anden halvdel er high-fidelity Musik. Hvis vi koder dette som CBR ved 128kbps, vil det være 1280kb. Hvis vi koder det som VBR, og koderen hypotetisk koder første halvdel ved 64kbps og anden halvdel ved 192kbps, vil filstørrelsen stadig være 1280kb, og den gennemsnitlige bitrate er stadig 128kbps. Sammenligning af kvaliteten finder vi dog, at VBR-filen lyder meget bedre, da stilheden kun bruger de bits, den har brug for, og flere bits blev afsat til musikken.
ved at indstille din koders indstillinger kan du effektivt sænke den gennemsnitlige bitrate for din VBR-kodede fil, så kvaliteten stort set svarer til den tilsvarende CBR-kodede fil. I teorien vil dette føre til en samlet reduktion i Filstørrelse. Hvis du vælger VBR-indstillinger uden at vide, hvad du laver, kan du dog nemt ende med at negere enhver filstørrelsesfordel, du ville få ved at bruge VBR til at begynde med.
VBR-filer viser ikke den korrekte varighed.
som standard Nej, En VBR-fils varighed beregnes ved dens byte-længde, hvilket resulterer i en overvurdering (af samme grund som søgning ikke fungerer). Dette afhjælpes dog let: blot at angive lydvarigheden i ID3-tags ved hjælp af en TLEN – ramme løser varigheden. Nogle dekodere læser ikke TLEN – rammen korrekt, men de er få og langt imellem og bruges næsten aldrig med de apps og enheder, som nogen måske bruger en podcast fra.
kodere som Adobe Audition genererer ødelagte VBR-kodede filer.
dette er noget, jeg fandt nævnt online på en række steder, spore tilbage til et indlæg på Adobes fora. Uden at læse detaljerne er det nemt at oprette en sky af FUD omkring dette problem. Det viser sig, at dette er direkte relateret til den sidste påstand om varighed: Audition var simpelthen ikke (angiveligt) at tilføje TLEN data.
opdatering: Jeg vil gerne bemærke, at jeg ikke har været i stand til at gengive dette problem med Adobe Audition. Det kan være, at der eksisterede et problem i en tidligere version, men det ser ikke længere ud til at være tilfældet. Jeg har opdateret dette afsnit for mere eksplicit at angive, at jeg ikke tror, at der er et problem med Adobe Audition. Tak til @audiblychuck på kvidre for at nå ud.
jeg vil gøre argumentet om, at dette er podcasterens ansvar, ikke et problem for lytteren. Det er nemt at tilføje ID3-tags, og Audition er ikke den eneste hest i dette løb. Bag kulisserne bruger Audition Fraunhofer MP3 encoder. Indlægget på Adobes fora henviser også til Audition CS6, udgivet i 2012; Jeg ville ikke være overrasket, hvis en nyere version løste problemet.
selvom Adobe ikke løste dette, anbefaler adskillige indlæg rundt om på internettet værktøjer (MP3val, MP3Diag osv.) at opdage og løse dette problem. Ffmpeg og LAME tilføjer begge korrekt det relevante ID3-tag, hvilket betyder, at de fleste andre lydredigeringsprogrammer fungerer korrekt som standard.
næsten alle moderne MP3-dekodere kræver ikke et TLEN ID3-tag for at bestemme den korrekte varighed af en VBR MP3-fil.
VBR virker ikke med bestemte enheder.
der er anekdotiske beviser til støtte for dette. Jeg fandt en Hackernyheder kommentarer tråd om enhed støtte. Her er rodkommentaren til diskussionen, taler om en oplevelse fra over et årti siden:
som det viser sig, lytter ikke alle ved hjælp af en moderne enhed. Da vi prøvede VBR, kunne et betydeligt antal mennesker ikke lytte, fordi deres MP3-afspillere ikke understøttede VBR-filer korrekt. De var ikke klar over, at dette var problemet. De klagede bare over, at filen var beskadiget, mens den fungerede fint for alle andre.
en kommentator havde et problem med deres EigerMan F20:
min yndlingsfejl om dette var på en _ANCIENT_ MP3-afspiller, jeg havde (en EigerMan F20), som understøttede VBR MP3s…ufuldstændigt. Det understøttede ikke afkodningsregioner med visse bitrates, så det ville bare stille over dem, hvilket førte til ekstrem forvirring fra min side.
en anden kommentator havde bedre held med sin Nomad jukeboks 3:
jeg er ret sikker på, at min Nomad jukeboks 3 understøttede vbrs fint, og det kommer op på 14 år nu.
en bruger på hydrogenaudio havde uheld med en DVD-afspiller i 2006:
min DVD-afspiller (Samsung HD-860) afspiller ikke mp3 vbr-filer. Den er omkring 2 år gammel og leveres endda med en HDMI-udgang.
en anden kommentator i samme tråd havde problemer med sin bil:
min ven købte en ny 2008 Pontiac G5 (dette er dybest set Grand Am, men de har siden omdøbt den til G5), og den fulgte med et fabriksinstalleret mp3-CD-kompatibelt dæk. Enheden vil spille VBR filer fint, men vi har opdaget, at alle rammer i mp3 skal kodes på 128kbps eller højere.
jeg vil ikke fortsætte med at kopiere og indsætte indlæg om biler og MP3-afspillere fra over et årti siden. De fleste af de enheder, som folk nævner, ville ikke engang kunne holde en fuld podcast-episode fra 2017!
min forskning på tværs af resten af internettet gav lignende resultater. Jeg kunne ikke finde en enkelt rapport om en enhed lavet i de sidste ti år, der ikke kunne afspille VBR-filer, og det overrasker mig ikke. En uncited krav på
fra December 2006 er enheder, der kun understøtter CBR-kodede filer, stort set forældede, da langt de fleste moderne bærbare musikenheder og programmer understøtter VBR-kodede filer.
uden bevis for det modsatte tror jeg ikke, at enhedskompatibilitet er et gyldigt argument mod VBR.
hvis du har oplevet VBR-kompatibilitetsproblemer med en enhed, vil jeg meget gerne høre om det. Venligst række ud!
Firefoks understøtter ikke VBR.
dette er ikke længere sandt.
de professionelle siger ikke at bruge VBR.
jeg blev henvist til en podcast myndigheder og andre branchefolk for deres råd om, hvorfor at undgå VBR. Jeg var interesseret i de argumenter, som disse folk fremsatte.
opdatering: i skrivende stund identificerede en fejl i min analyses kode forkert 15 podcasts i iTunes top 100 podcasts som brug af VBR. I virkeligheden bruger kun en VBR-kodning. Dette nummer blev citeret i min korrespondance med Rob.
den første person, jeg fik at vide at komme i kontakt med, er Rob, hvem er den nuværende VP for podcaster relations hos Libsyn. Jeg sendte ham en e-mail, og han svarede med et link til et blogindlæg. Her er et uddrag fra det indlæg:
VBR er en gammel tech / hack, der blev oprettet for at gøre MP3 musikfiler mindre og var populær tilbage i storhedstid fildeling. I dag er der ikke behov for det — tilgængelig båndbredde og opbevaring i dag er meget anderledes end for 15 og 20 år siden. Men endnu vigtigere ISO-standarder for MP3 kræver ikke spillere understøtter det.
i henhold til standarden (ISO/IEC 11172-3:1993) afsnit 2.4.2.3
“for at give den mindste mulige forsinkelse og kompleksitet er dekoderen ikke forpligtet til at understøtte en kontinuerligt variabel bithastighed, når den er i lag i eller II. lag III understøtter variabel bithastighed ved at skifte bithastighedsindeks. I frit format kræves der dog fast bithastighed.”
og
” for lag II er ikke alle kombinationer af total bitrate og tilstand tilladt.”
derfor ville de fleste Layer II-kodere ikke være skrevet med VBR i tankerne, og Layer II VBR er et hack. Det fungerer i begrænsede tilfælde. At få det til at fungere i samme omfang som MP3-stil VBR vil være et stort hack.
kort sagt er VBRS dag i lyset og massebrug langt bag os — tilbage i slutningen af 1990 ‘ erne og pre-podcasting.
alle disse argumenter er de samme som vi har dækket ovenfor, med en håndfuld undtagelser. For det første hævder Rob, at båndbredde og opbevaring er billig. Dette er sandt, men podcast listenership er også eksploderet i de senere år (selv siden hans indlæg i 2014). Internationalt, især på nye markeder, båndbredde er dyrt for lytteren, hvilket kan være en barriere for stigende lytterskab uden for USA.
han citerer også MPEG ISO spec, men de citater, han uddrager, fortolkes fejlagtigt. MP3 står for “MPEG – 2 Audio Layer 3”, så citatet “Layer III understøtter variabel bitrate ved at skifte bitrate indeks,” virkelig betyder “MP3 understøtter variabel bitrate.”Efter min forståelse kan du ikke være MP3-kompatibel og ikke understøtte VBR (pr. Det andet citat om “Layer 2” refererer til MPEG-2 Audio Layer 2, som er en anden codec fra MP3 helt og er irrelevant for diskussionen.
jeg svarede med disse kommentarer og spurgte, om han havde data til at underbygge disse påstande. Svaret Jeg fik var lidt … salt.
Matt,
ærligt — artikeltitlen sagde det hele — det første og sidste ord på VBR.
VBR er død — enhver, der presser på for det, kæmper bare med vindmøller.
CBR = god
VBR = dårlig
det er virkelig så simpelt — prøv ikke at gøre mere ud af dette — VBR understøttes ikke fuldt ud af spillere og standarder.
hvis du prøver at skubbe til VBR — så vil du til sidst se tilbage på denne e-mail og ønske, at du bare lyttede til mig. 🙂
og efterfulgt hurtigt af
Hej Matt,
hvis du tænkte på at bruge VBR eller bruger VBR, og efter at du har læst min artikel, er du ikke overbevist om at ændre — Du skal virkelig læse dette:
http://theoatmeal.com/comics/believe
der er en bitter ironi i hans svar, som jeg vil lade dig finde, når du læser Matthæus Inmans fine strimmel om backfire-effekten. Jeg pressede ham igen for at give detaljer, og modtog endnu et køligt svar:
held og lykke på din søgen.
jeg betragter VBR som et dødt problem og ruller øjne, når det kommer op. Hvilket er grunden til det indlæg, jeg lavede.
det ser ud til, at det hvert par år løfter sit grimme hoved.
Ikke sikker på, hvad 15% du så-sidste gang jeg tjekkede top viser det var 0%
http://podcast411.libsyn.com/will-increasing-your-bit-rate-equal-more-listeners
se dette indlæg.
på dette tidspunkt — det er mit sidste svar på VBR.
for meget at gøre for at spilde tid på dette — det indlæg, jeg lavede, giver dig al den information, du har brug for, hvis du ser objektivt på det.
jeg anbefaler virkelig, at du går videre til CBR, og du vil ikke have nogen problemer.
det linkede indlæg gentager kun Robs mantra: “VBR = bad.”Uden at pege på objektive fakta for at sikkerhedskopiere de påstande, han fremsætter, kan jeg ikke sige, at Robs meninger om sagen holder meget vand.