Živě.cz o počítačích a internetu

Umíme to s Delphi: 144. díl – jak přinutit starý přehrávač, aby přehrával nové empétrojky?

Václav Kadlec 12.4.2005

Dnešní článek se zabývá především následující otázkou: jak zajistit, aby starší přehrávače empétrojek, které nemají ani ponětí o tom, že do souborů vkládáme nehudební informace - ID3 tagy - přehrály správně i soubor, který takový tag obsahuje? Kromě toho si více povíme o umístění ID3v2 tagu v souboru.

Dnešní článek konečně uzavře problematiku nastíněnou v předchozích pokračováních: dokončíme zkoumání toho, jak jsou organizovány rámce v ID3v2 tagu, což je technologie umožňující rozšířit hudební (typicky MP3) soubory o možnost uchování textových a jiných význačných (avšak zcela nehudebních) informací.

Na samotný úvod si připomeňme hrubý nástin toho, o čem v poslední době vlastně mluvíme.

Ve čtyřech předešlých článcích jsme se poměrně podrobně a do detailu zabývali strukturou a formátem ID3v2 tagu. Základním informačním zdrojem pro nás přitom byla specifikace uvedená na URL http://www.id3.org/id3v2.4.0-structure.txt.

Shrnutí obsahu předešlých částech najdete v následujícím přehledu:

díl 136 se zabývá obecným popisem ID3 tagů jako takových,
náplní dílu 137 je praktická implementace podpory ID3 tagů v programech,
také díl 138 se zabývá praktickou implementací, tentokráte modifikací ID3 tagů,
díl 139 potom podrobně rozebírá druhou verzi tagů (ID3v2) a shrnuje rozdíly mezi jednoduchou první a sofistikovanou druhou verzí,
díl 140 je věnován specifikaci formátu a struktury hlavičky ID3v2 tagů,
díl 141 je dalším pokračováním rozboru struktury ID3v2 tagu, konkrétně pak popisuje rozšířenou hlavičku, padding a patičku,
díl 142 popisuje hlavní součást ID3v2 tagu, a to datové rámce. Tento díl je vlastně první částí popisu datových rámců, jehož ¨pokračování je uvedeno v
dílu 143 zveřejněného před týdnem. Ve 143. dílu najdete především popis věcí jako pořadí rámců, počet rámců, kódování apod.

Než se vrhneme do vod ID3v2, podívejme se naše tradiční schéma, s jehož pomocí si demonstrujeme obecnou strukturu ID3v2 tagu. Tag tedy vypadá zhruba takto:

Dnešní článek je primárně zaměřen na dvojici informací, které dosud o ID3v2 technologii nevíme. Těmito informacemi jsou:

umístění tagu v souboru a
tzv. mechanismus "unsynchronization".

Pojďme na ně!

Umístění tagu v souboru

Takže, kde je vlastně ID3v2 tag v souboru umístěn? Defaultní pozice pro tag je taková, že tag by měl umístěn před samotnými audio daty. Proč? Pokud je toto pravidlo splněno, mohou přehrávače podporující technologii ID3v2 těžit z informací umístěných v tagu v případě, kdy je hudební soubor streamován.

V případě, že si nejste jisti, o čem to teď mluvím, pokusím se vše vysvětlit. Streamování je obecně technologie, díky níž je možné zpracovávat soubor postupně, zároveň s jeho získáváním, otvíráním nebo stahováním.

Jinak řečeno, v klasickém případě (tedy ne v případě streamování) probíhá zpracování tak, že na začátku práce otevřeme (případně načteme) celý soubor a následně zpracováváme informace, které potřebujeme. Streamování je odlišné a používá se např. v případě stahování souborů z Internetu nebo v případě zpracovávání velkých souborů určitých typů. Určitě jste třeba slyšeli o pojmu "streamování videa"; znamená to, že videosoubor na začátku streamování vůbec nemáme celý, máme jen jeho začátek, nicméně začneme jej v přehrávači přehrávat a jak přehrávání pokračuje, jiná aplikace (nebo samotný přehrávač) kdesi na pozadí stahuje následující části souborů.

Je asi zřejmé, že pokud budeme streamovat audiosoubor, jehož ID3 tag bude umístěn na samotném konci, nedozvíme se o souboru zhola nic až do okamžiku, kdy dojde ke stažení celého jeho obsahu. Jinak řečeno, pokud bychom streamovali soubor s ID3 tagem umístěným na konci, mohli bychom třeba zobrazit název písničky až po jejím skoro celém přehrání.

Právě tomu se pokouší technologie ID3v2 zabránit, a proto doporučuje umístit tag před audiodata tak, aby byl tag přečten včas i při streamování skladby. Jedná se nicméně pouze a jen o doporučení: rozhodnete-li se z nějakého důvodu (který může být v určitých situacích poměrně rozumný) umístit tag na konec, případně umístit část na začátek a část na konec, nebude to specifikaci v zásadě odporovat.

Specifikace se vás pouze pokouší přimět k tomu, abyste se při úvahách o umístění tagu pokusili řídit následujícími pravidly (v pořadí podle důležitosti, tedy první je nejdůležitější a pouze v případě, kdy máte vážný důvod se jím neřídit, postupte k druhému ):

Pokuste se dát celý tag před audiodata.
Dejte před audiodata alespoň tag s nejdůležitějšími informacemi. Za audiodata pak následně umístěte druhý tag; zajistěte, aby předcházel případné tagy z jiných tagovacích systémů nebo technologií. První tag (umístěný před souborem) pak z definice musí obsahovat rámec SEEK.
Dejte tag za audiodata, avšak před tagy z jiných tagovacích systémů nebo technologií.

Specifikace dále doporučuje způsob, jak vyhledávat, zda soubor obsahuje ID3v2 tag nebo nikoliv:

Vyhledejte, zda před audiodaty je tag používající vzor popsaný v dílu 140. tohoto seriálu.
Pokud naleznete rámec SEEK, použijte hodnoty v něm uvedené k následnému vyhledávání.
Pokuste se vyhledat patičku tagu, prohledávejte přitom soubor od konce.

Snad ještě krátký dodatek - najdete-li nový tag, měl by být ihned vymazán případný starý tag. Jedinou výjimkou je situace, kdy je nastaven update flag v rozšířené hlavičce tagu.

Mechanismus "unsynchronization"

Tolik k první části dnešního článku - k popisu toho, kde by měl být tag v souboru umístěn. Pojďme se podívat na druhou část, a to na popis mechanismu nazvaného "unsynchronization".

Jedná se poměrně užitečnou věc: umožňuje totiž zpětnou kompatibilitu se softwarem, který o technologii ID3v2 vůbec neví. To je vlastně primárním (a jediným) účelem celého mechanismu.

Jak to celé funguje? Nejprve se podívejme na potíž, kterou můžeme při přehrávání hudby mít. Následující popis je trochu zjednodušený.

Představme si třeba velmi starý přehrávač hudebních souborů, který neví nic o tom, že hudební soubory mohou být rozšířeny o textové informace. Takovému přehrávači následně "předhodíme" hudební soubor a požádáme jejo jeho přehrání. Co se stane? Přehrávač vezme soubor a všechny bity, které v něm najde, bude interpretovat jako hudbu, protože nebude mít ani tušení o tom, že by to mohlo být něco jiného. Jinak řečeno, pokusí se přehrát textové nebo jiné binární (avšak zaručeně nehudební) informace. Můžeme si přitom být jistí, že výsledek nebude našemu uchu znít zrovna libozvučně.

Řešením tohoto problému v případě technologie ID3v2 je právě unsynchronizace. Jinak řečeno, unsynchronizace nemá vlastně žádný význam v případě, kdy je jí vybavený soubor přehrávaný přehrávačem majícím ponětí o technologii ID3v2. Ten si prostě celého mechanismu ani nevšimne. Zato jiným přehrávačům (ať už softwarovým nebo hardwarovým), které o technologii neví, zjednoduší život.

Dodejme ještě, že unsynchronization je použitelná pouze s tagy v souborech MPEG 1/2 layer I, II a III, v souborech MPEG 2.5 a v souborech AAC.

Aniž budeme zabíhat do podrobností, uvedeme si, že:

MP3 audiosoubor je identifikován tzv. sync (synchronizačním) signálem (sekvencí) na začátku MP3 rámce.
Unsynchronization je proces, během něhož dojde k modifikaci hlavičky ID3 rámce tak, že starší přehrávače, které neznají technologii ID3, nebudou mylně ID3 považovat za hudební rámec.

V zásadě jde o to, že unsynchronizací se rozumí nahrazení následujících sekvencí bitů:

11111111 111xxxxx

které jsou nalezeny kdekoliv v rámci, sekvencemi

11111111 00000000 111xxxxx

Jinak řečeno, v průběhu procesu unsynchronizace dojde k tomu, že všechna umístění uvedené sekvence jsou rozšířena tak, že za první FF bajt je umístěn nulový bajt (00).

Tento proces má bohužel několik vedlejších efektů, s nimiž je nutné se vypořádat. Jedním z nich je třeba to, že všechny $FF 00 kombinace musí být změněny, takže nebudou zpracovány při procesu dekódování. Jinak řečeno, všechny tyto kombinace jsou nahrazeny sekvencemi $FF 00 00.

Abychom indikovali použití unsynchronizace, musí být nastaven unsynchronization flag v hlavičce rámce. Tento flag musí být nastaven v případě, že rámec prošel unsynchronizací a neměl by být nastaven, pokud neprošel. Pokud jsou unsynchronizovány všechny rámce v tagu, měl by být nastaven unsynchronization flag v samotné hlavičce tagu. Tento tag však nesmí být nastaven v případě, že existuje byť jen jeden jediný rámec, který neprošel unsynchronizací.

Unsynchronization - polopatické shrnutí

Protože se obávám, že předchozí podkapitolka neudělal většině čtenářů příliš jasno, pokusím se ještě jednou shrnout fakta o procesu unsynchronizaci a o jejím významu. Zabrousím přitom do širších souvislostí, abyste si dokázali udělat o celé technologii ucelenější obrázek.

MP3 soubor je vlastně MPEG souborem, jen obsahuje pouze audiodata (žádné video). Jako takový je rozčleněn do rámců. Aby byly snadno identifikovatelné začátky rámců pro zpracovávající software, začíná každý rámec bajtem FF následovaným ještě jedním F (nebo E namísto F v případě MPEG 2.5). Takhle prostě vypadají MP3 data a všechny přehrávače, i ty nejstarší, to ví.

Co ale nejstarší přehrávače neví, je skutečnost, že nově přidáváme do MP3 souborů nehudební data. Otázkou tedy v podstatě je, jak zabránit tomu, aby tato nehudební data obsahovala sekvence FFF nebo FFE, které by starými přehrávači mohly být interpretovány jako hlavička dalšího hudebního rámce. Nic jiného nemusíme řešit, protože dokud přehrávač nenarazí na zmíněnou sekvenci, ani ho nenapadne nalezená data považovat za hudbu.

Technologie ID3 k vyřešení této otázky používá dva mechanismy, přičemž důležitější z nich je právě unsynchronization. Druhým mechanismem je používání tzv. synchsafe integerů, o kterých si stručně povíme za chvíli.

Unsynchronizace tedy znamená provedení takové modifikace souboru, která zkonvertuje všechny potencionálně nebezpečné sekvence bitů (tedy zmíněné 11111111 111xxxxx) na sekvence bezpečné, tedy na sekvence takové, které nebudou žádnému, ani sebehloupějšímu přehrávači, připadat jako začátek hlavičky hudebního rámce. Jinak řečeno, novými sekvencemi budou 11111111 00000000 111xxxxx.

Závěrem dodejme, že ač se unsynchronizace jeví jako užitečná a funkční, některé názory hovoří striktně proti ní, například autor následujícího článku na webu www.id3.org uvádí: "Myslím, že unsynchronizace by měla být prováděna tak zřídka, jak je to jen možné, protože znamená zvětšení velikosti celého souboru a tím také zvyšuje dobu zpracování (čas parsování). Jinými slovy, myslím, že by unsynchronizace měla být dafaultně vypnutá."

Synchsafe integers

Poslední věcí, kterou dnes zmíníme, jsou tzv. synchsafe integery. Jedná se o jakýsi doplněk technologie unsynchronization: používáním synchsafe integerů zajistíme, že celý proces bude plně funkční.

Synchsafe integery jsou takové, které nemohou být nikdy nositelem výše uvedené "nebezpečné" sekvence bitů (která by mohla být přehrávačem mylně pochopena jako začátek hudebního rámce).

Synchsafe integers jsou takové integery, které udržují svůj nejvyšší bit (bit 7) na nule. Jinak řečeno, takový integer obsahuje pouze 7 významných bitů. V případě dvaatřicetibitového integeru umožňuje uložit 28 bitů informací.

Příklad: číslo 255 (tj. 11111111) zakódované jako 16bitový synchsafe integer bude vypadat vlastně jako 383 (tj. 00000001 01111111).

Závěr

To je o teorii ID3v2 vše. V předchozích článcích uzavřených dnešním dílem jsme si popsali vše důležité, co by případné zájemce o MP2 a ID3v2 technologie mohlo zajímat.

V dalším pokračování se konečně pokusíme zaměřit více na praktické využití získaných informací.