Audioknihy.net - Ondřej Caletka: "Audioknihy, jak je chápe Nokia" - Článek
 
 Známe vítěze o NEJ OBAL audioknih


40 audioknih, 4 vydavatelství a kdo získal ocenění NEJ obal? My už to víme!

Chci vědět víc

Přihlásit se
Hledat

supraphon  


Ondřej Caletka: "Audioknihy, jak je chápe Nokia"

datum Ne 29 listopad 2009, 22:11:41 autor Bára kategorie_obrazek Kategorie Externisté

Audioknihy jsou poslední dobou v módě a tak ani Nokia nezůstala stranou a vytvořila pro své symbianí mobily aplikaci, speciálně optimalizovanou pro přehrávání audioknih. Kromě aplikace také definovali vlastní formát pro ukládání audioknih a software pro převod do tohoto formátu. Ten je jako obvykle jen pro Windows a pod Wine se mu moc běhat nechce. Tak jsem vyrobil svou vlastní sadu nástrojů.

Ještě by se slušelo napsat, v čem vlastně nokiácký formát spočívá. Základním prvkem jsou vlastní audiodata. Pro jejich uložení zvolili formát Adaptive Multi-Rate - Wideband (AMR-WB, nebo AWB), což je formát vyvinutý iniciativou 3GPP pro přenos hlasu v mobilních sítích třetí generace. Nazývat jako širokopásmový kodek se vzorkovací frekvencí 16 kHz může vypadat jako troufalost, ale je třeba si uvědomit, že ve světě telefonie je vzorkování 16 kHz naprostý luxus. V každém případě kodek je to opravdu dobrý, při základním datovém toku 12650 bitů za sekundu je hlas (bez ruchu na pozadí) přenášen naprosto věrně, pouhým uchem jsem nebyl s to rozeznat jej od nekomprimovaného souboru se stejnou vzorkovací frekvencí. Dalším plusem pro kodek je, že referenční implementace v jazyce C je volně dostupná na webu 3GPP. Tato pozitiva a sociální jistoty trochu kalí ujištění, že kodek je patentován a jistá jeho využití je třeba licencovat (nezkoumal jsem, která).

A ještě poznámka k bitovému toku. Jak už název kodeku napovídá, bitových rychlostí je víc a jsou proměnlivé. Původní účel je ten, že pokud se mobilní terminál ocitne v místě se slabým pokrytím, může datový tok seškrtit na 8850, nebo 6600 bitů za sekundu, naopak v případě, že je na pozadí hlasu výrazný hluk, který kazí účinnost komrese, může si kodek přidat v několika stupních až na 23850 bitů za sekundu. Kromě toho kodek detekuje ticho a nahrazuje jej prázdnými rámci, případně řídicími rámci generátoru komfortního šumu. Každý rámec trvá přesně 20 ms. Výsledný bitový tok souboru *.awb je ještě jiný. Jednotlivé rámce jsou zarovnány na celé oktety a každý rámec je uveden jedním oktetem záhlaví. Tím se základní tok mění na 13200 bitů za sekundu. Prázdné rámce jsou ukládány jen jako osmibitová záhlaví, tedy sekunda ticha zabere 400 bitů.

Druhou částí audioknihy je metasoubor, kterým je přehrávač informován o počtu, délce a názvech jednotlivých kapitol. Budiž nokie ke cti, že použili obyčejný textový soubor, byť v trochu nestandardním kódování UTF-16. Aby se aplikace mohla v knize zorientovat, jsou součástí souboru délky jednotlivých audiosouborů v sekundách. Protože, jak jsem ukázal, není možné vypočítat časovou délku záznamu z velikosti souboru, napsal jsem malý prográmek, který v předloženém awb souboru spočte rámce a vypíše na standardní výstup délku souboru v milisekundách (na chybový výstup píše další statistiky souboru). Zároveň dodávám skriptík, který tuto část metasouboru vytvoří. Více informací je v souboru README.

Vlastní zkušenost s aplikací je celkem dobrá. Nicméně vidím jako neštastné, že se aplikace orientuje v souboru (například ukládá záložky) podle časového kódu, a ne podle polohy v souboru. Vzhledem k VBR povaze AMR souboru není totiž možné určit přesně časovou polohu v souboru bez postupného procházení od začátku ke konci. Aplikace to nedělá a tak se občas stane, že uložená záložka se svévolně "posune", někdy i o víc než minutu.

Jak už jsem napsal, samotný kodek je při poslechu hlasu bez ruchu na pozadí poslechově srovnatelný s nekomprimovaným signálem. Bohužel, ten zásadní poslechový rozdíl vznikne už prvotním snížením vzorkovacího kmitočtu na 16kHz. Pokud pochází originál z audiokazety, je to v pořádku, pokud jsem však převáděl originální MP3 22,050 kHz 64kbps, byly výstupní soubory o poznání méně kvalitní. Trochu pak pomůže decentně ubrat hloubky, aby záznam tolik nehuhlal.

 

Ondřej Caletka

 

Převzato z: http://shell.sh.cvut.cz/~oskar/blog/comments.php?y=09&m=01&entry=entry090121-132853