VBR: tényleg olyan rossz, mint mondják?

nemrég írtam egy hosszadalmas bejegyzést az MP3 kódolási beállításairól a top száz podcast az iTunes charts. Az egyik javaslatom nagyon ellentmondásos volt: a Reddit emberei nem értettek egyet abban, hogy rendben van-e a VBR kódolás használata a podcastokban.

meglepett az a vehemencia, amellyel az emberek ragaszkodtak ahhoz, hogy a VBR rossz. “Nem szabad használni!””Maradj távol a VBR-től.”Nem volt hiány az emberek azt javasolja, hogy elkerüljék VBR, de kevés az olyan anyag mögött ezeket az állításokat.

nekiláttam, hogy összegyűjtsem az összes VBR elleni érvet, amelyet találtam, és mindegyik után kutattam, hogy megállapítsam, lehetséges-e ellenőrizni az egyes állítások mögött.

először is, Néhány háttér.

a kattintás mentéséhez gyors hátteret adok. Egy MP3-ban van egy bitráta. A bitráta az egy másodperces hang tárolásához szükséges bitek száma. A 128kbps MP3 fájl 128 kilobitot vesz igénybe egy másodperces hang tárolásához. Ha 128kbps MP3 fájlja van, amely tíz másodperc hosszú, akkor a fájl tárolásához 1280 kilobit szükséges. Egyszerű.

így működik a CBR vagy az állandó bitráta. Az egész fájl egy bitrátával rendelkezik. Ennek hátránya, hogy nem minden hang jön létre egyenlően. Néhány hang tárolásához kevesebb bit szükséges (mondjuk egy pillanatnyi csend). Néhány hang többet igényel. Egy bitráta azt jelenti, hogy potenciálisan pazarolja a biteket, amelyek olyan hanghűséget tárolnak, amelyre nincs szüksége. Itt jön be a VBR vagy a változó bitráta.

a VBR lehetővé teszi a fájl egyes részeinek különböző bitrátákon történő kódolását. Ez a második a Közel-csend lehet squish le 40kbps, míg egy második zene lehet ugrani akár 160kbps. Helyesen végzett, ez nagyon jelentős megtakarítást eredményezhet.

milyen érvek szólnak a VBR ellen?

ahelyett, hogy a bokor körül vernénk, ugorjunk be, és nézzük meg a VBR elleni érveket, és teszteljük mindegyik érvényességét.

VBR szünetek keres sok apps.

ez igaz, és ezt kifejezetten felhívom a bejegyzésemben:

CBR fájl esetén az előre vagy hátra ugrás egyszerű, mert pontosan kiszámíthatja, hová ugorjon. A VBR-rel a tíz másodperc előtti ugrás akár 1280 kilobit átugrását is jelentheti-de ez túl sok lehet, ha a minőség ezen a tíz másodpercen belül csökken.

lényegében nem tudhatja, hová ugorjon a fájlban, hogy elkezdjen játszani egy adott időkóddal, mert egyszerű szorzás helyett ismernie kell az adott időkódhoz vezető összes hang bitrátáját.

vannak módok ennek elkerülésére. Réges-régen, az emberek számos szabványt hoztak létre, amelyek lehetővé teszik a metaadatok beágyazását az MP3-ba, lehetővé téve a dekóderek számára, hogy kitalálják, hol keressék. Írhatnék erről többet, de ez vitás pont, mert gyakorlatilag senki sem valósítja meg a szabványt.

érdemes megjegyezni, hogy az az összeg, amellyel az időkód ki van kapcsolva, növekszik, ahogy tovább halad a fájlban. A hangfájl elején nem valószínű, hogy a minőség egyáltalán nagyon csökkent volna, és a különbség csak néhány milliszekundum lehet. Néhány perc múlva, bár, hogy növekedni fog a másodperc. Egy óra múlva akár egy percig is növekedhet.

néhány podcast nagyon rövid. Tekintsük a Memóriapalotát, amelynek epizódjai általában kevesebb, mint 15 perc. Több mint meglepődnék, ha azt hallanám, hogy a VBR-kódolású T. M. P. epizódban a fájl végére több mint néhány marék másodperccel kikapcsolt. (Ezt mérném, de lehetetlen helyesen csinálni a nyers forrás hanghoz való hozzáférés nélkül)

más podcastok nem igazán igényelnek robusztus keresési funkciót. ASMR podcastok, podcastok kis párbeszéd vagy anélkül párbeszéd egyáltalán, és podcastok mindless jabber, mint a házigazdák, mond, videojátékok minden nem kell a képesség, hogy pontosan igyekeznek egy adott időkód. Ez egy kompromisszum, amelyet nem nulla számú podcast hajlandó megtenni.

a relatív keresést a VBR kódolás is nagyrészt nem befolyásolja. A podcast A bátyám a bátyám és én VBR kódolást használ, és nagyon jó pontossággal lehet harminc másodperccel előre ugrani, tíz másodperccel vissza. Ennek technikailag jó oka van: csakúgy, mint a fájl elejétől való keresés, nem valószínű, hogy a minőség nagyon sokat süllyed a kis idő alatt, amelyet előre ugrik. Ha harminc másodperccel előre ugrunk, az azt jelentheti, hogy mondjuk harmincegy másodperccel előre ugrunk. A pontatlanság mértékét az a hangmennyiség határozza meg, amelyet átugrasz, ami relatív kereséssel általában meglehetősen kicsi.

a VBR valójában nem teszi kisebbé a fájlokat.

ez félig igaz. A VBR a CBR-rel majdnem azonos méretű fájlokat fog előállítani, ha a VBR fájl átlagos bitrátája megegyezik a CBR fájl rögzített bitrátájával. A VBR a CBR fájl méretével megegyező méretű fájlokat is készít, ha soha nem változtatja meg a bitrátát (azaz a kódoló soha nem választja a minőség csökkentését, például véletlenszerű zaj esetén).

kivéve azt az esetet, amikor a fájl csak véletlenszerű zajt tartalmaz (egyébként miért teszi közzé ezt a podcastjában?) a méretbeli különbségnek nyilvánvaló figyelmeztetése van, hogy a VBR fájl összességében azonos vagy jobb hangminőséggel rendelkezik, mint a CBR fájl.

fontolja meg ezt: van egy tíz másodperces aktája. Az első fele szinte csend, a második fele pedig nagy hűségű zene. Ha ezt CBR-ként kódoljuk 128 kb / s sebességgel, akkor 1280 KB lesz. Ha VBR-ként kódoljuk, és a kódoló hipotetikusan az első felét 64 kB / s, a második felét 192 kb / s sebességgel kódolja, akkor a fájlméret továbbra is 1280 kb, Az átlagos bitráta pedig továbbra is 128 kb / s. A minőséget összehasonlítva azonban azt találjuk, hogy a VBR Fájl sokkal jobban hangzik, mivel a csend csak a szükséges biteket használja, és több bitet szenteltek a zenének.

a kódoló beállításainak beállításával hatékonyan csökkentheti a VBR-kódolású fájl átlagos bitrátáját úgy, hogy a minőség nagyjából megegyezzen az egyenértékű CBR-kódolású fájllal. Elméletileg ez a fájlméret általános csökkenéséhez vezet. Ha úgy dönt, VBR beállításokat anélkül, hogy tudnánk, mit csinálsz, bár, akkor könnyen a végén tagadja minden fájlméret előny akkor származik a VBR kezdeni.

a VBR fájlok nem mutatják a megfelelő időtartamot.

alapértelmezés szerint nem, a VBR fájl időtartamát a bájt hossza számítja ki, ami túlbecsülést eredményez (ugyanazon okból, hogy a keresés nem működik). Ez azonban könnyen orvosolható: ha egyszerűen megadja az audio időtartamát az ID3 címkékben egy TLEN keret segítségével, akkor rögzíti az időtartamot. Néhány dekóder nem olvassa el helyesen a TLEN keretet, de kevés és messze vannak egymástól, és szinte soha nem használják azokat az alkalmazásokat és eszközöket, amelyekről valaki podcastot fogyaszthat.

az olyan kódolók, mint az Adobe Audition, hibás VBR-kódolású fájlokat generálnak.

ezt találtam az interneten számos helyen, az Adobe fórumainak egyik bejegyzéséhez vezetve. A részletek elolvasása nélkül könnyű létrehozni egy FUD felhőt a probléma körül. Kiderült, hogy ez közvetlenül kapcsolódik az időtartammal kapcsolatos utolsó állításhoz: az Audition egyszerűen nem (állítólag) adta hozzá a TLEN adatokat.

frissítés: szeretném megjegyezni, hogy nem sikerült reprodukálni ezt a problémát az Adobe Audition programmal. Lehet, hogy egy korábbi verzióban létezett egy probléma, de úgy tűnik, hogy ez már nem így van. Frissítettem ezt a részt, hogy pontosabban kijelentsem, hogy nem hiszem, hogy probléma van az Adobe Audition programmal. Köszönet @audiblychuck-nak a Twitteren, hogy elérte.

azzal érvelnék, hogy ez a podcaster felelőssége, nem pedig a hallgató problémája. Könnyű hozzáadni az ID3 címkéket, és az Audition nem az egyetlen ló ebben a versenyben. A színfalak mögött az Audition a Fraunhofer MP3 kódolót használja. Az Adobe fórumain található bejegyzés az Audition CS6-ra is utal, amelyet 2012-ben adtak ki; nem lennék meglepve, ha egy újabb verzió megoldaná a problémát.

még ha az Adobe nem is javította ezt, az interneten számos bejegyzés javasolja az eszközöket (MP3val, MP3Diag stb.), amelyek felismerik és megoldják ezt a problémát. Az Ffmpeg és a LAME egyaránt helyesen adja hozzá a megfelelő ID3 címkét, ami azt jelenti, hogy a legtöbb más hangszerkesztő szoftver alapértelmezés szerint megfelelően fog működni.

szinte minden modern MP3 dekóder nem igényel TLEN ID3 címkét a VBR MP3 fájl megfelelő időtartamának meghatározásához.

a VBR nem működik bizonyos eszközökkel.

anekdotikus bizonyítékok támasztják alá ezt. Találtam egy HackerNews comments szálat az eszköz támogatásáról. Itt van a vita gyökér megjegyzése, több mint egy évtizeddel ezelőtti tapasztalatról beszél:

mint kiderült,nem mindenki hallgat egy modern eszközt. Amikor megpróbáltuk VBR jelentős számú ember nem tudott hallgatni, mert az MP3 játszik hardver / szoftver a választás nem támogatja a VBR fájlokat megfelelően. Nem vették észre, hogy ez a probléma. Csak panaszkodtak, hogy a fájl sérült, miközben mindenki más számára jól működött.

az egyik hozzászólónak problémája volt a sajátjával EigerMan F20:

a kedvenc bug erről volt egy _ancient_ MP3 lejátszó volt (egy EigerMan F20), amely támogatta VBR MP3s…hiányosan. Nem támogatta a bizonyos bitrátákkal rendelkező régiók dekódolását, ezért csak csendben kihagyta őket, ami rendkívüli zavart okozott a részemről.

egy másik hozzászólónak nagyobb szerencséje volt Nomad Jukebox 3-mal:

biztos vagyok benne, hogy a Nomad Jukebox 3 jól támogatja a VBRs-t, és ez most 14 éves lesz.

a hydrogenaudio egyik felhasználójának balszerencséje volt egy DVD-lejátszóval 2006:

a DVD-lejátszó (Samsung HD-860) nem játszik le mp3 vbr fájlokat. Körülbelül 2 éves, sőt HDMI kimenettel is rendelkezik.

egy másik hozzászólónak ugyanabban a szálban gondja volt az autójával:

barátom vásárolt egy új 2008-as Pontiac G5-öt (ez alapvetően a Grand Am, de azóta átnevezték G5-re), és gyárilag telepített mp3-CD kompatibilis paklival érkezett. Az egység jól fogja lejátszani a VBR fájlokat, de felfedeztük, hogy az mp3 összes képkockáját 128kbps vagy annál nagyobb sebességgel kell kódolni.

nem fogok több mint egy évtizeddel ezelőtti autókat és MP3 lejátszókat tartalmazó bejegyzéseket másolni és beilleszteni. A legtöbb eszköz, amelyet az emberek megemlítenek, még egy teljes podcast epizódot sem tudna tartani 2017-től!

az interneten végzett kutatásaim hasonló eredményeket hoztak. Nem találtam egyetlen jelentést sem az elmúlt tíz évben készült eszközről, amely nem tudta lejátszani a VBR fájlokat, és ez nem lep meg. Egy meg nem nevezett állítás a Wikipédián Államok:

2006 decemberétől a csak CBR kódolású fájlokat támogató eszközök nagyrészt elavultak, mivel a modern hordozható zenei eszközök és szoftverek túlnyomó többsége támogatja a VBR kódolású fájlokat.

ellenkező bizonyíték nélkül nem hiszem, hogy az eszközkompatibilitás érvényes érv a VBR ellen.

ha VBR kompatibilitási problémákat tapasztalt egy eszközzel, szeretném hallani róla. Kérem, érje el!

a Firefox nem támogatja a VBR-t.

ez már nem igaz. A Firefox támogatja a VBR fájlokat. Teszteltem magam mind a macOS, mind a Windows 10 rendszeren. A Firefox A gazdagép platform audio dekóderét használja MP3 lejátszására, ahelyett, hogy saját MP3 dekóderét kötegelné. Windows rendszeren a fájl állítólag leállítja a mid-stream lejátszását a fent tárgyalt időkód-problémák miatt. Úgy tűnik, hogy ez már egyáltalán nem így van. A fájl játszott csak finom, nem csonkítás és nem keresik kérdések.

a szakemberek azt mondják, hogy ne használja a VBR-t.

egy podcast hatósághoz és más iparági szakemberekhez utaltak, hogy tanácsot adjanak arról, hogy miért kerüljük el a VBR-t. Érdekeltek azok az érvek, amelyeket ezek az emberek előadtak.

frissítés: abban az időben az írás, egy hiba az én elemzés kód helytelenül azonosított 15 podcastok az iTunes top 100 podcastok, mint a VBR. Valójában csak egy használ VBR kódolást. Ezt a számot idézték a Rob Walch-szal folytatott levelezésemben.

az első személy, akivel kapcsolatba léptem, Rob Walch, aki a Libsyn podcaster relations jelenlegi alelnöke. Küldtem neki egy e-mailt, ő pedig egy blogbejegyzés linkjével válaszolt. Itt van egy részlet abból a bejegyzésből:

a VBR egy régi tech / hack, amelyet azért hoztak létre, hogy az MP3 zenei fájlok kisebbek legyenek, és népszerű volt a fájlmegosztás fénykorában. Ma nincs szükség rá — a rendelkezésre álló sávszélesség és tárhely ma sokkal más, mint 15 és 20 évvel ezelőtt. De ami még fontosabb, az MP3 ISO szabványai nem igénylik a lejátszók támogatását.

a szabvány (ISO/IEC 11172-3:1993) 2.4.2.3. szakasz

“a lehető legkisebb késleltetés és összetettség biztosítása érdekében a dekódernek nem kell folyamatosan változó bitrátát támogatnia az I. vagy II.rétegben. a III. réteg támogatja a változó bitrátát a bitráta index váltásával. Szabad formátumban azonban rögzített bitráta szükséges.”

és

“a II.réteg esetében a teljes bitráta és a mód nem minden kombinációja engedélyezett.”

ezért a legtöbb Layer II kódolót nem a VBR szem előtt tartásával írták volna, és a Layer II VBR egy hack. Korlátozott esetekben működik. Az, hogy ugyanolyan mértékben működjön, mint az MP3 stílusú VBR, nagy hack lesz.

röviden VBR napja a fény és a tömeges használat messze mögöttünk-vissza a késő 1990-es és pre-podcasting.

ezek az érvek ugyanazok, mint a fentiekben, néhány kivétellel. Rob azt állítja, hogy a sávszélesség és a tárhely olcsó. Ez igaz, de a podcast hallgatottsága az utóbbi években is felrobbant (még 2014-es posztja óta). Nemzetközi szinten, különösen a feltörekvő piacokon, a sávszélesség drága a hallgató számára, ami akadályt jelenthet az Egyesült Államokon kívüli hallgatóság növelésében.

ő is idézi az MPEG ISO spec, de az idézetek ő kivonatok félreértelmezik. Az MP3 az “MPEG-2 Audio Layer 3” kifejezést jelenti, tehát a “Layer III támogatja a változó bitrátát a bitráta index váltásával,” valójában azt jelenti, hogy “az MP3 támogatja a változó bitrátát.”Megértésem szerint nem lehet MP3-kompatibilis, és nem támogatja a VBR-t (a specifikáció szerint). A ” Layer 2 “-ről szóló második idézet az MPEG-2 Audio Layer 2-re utal, amely teljesen más kodek, mint az MP3, és nem releváns a vita szempontjából.

ezekkel a megjegyzésekkel válaszoltam, megkérdezve, hogy vannak-e adatai, amelyek alátámasztják ezeket az állításokat. A válasz, amit kaptam, egy kicsit … sós volt.

Matt,

őszintén — a cikk címe azt mondta, hogy minden — az első és utolsó szó a VBR.

a VBR halott — bárki, aki erre törekszik, csak a szélmalmok ellen harcol.

CBR = jó

VBR = rossz

ez tényleg ilyen egyszerű — ne próbálj többet kihozni ebből — a VBR-t nem támogatják teljes mértékben a játékosok és a szabványok.

ha próbál nyomni a VBR — akkor végül akkor nézd vissza ezt az e-mailt, és szeretném, ha csak hallgatott rám. 🙂

és gyorsan követi

Szia Matt,

ha arra gondolt, hogy használja a VBR vagy használja VBR, és miután elolvasta a cikket, hogy nem győződve arról, hogy változtatni — meg kell, hogy tényleg igazán olvasni ezt:

http://theoatmeal.com/comics/believe

van egy keserű irónia a válaszában, amelyet hagyom, hogy megtalálja, amikor elolvassa Matthew Inman finom szalagját a backfire effektusról. Ismét megnyomtam, hogy adjon részleteket, és újabb hideg választ kapott:

sok szerencsét a küldetéshez.

úgy vélem, VBR halott kérdés and roll szemét, amikor jön fel. Ez az oka a poszt tettem.

úgy tűnik, néhány évente felemeli csúnya fejét.

nem tudom, mi 15% láttad-az utolsó alkalommal, amikor megnéztem top mutatja, hogy 0%

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

lásd ezt a bejegyzést.

ezen a ponton — ez az utolsó válasz a VBR.

túl sok tennivaló, hogy időt pazaroljak erre — az általam készített bejegyzés minden szükséges információt megad, ha objektíven nézi.

nagyon ajánlom, hogy lépjen tovább a CBR-re, és nem lesz problémája.

a linkelt bejegyzés csak Rob mantráját ismétli: “VBR = rossz.”Anélkül, hogy objektív tényekre mutatnék az állításainak alátámasztására, nem mondhatom, hogy Rob véleménye az ügyben sok vizet tartalmaz.