VBR: är det faktiskt så illa som de säger?

jag skrev nyligen upp ett långt inlägg om MP3-kodningsinställningarna för de bästa hundra podcasts på iTunes-diagrammen. Ett av mina förslag var mycket kontroversiellt: folk på Reddit var inte överens om huruvida det är okej att använda VBR-kodning i podcasts.

jag blev förvånad över den häftighet som folk insisterade på att VBR är dåligt. ”Det ska inte användas!””Håll dig borta från VBR.”Det fanns ingen brist på folk som föreslog att undvika VBR, men lite i vägen för ämnet bakom dessa påståenden.

jag bestämde mig för att samla alla argument mot VBR som jag kunde hitta och undersökte var och en för att avgöra om det var möjligt att verifiera kraven bakom var och en av dem.

först, men lite bakgrund.

för att spara klicket ger jag lite snabb bakgrund. I en MP3 har du en bitrate. Bithastigheten är antalet bitar som krävs för att lagra en sekund ljud. En 128kbps MP3-fil tar 128 kilobit för att lagra en sekund ljud. Om du har en 128kbps MP3-fil som är tio sekunder lång tar det 1280 kilobit att lagra filen. Enkel.

så fungerar CBR, eller konstant BitRate. Hela filen har en bithastighet. Nackdelen med detta är att inte allt ljud skapas lika. Vissa ljud kräver färre bitar att lagra (säg ett ögonblick av tystnad). Vissa ljud kräver mer. Att ha en bithastighet innebär att du potentiellt slösar bort bitar som lagrar ljudtrohet som du inte behöver. Det är där VBR, eller variabel BitRate, kommer in.

VBR tillåter bitar av filen som ska kodas vid olika bithastigheter. Den andra av nästan tystnad kan klämma ner till 40kbps, medan en sekund av musik kan hoppa upp till 160kbps. Gjort korrekt kan detta ge mycket stora besparingar i storlek.

vilka är argumenten mot VBR?

istället för att slå runt busken, låt oss hoppa in och titta på argumenten mot VBR och testa giltigheten för varje.

VBR bryter söker i massor av program.

Detta är sant, och jag kallar specifikt detta i mitt inlägg:

med en CBR-fil är det enkelt att hoppa framåt eller bakåt eftersom du kan beräkna exakt var du ska hoppa till. Med VBR kan hoppa framåt tio sekunder innebära att hoppa upp till 1280 kilobits — men det kan vara för mycket om kvaliteten sänks inom de tio sekunderna.

i huvudsak kan du inte veta var du ska hoppa till i filen för att börja spela vid en viss tidskod, för istället för att vara en enkel multiplikation måste du känna till bithastigheterna för allt ljud som leder fram till den tidskoden.

det finns sätt att undvika detta. För länge sedan skapade folk ett antal standarder som gör att metadata kan inbäddas i MP3, så att avkodare kan ta reda på var de ska försöka. Jag skulle kunna skriva mer om detta, men det är en omtvistad fråga eftersom praktiskt taget ingen implementerar standarden.

det är värt att notera att det belopp med vilket tidskoden är avstängd växer när du kommer längre fram i filen. I början av ljudfilen är det osannolikt att kvaliteten sjönk med mycket alls, och skillnaden kan bara vara några millisekunder. Efter några minuter kommer det dock att växa till sekunder. Efter en timme och uppåt kan det växa till en minut eller mer.

vissa podcasts är mycket korta. Tänk på Minnespalatset, som i allmänhet har episoder mindre än 15 minuter. Jag skulle vara mer än förvånad över att höra att seeking in a VBR-kodad tmp-episod var avstängd med mer än några handfull sekunder i slutet av filen. (Jag skulle mäta detta, men det är omöjligt att göra korrekt utan tillgång till raw-källljudet)

andra podcasts kräver inte riktigt en robust sökfunktion. ASMR podcasts, podcasts med liten dialog eller utan dialog alls, och podcasts med mindless jabber som värdar, säg, Spela videospel alla behöver inte förmågan att noggrant söka till en viss tidskod. Detta är en avvägning som ett icke-noll antal podcasts är villiga att göra.

relativ sökning påverkas också till stor del av VBR-kodning. Podcasten min bror min bror och jag använder VBR-kodning, och det är möjligt att hoppa framåt med trettio sekunder och tillbaka med tio sekunder med mycket god noggrannhet. Det finns en bra anledning till detta tekniskt: precis som att söka från början av en fil är det osannolikt att kvaliteten sjunker mycket under den lilla delen av tiden du hoppar framåt. Att hoppa framåt med trettio sekunder kan innebära att man faktiskt hoppar framåt med, säg trettio sekunder. Mängden felaktighet bestäms av mängden ljud du hoppar över, vilket med relativ sökning vanligtvis är ganska liten.

VBR gör faktiskt inte filer Mindre.

detta är hälften sant. VBR kommer att producera filer av nästan lika stor storlek som CBR om den genomsnittliga bithastigheten för VBR-filen är densamma som den fasta bithastigheten för CBR-filen. VBR kommer också att producera filer lika stora som en CBR-fil om den aldrig ändrar bithastigheten (dvs kodaren väljer aldrig att sänka kvaliteten, till exempel med slumpmässigt brus).

exklusive fallet där filen bara innehåller slumpmässigt brus (varför publicerar du det i din podcast ändå?) skillnaden i storlek har den uppenbara försiktigheten att VBR-filen kommer att ha en lika eller större ljudkvalitet totalt sett än CBR-filen.

Tänk på detta: du har en tio sekunders fil. Den första halvan är nästan tystnad, och den andra halvan är Hifi-Musik. Om vi kodar detta som CBR vid 128kbps, blir det 1280kb. Om vi kodar det som VBR, och kodaren hypotetiskt kodar den första halvan vid 64kbps och den andra halvan vid 192kbps, kommer filstorleken fortfarande att vara 1280kb, och den genomsnittliga bithastigheten är fortfarande 128kbps. Att jämföra kvaliteten, men vi hittar VBR-filen låter mycket bättre, eftersom tystnaden bara använder de bitar som den behöver och fler bitar ägnades åt musiken.

genom att ställa in kodarens inställningar kan du effektivt sänka den genomsnittliga bithastigheten för din VBR-kodade fil så att kvaliteten ungefär matchar motsvarande CBR-kodad fil. I teorin kommer detta att leda till en total minskning av filstorleken. Om du väljer VBR-inställningar utan att veta vad du gör, kan du dock enkelt sluta negera någon filstorleksfördel som du skulle härleda från att använda VBR till att börja med.

VBR-filer visar inte rätt varaktighet.

som standard, Nej, En VBR-filens varaktighet beräknas med dess bytelängd, vilket resulterar i en överskattning (av samma anledning som sökningen inte fungerar). Detta kan dock enkelt åtgärdas: att bara ange ljudvaraktigheten i ID3-taggarna med en TLEN – ram fixar varaktigheten. Vissa avkodare läser inte TLEN – ramen korrekt, men de är få och långt ifrån och används nästan aldrig med de appar och enheter som någon kan konsumera en podcast från.

kodare som Adobe Audition genererar trasiga VBR-kodade filer.

detta är något jag hittade nämns på nätet i ett antal platser, spåra tillbaka till ett inlägg på Adobes forum. Utan att läsa detaljerna är det enkelt att skapa ett moln av FUD kring denna fråga. Det visar sig att detta är direkt relaterat till det sista påståendet om varaktighet: Audition var helt enkelt inte (påstås) att lägga till TLEN data.

Uppdatering: jag skulle vilja notera att jag inte har kunnat reproducera problemet med Adobe Audition. Det kan vara så att ett problem fanns i en tidigare version, men det verkar inte längre vara fallet. Jag har uppdaterat det här avsnittet för att mer uttryckligen ange att jag inte tror att det finns ett problem med Adobe Audition. Tack till @audiblychuck på Twitter för att nå ut.

jag skulle göra argumentet att detta är podcasterns ansvar, inte ett problem för lyssnaren. Det är enkelt att lägga till ID3-taggar, och Audition är inte den enda hästen i det här loppet. Bakom kulisserna använder Audition Fraunhofer MP3-kodaren. Inlägget på Adobes forum hänvisar också till Audition CS6, släppt 2012; Jag skulle vara förvånad om en nyare version fixade problemet.

även om Adobe inte fixade detta rekommenderar många inlägg på internet verktyg (MP3val, MP3Diag, etc.) som upptäcker och åtgärdar detta problem. Ffmpeg och LAME lägger båda till rätt ID3-tagg, vilket innebär att de flesta andra ljudredigeringsprogram fungerar korrekt som standard.

nästan alla moderna MP3-avkodare kräver inte en TLEN ID3-tagg för att bestämma rätt varaktighet för en VBR MP3-fil.

VBR fungerar inte med vissa enheter.

det finns anekdotiska bevis för att stödja detta. Jag hittade en HackerNews kommentarer tråd om enhetsstöd. Här är roten kommentar av diskussionen, talar om en upplevelse från över ett decennium sedan:

som det visar sig lyssnar inte alla med en modern enhet. När vi försökte VBR kunde ett betydande antal människor inte lyssna eftersom deras MP3-spelning av hårdvara / programvara inte stödde VBR-filer korrekt. De insåg inte att detta var problemet. De klagade bara på att filen var skadad medan den fungerade bra för alla andra.

en kommentator hade problem med sin EigerMan F20:

min favorit bugg om detta var på en _ancient_ MP3-spelare jag hade (en EigerMan F20), som stödde VBR MP3s…ofullständigt. Det stödde inte avkodningsregioner med vissa bithastigheter, så det skulle bara tyst hoppa över dem, vilket ledde till extrem förvirring från min sida.

en annan kommenterare hade bättre tur med sin Nomad Jukebox 3:

jag är ganska säker på att min Nomad Jukebox 3 stödde VBRs bra, och det kommer upp på 14 år nu.

en användare på hydrogenaudio hade otur med en DVD-spelare i 2006:

min DVD-spelare (Samsung HD-860) spelar inte Mp3 vbr-filer. Det handlar om 2 år gammal och även kommer med en HDMI-utgång.

en annan kommentator i samma tråd hade problem med sin bil:

min vän köpte en ny 2008 Pontiac G5 (det här är i grunden Grand Am men de har sedan bytt namn till G5) och det kom med ett fabriksinstallerat MP3-CD-kompatibelt däck. Enheten kommer att spela VBR-filer bara bra men vi har upptäckt att alla ramar i mp3 måste kodas på 128kbps eller högre.

jag kommer inte att fortsätta kopiera och klistra in inlägg om bilar och MP3-spelare från över ett decennium sedan. De flesta enheter som folk nämner skulle inte ens kunna hålla en fullständig podcast-episod från 2017!

min forskning över resten av webben gav liknande resultat. Jag kunde inte hitta en enda rapport om en enhet som gjorts under de senaste tio åren som misslyckades med att spela VBR-filer, och det förvånar mig inte. Ett ociterat påstående på Wikipedia säger:

från och med December 2006 är enheter som endast stöder CBR-kodade filer till stor del föråldrade, eftersom de allra flesta moderna bärbara musikenheter och programvara stöder VBR-kodade filer.

utan några bevis för motsatsen tror jag inte att enhetskompatibilitet är ett giltigt argument mot VBR.

om du har upplevt VBR-kompatibilitetsproblem med en enhet, skulle jag gärna höra om det. Vänligen nå ut!

Firefox stöder inte VBR.

Detta är inte längre sant. Firefox stöder VBR-filer. Jag testade mig själv på både macOS och Windows 10. Firefox använder värdplattformens ljudavkodare för att spela MP3 snarare än att kombinera sin egen MP3-avkodare. På Windows slutar filen påstås spela mid-stream på grund av de tidskodesproblem som diskuterats ovan. Detta verkar inte längre vara fallet alls. Filen spelade bara bra, utan trunkering och inga sökproblem.

proffsen säger att inte använda VBR.

jag hänvisades till en podcast myndigheter och andra branschfolk för deras råd om varför att undvika VBR. Jag var intresserad av de argument som dessa människor lade fram.

uppdatering: i skrivande stund identifierade ett fel i min analyskod felaktigt 15 podcasts i iTunes top 100 podcasts som att använda VBR. I själva verket använder endast en VBR-kodning. Detta nummer citerades i min korrespondens med Rob Walch.

den första personen jag fick höra att komma i kontakt med är Rob Walch, som är den nuvarande VP för podcaster relations på Libsyn. Jag skickade honom ett mail, och han svarade med en länk till ett blogginlägg. Här är ett utdrag från det inlägget:

VBR är en gammal tech / hack som skapades för att göra MP3-musikfiler mindre och var populär tillbaka i glansdagar fildelning. Idag finns det inget behov av det – tillgänglig bandbredd och lagring idag är mycket annorlunda än för 15 och 20 år sedan. Men ännu viktigare ISO-standarder för MP3 kräver inte att spelare stöder det.

enligt standarden (ISO/IEC 11172-3:1993) avsnitt 2.4.2.3

”för att ge minsta möjliga fördröjning och komplexitet krävs inte avkodaren för att stödja en kontinuerligt variabel bithastighet när den är i lager i eller II. lager III stöder variabel bithastighet genom att byta bithastighetsindex. I fritt format krävs dock fast bithastighet.”

och

” för Layer II är inte alla kombinationer av total bithastighet och läge tillåtna.”

därför skulle de flesta Layer II-kodare inte ha skrivits med VBR i åtanke, och Layer II VBR är ett hack. Det fungerar för begränsade fall. Att få det att fungera i samma utsträckning som MP3-stil VBR kommer att vara ett stort hack.

kort sagt VBR: s dag i ljuset och massanvändningen ligger långt bakom oss — tillbaka i slutet av 1990-talet och pre-podcasting.

alla dessa argument är desamma som vi har täckt ovan, med en handfull undantag. För en, Rob hävdar att bandbredd och lagring är billigt. Detta är sant, men podcast listenership har också exploderat de senaste åren (även sedan hans inlägg 2014). Internationellt, särskilt på tillväxtmarknader, är bandbredd dyrt för lyssnaren, vilket kan vara ett hinder för att öka lyssnandet utanför USA.

han citerar också MPEG ISO-specifikationen, men citaten som han extraherar tolkas felaktigt. MP3 står för” MPEG-2 Audio Layer 3″, så citatet” Layer III stöder variabel bithastighet genom att byta bithastighetsindex ”betyder verkligen” MP3 stöder variabel bithastighet.”Enligt min förståelse kan du inte vara MP3-kompatibel och inte stödja VBR (per spec). Det andra citatet om ”Layer 2” hänvisar till MPEG-2 Audio Layer 2, som är en annan codec från MP3 helt och är irrelevant för diskussionen.

jag svarade med dessa kommentarer och frågade om han hade data för att underbygga dessa påståenden. Svaret jag fick var lite … salt.

Matt,

ärligt talat — artikelns titel sa allt — det första och sista ordet på VBR.

VBR är död-den som driver på det kämpar bara mot väderkvarnar.

CBR = bra

VBR = dåligt

det är verkligen så enkelt — försök inte göra mer av detta — VBR stöds inte fullt ut av spelare och standarder.

om du försöker driva för VBR — så småningom kommer du att se tillbaka på det här e-postmeddelandet och önskar att du bara lyssnade på mig. 🙂

och följt snabbt av

Hej Matt,

om du tänkte använda VBR eller använder VBR och efter att du läst min artikel är du inte övertygad om att ändra – du behöver verkligen verkligen läsa detta:

http://theoatmeal.com/comics/believe

det finns en bitter ironi i hans svar, som jag låter dig hitta när du läser Matthew Inmans fina remsa om backfire-effekten. Jag pressade honom igen för att ge detaljer, och fick ett annat kyligt svar:

lycka till på din strävan.

jag anser VBR en död fråga och rulla ögon när det kommer upp. Vilket är anledningen till inlägget jag gjorde.

det verkar varje par år det höjer sitt fula huvud.

inte säker på vad 15% du såg-sista gången jag kollade topp visar det var 0%

http://podcast411.libsyn.com/will-increasing-your-bit-rate-equal-more-listeners

se det här inlägget.

just nu-det är mitt sista svar på VBR.

för mycket att göra för att slösa tid på detta — inlägget jag gjorde ger dig all information du behöver om du tittar på det objektivt.

jag rekommenderar verkligen att du går vidare till CBR och du kommer inte ha några problem.

det länkade inlägget upprepar bara Robs mantra: ”VBR = dåligt.”Utan att peka på objektiva fakta för att säkerhetskopiera de påståenden som han gör, kan jag inte säga att Robs åsikter i frågan håller mycket vatten.