|
Podíváme se na to, jaké jsou možnosti využití RDS na moderních
přijímačích a jak stanice tyto možnosti reálně využívají. Můžete tento
článek chápat i jako stručný průvodce nastavením RDS nebo jako soupis minimálních
požadavků na soudobou vysílací techniku.
V první řadě se zamysleme nad rozsahem a formou informací poskytovaných v RDS.
Jsou tyto informace vždy dostatečně úplné na to, aby se posluchač zorientoval v
aktuálním vysílání a v programovém schématu? Jsou plně využity zobrazovací
možnosti dnešních přijímačů? Odpovědi nejsou vždy úplně lichotivé. Velké
části rádií se v minulosti podařilo dostat na displej informaci o právě hrané
skladbě, o aktuálním pořadu nebo jiné měnící se texty. Bohužel od té doby
příliš velký posun nenastal. Nehledě na to, že na třetině FM vysílačů stále
zůstává jen statický text, samozřejmě bez diakritiky. Rádio tak ve srovnání s
moderními prostředky komunikace zbytečně působí dojmem zastaralosti.
Paradoxně webové stránky rádií bývají informačně bohaté. Dozvíme se co
právě hraje, kdo moderuje, jaký pořad běží, co bude následovat, kontakty do
studia, ovšem najdeme zde i přehled událostí nebo přehled akcí pořádaných
rádiem. Takže byl splněn ten nejobtížnější úkol - informace sestavit a
publikovat. Proč tedy významná část těchto informací neběhá i v RDS? Posluchač
sice vše "najde na webu", ale posluchače je třeba přitáhnout zejména k
přijímači. Moderní přijímače s velkým grafickým displejem umějí informace
zobrazit, ale někdo jim je nejprve musí ve vhodné formě poskytnout.
Značkování textových informací pomocí RT+
Funkce pojmenovaná Radiotext Plus (ve zkratce RT+) dnes bude zmíněna mnohokrát,
takže asi není překvapivé, že začneme právě jejím popisem. Pro přenos textů je
v RDS vyhrazena funkce Radiotext. Tím pádem RT+ nepřenáší žádný text, pouze
rozšiřuje možnosti Radiotextu - označuje pozici v Radiotextu, na které se nachází
text určitého typu (třídy). Celkem lze takto označit nejvýše dva úseky Radiotextu.
Abychom to hned přiblížili na něčem konkrétním, tak pokud se v Radiotextu
vysílají informace o právě hrané skladbě, RT+ říká přijímači, která část
textu je jméno interpreta a která část je název skladby. Celkem je definováno 63 tříd, mezi kterými je třeba i název
stanice v plné délce, telefonní číslo do studia, zprávy a události, webové adresy,
reklamní sdělení, informace o vysílaném programu atd.
RT+ není funkce nikterak nová, existuje někdy od roku 2007 a významnější podpora
v přijímačích se objevuje zhruba od roku 2011. S masovým příchodem multifunkčních
zařízení a přijímačů s grafickým displejem se funkce RT+ stala natolik významnou,
že její absenci ve vysílání RDS lze označit za vážný nedostatek. Ke škodě
posluchačů i samotných rozhlasových stanic je funkce RT+ stále přehlížena či
nedostatečně využívána, viz [1]. V České republice v roce 2024 lze RT+ přijímat z
necelých 20 procent FM vysílačů, což je zoufale málo. Přitom někde možná stačí
jen tuto funkci několika kliknutími zapnout! Řekněme si to na rovinu: Stanice, které
dosud nevysílají RT+, se vizuálně stávají stanicemi druhé kategorie.
Stanice vysílající pouze Radiotext.
Stanice vysílající Radiotext Plus.
Proč je funkce RT+ tak důležitá? Pojďme si shrnout některé její výhody:
- Přijímač dostává nejen vlastní text, ale i informaci, k čemu se text váže a co
popisuje
- Stanice je hned na první pohled vizuálně atraktivnější a může být i samotným
přijímačem preferována při hledání stanic
- RT+ umožňuje zobrazení textů i na některých přijímačích, které samotný
Radiotext standardně nezobrazují
- Texty různého typu zůstávají uloženy vedle sebe v paměti přijímače a jsou
zobrazeny i tehdy, když se zrovna nevysílají
- Lze postupně vysílat velké množství různých textů a stále zůstává zachována
přehlednost
- Vizuální soulad s jinými moderními službami elektronické komunikace
- Snazší využití textové informace, např. přímé vyhledání skladby, vytočení
telefonního čísla atd.
- Radiotext je nadále bez problémů čitelný i na přijímačích, které RT+
nepodporují
S použitím soudobých prostředků je implementace RT+ relativně snadnou
záležitostí. V mnoha případech ani není nutné měnit kodéry RDS. V prvním kroku
je ale třeba opustit 20 let starý software... Následně se otevřou úplně nové
obzory co se týče načítání, plánování, zpracování a rotace textů.
"Otagování" všech vysílaných textů může být otázkou chvilky. A když
myslíme texty, tak nejen právě hranou skladbu (item.artist a item.title), ale
i popis vysílaného pořadu (programme.now), upoutávky (programme.next),
telefonní číslo (phone.studio), internetovou adresu (info.url),
události (info.event), a v neposlední řadě i komerční sdělení (info.advertisement),
takže lze drobně přilepšit rádiovému rozpočtu.
Tagy lze do textu vložit ručně (například do textového souboru se slogany
stanice) nebo automaticky několika různými způsoby: na základě shody s některou ze
šablon, pevným přiřazením konkrétnímu zdroji textu nebo přiřazením konkrétnímu
XML/JSON elementu ze zdroje textu.
Příklad ručního vložení:
Volejte bezplatně naši horkou linku <phone.studio>800 123 456</phone.studio>
Příklad šablony:
%PREFIX%<item.artist/> - <item.title/>%SUFFIX%
Ovládací software RDS kodéru následně provede zakódování informace RT+ do
formátu, který je kodérem podporován. Případné elementy v závorkách <...> z
textu odstraní, takže ve finálním Radiotextu již obsaženy nebudou a data RT+
přijímač dostane souběžně s Radiotextem pomocí datových skupin ODA.
V jednom okamžiku lze vysílat vždy pouze jeden Radiotext, takže pro různé texty
se použije smyčka a texty se přepínají pokud možno v pevném časovém rytmu, třeba po 30 sekundách. Lze zajít ještě
dál a vytvořit hlavní smyčku obsahující i podružné smyčky. Může se tak
střídat třeba informace o hrané skladbě vždy s jedním ze sloganů stanice, a dále
dle fantazie provozovatele. Při použití RT+ texty z přijímače nemizí (resp. neměly
by mizet), přijímač si ke každému typu (třídě) pamatuje poslední přijatý text.
Dlouhý název programu (Long PS)
Funkce Long PS umožňuje vysílat název stanice v kódování UTF-8 v délce až 32
bajtů. Znamená to, že konečně padá staré omezení názvu stanice na maximální
délku 8 znaků. Též lze vysílat teoreticky libovolné znaky z tabulky Unicode,
včetně různých symbolů, ikonek i jiných podivností, které známe z internetu z
předmětu emailových zpráv a z příspěvků na asociálních sítích.
Funkce je relativně nová, objevila se ve specifikaci označované jako
"RDS2". Avšak přenáší se v rámci "starého" RDS, ve skupinách
typu 15A. Díky tomu je relativně snadné ji implementovat. Údajně až čtvrtina nyní
vyráběných přijímačů by měla funkci Long PS podporovat (tento údaj raději berte
s rezervou). Namátkově jsou to: autorádio Pioneer ve vozidle Subaru WRX, přenosné
přijímače Sangean DPR76DAB, Pure Elan a Sony XDR-P1DBP, nebo radiobudík JBL Horizon 2.
Funkce není náhražkou, nýbrž výhradně doplňkem tradičního 8znakového PS.
Její využití je vhodné pro stanice, které mají v názvu znaky s háčky a čárkami
nebo jejichž název je delší než 8 znaků. V ostatních případech je funkce Long PS
zbytečná.
Bohužel tvůrci RDS norem udělali tu chybu, že spolu s funkcí Long PS zahrnuli do
skupiny 15A povinně i funkci TA. Asi nemá smysl na tomto místě zabíhat do detailů,
zkrátka následkem toho není možné vysílat Long PS přes RDS kodéry bez přímé
podpory této funkce, pokud stanice zároveň využívá funkci TA. Skupiny 15A by se
totiž daly zakódovat externě, ale pak nelze zaručit shodu hodnoty TA s hodnotou
ovládanou přímo kodérem.
Dynamické PS
Kdysi dávno, když přijímače uměly zobrazit jen 8znakový název stanice (PS), se
pro zobrazení delších textů zavedla taková praxe, že se text rozdělil na úseky,
které se postupně odvysílaly na displej rádia. Tak se zrodilo dynamické PS. Věc,
která vznikla z důvodů nouze a kterou se dodnes nedaří zcela vyloučit, ačkoli již
neexistuje žádný důvod pro její existenci.
Některé stanice, zejména v zahraničí, razily dlouhé roky trend, že čím
větší guláš v PS, tím lépe. Najelo to až do absurdních rozměrů, kdy některé
stanice požadovaly, aby se klasický název stanice neukazoval vůbec a aby tam pořád
"něco běhalo", rolovalo tu po jednom znaku, tu zase po slovech, a nejlépe
ještě proložené hvězdičkami. Tohle už je naštěstí pryč. Především je třeba
pochopit, že PS je součást značky rádia, podobně jako logo nebo znělky. Podle toho
je třeba s ním zacházet.
Pokud si na přijímači aktivujete funkci automatického vyhledání stanic, pak ve
výsledném seznamu kromě běžných názvů narazíte třeba na toto:
"VYTRCIIO", nebo na tohle: "R-izMo a". Ano, to jsou stanice, které
vysílají dynamické PS. Pozná v nich posluchač své oblíbené rádio? Dynamické PS
totiž funguje pouze při bezvadném příjmu a pouze za předpokladu, že na příjem
stanice je vyhrazen dostatečný čas, což při prohledávání celého pásma opravdu
není splněno. K tomu stále přibývá přijímačů, které dynamické PS filtrují a
při poslechu jej vůbec nezobrazují.
Dalším problémem je nekonzistence zobrazení napříč různými stanicemi. Mnoho
současných přijímačů zobrazuje PS a Radiotext na dvou různých řádcích.
Posluchač obvykle neví, co je to PS a co je Radiotext. Diví se, proč u některých
stanic se texty zobrazují "tam nahoře" a u jiných stanic "pod názvem
stanice". Nemluvě o faktu, že občas v tom nemají úplně jasno ani lidé přímo
z rádia :) Někdy je to ze strany provozovatele vysílání přímo i záměr -
poskytovat naráz dva typy informací, jeden v Radiotextu a jiný v dynamickém PS. Je to
zbytečné, neboť toto již dávno řeší RT+.
Abychom to shrnuli, PS by mělo být absolutně neměnné. Celý název rádia, pokud se
nevejde do 8 znaků, nebo informaci, která má odrážet aktuální náplň vysílání,
lze vysílat pomocí služeb k tomu určených: Long PS, resp. RT+.
Znaky s diakritikou
Je to opravdu kruté a k nevíře, ale i v roce 2024 jsou veškeré texty v RDS po
celém světě podřízeny jedné jediné 8bitové znakové sadě staré možná 50 let.
Výjimkou je pouze již zmíněná funkce Long PS, která je založena na kódování
UTF-8. Rozšíření kódování UTF-8 i na ostatní textové služby je bohužel stále v
říši snů, a tam to možná zůstane navždy. Následující tabulka tedy ukazuje
veškeré znaky, které máme v RDS k dispozici. Nic víc z toho nedostaneme. Naštěstí
čeština je zahrnuta relativně dobře.
Nejvíce asi zamrzí absence znaku "ů", takže se vždy kóduje jako
"u" a tedy se zobrazuje bez kroužku. Podobně ť nebo ď. Mezi velkými
písmeny dále chybí Ě a Ň. Obecně není doporučeno psát texty pouze velkými
písmeny, a ani RDS samozřejmě není výjimkou. Takový text je méně přehledný, a
třeba v internetových diskuzích je psaní velkými písmeny považováno za projev
neslušnosti. U názvů skladeb lze doporučit konverzi na tzv. title case, kdy jsou
všechna počáteční písmena velká a zbytek slova je psán malými písmeny. Kromě
toho, že to celkem dobře vypadá, se tím i schovají některé chyby v pojmenování
skladeb.
Problematice zobrazení znaků s háčky a čárkami jsme se věnovali v samostatném článku již před 10 lety. Test
přijímačů, který jsme předtím provedli, dopadl neslavně. Jenže všechny
testované přijímače byly z dnešního pohledu staré vykopávky a nemá vůbec
žádný smysl je donekonečna brát v úvahu. Jestliže tehdy padlo doporučení vysílat
texty s háčky a čárkami na určitých typech stanic, tak dnes jednoznačně platí:
vysílat vždy! Číst na moderních zařízeních texty bez diakritiky je takřka
nedůstojné, a hlavně je to naprosto zbytečný handicap.
Zdrojové texty bývají obvykle v kódování UTF-8, v horším případě v CP-1250 (8bitová středoevropská znaková sada ve
Windows). Jiné zastaralé znakové sady už se snad vůbec
nepoužívají. Musí být zajištěna konverze do znakové sady RDS, buď v ovládacím
softwaru nebo v samotném RDS kodéru. Problém může být pouze se zastaralým softwarem
nebo kodérem, nebo v případě, kdy konverze probíhá ještě přes nějakou třetí
znakovou sadu. Ale to vše už patří minulosti a náhrada řešením na úrovni doby
nepředstavuje žádnou významnou překážku.
Výjimku lze učinit jen u názvu programu (PS) a vysílat jej tedy nadále bez
diakritiky, jelikož je to součást značky a případné "zprznění"
špatným zobrazením na starém přijímači nemusí být přípustné. Navíc lze pro
moderní přijímače paralelně vysílat plnohodnotný název stanice v podobě Long PS
nebo v RT+ pod tagem stationname.
Napojení na odbavovací systém
Aby bylo možné odesílat textová data o právě hrané skladbě, případně další
informace vázané na programovou náplň stanice, je nutné odbavovací systém propojit
s kodéry RDS. Ačkoli v mnoha případech existuje možnost zasílat data z odbavovacího
systému přímo do kodéru RDS, obecně je takové řešení nutné považovat za
nouzové a nevyhovující, viz [2]. Preferovaný způsob řešení využívá
specializovaný ovládací software pro RDS kodéry jakožto prostředníka
("middleware") mezi odbavovacím systémem a kodéry RDS:
Společným rysem prakticky všech odbavovacích systémů je velmi slabá podpora pro
RDS. Většinou lze odesílat Radiotext s právě hranou skladbou na zvolený sériový
port nebo TCP spojení. Počet podporovaných kodérů bývá omezen a jakékoli
pokročilejší funkce obvykle zcela chybí. My typicky požadujeme další funkce a
možnosti:
- Automatickou úpravu textů a filtrování podle zadaných klíčových slov
- Zařazení textových informací z různých zdrojů, jako jsou upoutávky na pořady,
slogany, zprávy a další sdělení
- Otagování všech informací pomocí RT+
- Ovládání dalších RDS služeb (PTY, TA, PI) dle denního plánu nebo výskytu
klíčových slov
- Jeden společný přístupový bod pro celou síť vysílačů a kodérů RDS
- Společný provoz RDS kodérů různých výrobců a typů
- Monitoring stavu sítě, atd.
Z těchto i dalších důvodů dává smysl vedle odbavovacího systému pro audio
obsah provozovat i "odbavovací software" pro obsah RDS. Ve hře je i
ekonomické hledisko - při použití centrálního softwaru pro obsluhu RDS kodérů lze
tato zařízení realizovat jednodušším způsobem, například co se týče počtu
komunikačních portů nebo individuální podpory síťových služeb.
Radiotext i RT+ v jednom příkazu
Pro případ, že odbavovací systém posílá texty do RDS kodéru přímo (bez
dalšího softwaru v roli "prostředníka"), byla vyvinuta nadstavba ASCII
komunikačního protokolu s názvem X-Command, založená na zjednodušené struktuře XML
jazyka. Jedním z hlavních cílů bylo umožnit vysílání RT+ aniž by jej původní
aplikace musela podporovat. Nahrazuje také zastaralé příkazy pro vložení informace
RT+, kterou bylo nutné předem zakódovat a zasílat separátně.
Veškeré nezbytné zpracování, optimalizaci a zakódování RT+ nyní zajistí
přímo RDS kodér, stejně tak konverzi z kódování UTF-8. Jako příklad si můžeme
uvést následující jednořádkový příkaz, na základě kterého RDS kodér
odvysílá nový Radiotext včetně RT+ tagů pro jméno interpreta a název skladby:
XCMD=<rds><item><dest>3</dest><text><artist>Morčata Na Útěku</artist> - <title>Šalina</title></text></item></rds>
Jak je ze struktury příkazu patrné, k jeho implementaci postačí nadefinovat
šablonu pro textový výstup, například:
XCMD=<rds><item><dest>3</dest><text><artist>%artist</artist> - <title>%title</title></text></item></rds>
Přesný formát šablony závisí na konkrétním odbavovacím softwaru. Příkaz je v
každém případě zakončen znakem CR (Carriage Return, 0x0D) jako jakýkoli jiný ASCII
příkaz. No řekněte sami - jednodušeji už to snad ani nejde.
Prodleva zobrazení Radiotextu
Aby textové informace v RDS dávaly posluchači smysl, neměly by se příliš časové míjet s
vlastním audio obsahem. Určitým krátkým časovým překryvům samozřejmě nejde zabránit, zejména v případě vysílání většího
množství textů. Například nelze posluchači už po pár sekundách "useknout" právě vysílané
textové sdělení jen proto, že zrovna začala hrát nová skladba.
Než se textová informace zobrazí posluchači na displeji, musí projít několika
fázemi, z nichž každá přidává určité zpoždění. Tento problém nebývá významný akorát v
případě internetové distribuce zvukového obsahu, neboť pak se zpožďuje nejen text, ale i zvuk :)
Software musí zjistit
existenci nového textu, tento odeslat do kodéru RDS, kodér musí informaci zpracovat a
následně odesílat do přijímače. Ač se může zdát, že vyslat krátký text do
přijímačů je dílem okamžiku, skutečnost je taková, že právě zde vzniká
největší část zpoždění. Je tomu z důvodu relativně nízké přenosové rychlosti
systému RDS, která je dále podstatným způsobem degradována kvůli potřebě vyhradit
část kapacity i pro jiné služby než je Radiotext.
Typická prodleva zobrazení nového textu na displejích přijímačů je proto kolem
5 sekund. To platí za předpokladu bezvadného příjmu a při absenci datově
náročných služeb jako je třeba EON nebo TMC - pak je třeba počítat spíše s
dvojnásobkem i trojnásobkem tohoto času. Dobrá zpráva je, že existuje způsob, jak
celkovou prodlevu zkrátit zhruba o třetinu.
Metoda je založena na dynamickém sledu RDS skupin (Dynamic Group Sequence) a
vyžaduje podporu v RDS kodéru. Pomocí této metody je dočasně vyhrazena vyšší
přenosová kapacita pro Radiotext bezprostředně po jeho změně. V případě
Radiotextu se jedná o skupiny typu 2A. Nový text se tedy zobrazí na přijímačích
rychleji, následně již stačí jej vysílat s obvyklou četností skupin 2A.
Identifikace země
Pro odlišení země, odkud stanice vysílá, se běžně používá první číslice
PI. Česká republika má přidělenu číslici 2. Protože jedna číslice neumožňuje
rozlišit všechny státy světa, každou konkrétní číslici sdílí několik zemí.
Číslici 2 používá i Alžírsko, Kypr, Irsko a další země.
Může se zdát, že to ničemu nevadí. Není to tak úplně pravda. Dnešní
přijímače, zejména autorádia, obsahují rozsáhlou databázi informací i grafiky ke
spoustě rozhlasových stanic. Aby se tato databáze dala správně použít, musí být
identifikace státu jednoznačná a nezávislá na nastavení přijímače. K tomu se
používá RDS funkce ECC (Extended Country Code). Jde o jednobajtovou informaci a pro
Českou republiku je přidělena hodnota E2.
V případě, že RDS kodér nepodporuje funkci ECC přímo, lze ji zakódovat ručně
a posílat jako uživatelsky definovanou skupinu typu 1A: 0x00E2 0x0000, příp. jako 1000
00E2 0000. Četnost vysílání postačí jednou za pět sekund.
Závěrem
Nejsme u konce. Spíše na začátku. Je společným zájmem všech stanic ujistit
posluchače, že rozhlasový přijímač může být stále vnímán jako moderní
prostředek. K tomu je ale nezbytné, kromě reprodukce zvuku, vzít do úvahy i
vizuální dojem při jeho používání. Snad k tomu trochu pomohou i informace
předložené v tomto článku.
Stanice, které se rozhodnou jít v tomto ohledu posluchači vstříc, si v první
řadě musí vytvořit přehled o tom, jakým způsobem vše dosud funguje. Kolik je v
síti RDS kodérů a jakých značek? Po jakých linkách se do nich posílají data? Je
na vysílačích k dispozici internetové připojení? Jaký software je používán? Kam
odbavovací systém ukládá texty? Atd. Na základě podrobné znalosti současného
stavu lze poté diskutovat nad náměty ke zlepšení a hledat nejschůdnější
řešení.
Použité prameny:
[1] Radio World. Broadcasters Need to Do Better With Visual Displays [online],
2024. Dostupné z <https://www.radioworld.com/news-and-business/news-makers/broadcasters-need-to-do-better-with-visual-displays>
nebo v
archivu.
[2] NAB Digital Dashboard. Best Practices Report [online], 2023. Dostupné z
<https://nab.org/innovation/NAB_DigitalDash_RecommendedBestPractices_1023.pdf>
nebo v archivu.
[3] KOLÁŘ, J. X-Command for RDS Encoders [online], 2024. Dostupné z <https://pira.cz/rds/xcmd.pdf>
[4] KOLÁŘ, J. Stručně o systému RDS [online], 2012. Dostupné z <https://pira.cz/RDS.pdf>
|
