Radiotext "+" per l'RDS di RTL: informazioni dinamiche "compliant"

Gli amici di RTL102.5 mi comunicano di aver attivato il servizio RDS RT+ che ora trasmette informazioni dinamiche come il titolo del brano musicale trasmesso al momento. La foto che vedete mi è stata gentilmente fornita da Marco Cavestro ed è stata ripresa dal display di Pure Sensia:

A parte ho realizzato un breve filmato sulla mia piccola Pure ONEmini, FM/DAB:

In questo modo, RTL può trasmettere una serie di dati e metadati per implementare servizi come l'invio di informazioni sul brano in onda (Titolo, Autore), indirizzo email, sito web, numero SMS, (tramite il RT, ricevibile dalla maggior parte dei ricevitori). E' anche possibile inviare i TAG che consentono di aquistare il brano, inviare SMS, visitare il sito della radio, inviare email, tramite il RT+ (ricevibile con appositi ricevitori, Ipod nano, Ipod Touch, telefoni Nokia nuova serie, telefoni Samsung Galaxy, etc). E last but not least l'uso dell'RT+ consente di rispettare la norma IEC 62106, relativa all'utilizzo improprio del campo RDS "PS" che deve rimanere fisso e visualizzare solo gli 8 caratteri che identificano la stazione. In Italia molto spesso questa direttiva viene ignorata e può dar luogo a effetti collaterali spiacevoli quando si è alla guida e si viene distratti da un display che si modifica continuamente.

Il discorso delle informazioni dinamiche e dei metadati si può trasferire ovviamente anche sul DAB, per cui è previsto il servizio Dynamic Label Plus (DL+). E' una modalità ancora più estesa perché consente all'ascoltatore di scegliere quali informazioni dinamiche visualizzare in base a una serie di TAG definite dall'emittente. Il DL+ deve però essere supportato a livello di software operativo dei chipset che rielaborano le informazioni del DAB.

Ibiquity (re)inventa l'RDS per le stazioni AM

La National Association of Broadcasters americana ha contribuito a finanziare una ricerca di Ibiquity, l'inventore del sistema di radio digitale HD Radio, con l'obiettivo di escogitare una tecnica di trasmissione dati da associare alla portante di un segnale radio modulato in ampiezza. Questa forma di RDS per le onde medie potrebbe essere utilizzata dalle stazioni locali in onde medie per offrire ai loro ascoltatori analoghi servizi informativi, dal nome della stazione al titolo dei brani trasmessi. Il sistema, AM Digital Data Service (ADDS) si basa sull'impiego di un ristretto numero di sottoportanti modulate come nelle trasmissioni HD Radio, ma a differenza di quest'ultimo la banda occupata è molto limitata e consente di trasmettere i dati a un rate compreso tra i 90 e i 1.000 bit al secondo (contro gli 1,2 kilobit di RDS).

E' davvero possibile che una tecnologia del genere possa essere utilizzata per estendere le capacità delle trasmissioni in AM? Potrebbe essere accettata su vasta scala? Nutro parecchi dubbi al proposito, ma il mio punto di vista è molto europeo e diversamente dagli Stati Uniti, dove esistono ancora migliaia di stazioni in onde medie che potrebbero trovare interesse nello sperimentare nuove opportunità di svecchiamento del medium, qui in Europa le onde medie sono apertamente in via di progressiva estinzione. Sono in pochi - a parte forse i lettori di questo blog - a conoscere l'esistenza di una tecnica ETSI molto simile concettualmente all'ADDS proposto oggi da Ibiquity. Si chiama AM Signalling System e funziona in base a un meccanismo di modulazione in fase della portante di un segnale AM. AMSS, sviluppato cinque anni fa, supporta una velocità di trasferimento dati di circa 48 bit al secondo. A parte qualche trasmissione sperimentale della BBC, decodificabile con il software per DRM DReAM, non c'è stato alcun seguito alla cosa.

Lo studio americano proseguirà, avvertono quelli del NAB, solo se ci sarà una adesione da parte del mercato. In teoria, sviluppare i componenti e il software per decodificare le informazioni ADDS non dovrebbe essere complicato e neppure aggiungere questa funzione agli attuali ricevitori analogici. Da a qui ad aver voglia di farlo, ci passa. Ma tutto questo è interessante perché dimostra che se si vuole integrare un contenuto audio distribuito con tecniche analogiche, è possibile pensare di accompagnare tali flussi con metadati che aprono la strade a servizi e forme di integrazione di tipo digitale. L'obsolescenza della radio analogica soprattutto nelle onde medie è ovviamente legata al comportamento degli ascoltatori, dei consumatori. Ma tale comportamento è inevitabilmente condizionato dalle tecnologie, dai quadri normativi, dalle scelte industriali, dalle iniziative degli editori. Che succederebbe, ipotizziamo, se le onde medie fossero destinate, chessò, alla copertura di eventi sportivi di forte interesse locale, come le partite di calcio, con l'audio del commento e dell'interno dello stadio radiodiffuso e le informazioni di corredo visibili via Internet? O per applicazioni a carattere turistico, come le audioguide? Forse non tutte le idee sarebbero commercializzabili, ma perché negarsi l'opportunità di esplorarle? In ogni caso, potete leggere il documento tecnico relativo al sistema AM Digital Data Service scaricando questo pdf.

iBiquity Develops New AM Radio Data Service Concept

NAB FASTROAD (www.nabfastroad.org) last week announced the release of a report on a new AM radio data service concept, with the potential to provide AM broadcasters the ability to transmit low-rate data similar to what analog FM broadcasters can provide using the Radio Data System (RDS) subcarrier. This work was undertaken by iBiquity Digital Corporation (Columbia, Md, www.iBiquity.com), developers of the HD Radio IBOC system used by U.S. broadcasters to transition to digital radio, and was co-funded by iBiquity and NAB FASTROAD.

Called the AM Digital Data Service (ADDS), this new technology would utilize a small number of IBOC digital subcarriers (either two, four or six) to provide a data capability (but no digital audio) similar to RDS for analog FM. Because analog AM radio stations have no method for transmitting data such as song title and artist, there is a need for an AM data transmission service that provides capabilities similar to FM RDS and can support delivery of low data-rate text. This technology could be easily and affordably integrated into future versions of IBOC receivers but existing IBOC receivers (and analog-only receivers) would not be able to decode the ADDS signal.

As described in the report, from one to three digital subcarrier pairs would be used to transmit digital data, as shown in the figure. These subcarriers would reside “underneath” the existing analog AM audio signal, which is represented in the figure by the trapezoidal shape which extends symmetrically about the channel center out to approximately ±10 kHz.

Each subcarrier’s power level is set to ensure robust reception of the digital data, while minimizing interference to the host analog audio. The levels shown in the figure are based upon an analytical study which is summarized in the report, and would, in a future phase of the program (not currently planned), be verified in laboratory and field testing of the system. The ADDS system borrows heavily from the digital broadcast design defined for HD Radio AM Hybrid transmission. The design establishes symbol durations, subcarrier spacing, and sample rates consistent with HD Radio broadcasts. These design requirements ensure robust reception and allow for compatibility with existing HD Radio receiver applications.

Depending upon the number of subcarriers and the type of modulation, data rates from approximately 90 to 1000 bits per second would be supported by ADDS. By comparison, the RDS signal has a bit rate of approximately 1,200 bits per second. ADDS is designed to support text messaging and data transmission associated with audio program content. Proposed “use cases” include station service messages, alert messages, and program service messages. These system definitions are identical to the corresponding definitions in the HD Radio system standard; additional information on two of these use cases is provided here:

Station Message Service (SMS) – the station message service is intended to identify station-related configuration and important messages to the listener. The station message service provides, but is not limited to, the following: station call letters, station message (examples include public service announcements, weather reports or telephone call-in numbers). This service borrows definitions from the HD Radio Station Information Service (SIS);

Program Service Data (PSD) – the program service data is intended to describe the content of the current audio program. The PSD service provides, but is not limited to, the following messages: title, artist, album, genre, content, commercial. This service borrows definitions from the HD Radio Program Service Data (PSD).

One of the benefits of ADDS is that it would offer AM broadcasters a simpler and less-expensive way to provide a (limited) digital service compared to a full AM IBOC installation which at present is the only option. Also, the requirements on the antenna system for ADDS would be the same as for analog AM and not the more stringent requirements of AM IBOC. This is important because antenna tuning (usually necessary when upgrading existing AM broadcast facilities from analog AM to HD Radio specifications) has been one of the major tasks needed to get AM IBOC stations functioning and on-the-air.

The full text of the ADDS report and information on the NAB FASTROAD technology advocacy program are available at www.nabfastroad.org. Future work on this project will depend upon a number of factors including whether the broadcasting and receiver manufacturing industries embrace this concept.

EPG story parte I: Google ci riprova con Dish Network

Secondo il Wall Street Journal Google sta cercando un'altra volta di "domare" un old medium come la televisione. Lo sta facendo collaborando con Dish Network, terzo operatore tv satellitare negli USA, uno spin-off di Echostar. Se n'era sentito parlare tempo fa, quando il suo boss Charlie Ergen, una figura carismatica nell'industria mediatica americana, si era offerto di cavare le castagne dal fuoco di Mel Karmazin, Sirius Xm Satellite Radio, finendo poi per essere battuto sul filo di lana da un altro tycoon John Malone di Liberty Media, controllante dell'operatore DirecTv. Secondo il quotidiano, subito ripreso dalla stampa e dal Web, il servizio funzionerebbe attraverso un set-top box collegato a Internet, che permetterebbe agli abbonati di Dish Network di svolgere ricerche nella guida programmi dell'operatore e in portali video su Web come YouTube (controllata dalla stessa Google). La storia viene raccontata in modo molto sintetico dal blog di All tech considered, di National Public Radio.
Non molto tempo fa Google aveva dovuto ritirarsi da uno dei suoi pochi fallimenti. Aveva cercato di integrare sia il sistema televisivo, sia quello radiofonico, nel suo schema di vendita pubblicitaria, con un meccanismo decisamente furbo: esaminare il contesto di programmazione radiotelevisiva e piazzarvi in tempo reale gli annunci dei suoi clienti inserzionisti. Non c'è stato niente da fare, il famoso contesto della programmazione radiotelevisiva è troppo vago, troppo indefinito, difficile da classificare con gli strumenti semantici e statistici della ricerca su Web. Persino le rigide gabbie dei palinsesti non sono abbastanza rigide per un obiettivo del genere. I tempi sforano, gli eventi incalzano, i contenuti programmati dalle emittenti saltano, vengono rimpiazzati. Troppe variabili, troppa incertezza. Qualunque cosa abbia in mente adesso il "ragno" di MountainView, presto sapremo se si tratta di una strada più percorribile.

RDS RT+, metadati per la radio (e iPod Nano)

Una interessantissima recensione di Alan Jurison su RadioWorld svela molti particolari tecnici della funzionalità di tagging integrata dal nuovo Apple iPod Nano nel suo ricevitore FM/RDS. Per implementare la funzione - che permette di marcare i brani ricevuti via radio e successivamente collegarsi all'iTunes Store per eventualmente acquistare questi brani - Apple ha utilizzato una parte dello standard RDS introdotta già da qualche anno, il Radiotext Plus o RT+.
E' veramente incredibile pensare a quante cose sono possibili già oggi con la radio analogica e una manciata di metadati. Cose che chissà perché nessuno si immagina di utilizzare. Le specifiche RT+ hanno introdotto, grazie ai campi delle Open Data Application previste dalla normativa che regola questa codifica, un discreto grado di informazione all'utente e interattività. Sto parlando in questi giorni del nuovo sistema RadioDNS, proposto per ovviare ai "limiti" dei metadati trasmessi con i segnali della radio analogica e digitale. RadioDNS è stato definito alla fine del 2009 ma già nel 2006 la rivista tecnica dell'EBU di Ginevra pubblicava un breve ma dettagliato articolo che spiegava che cosa era possibile fare con RT+ (l'articolo si può prelevare qui). Il sistema, sviluppato guarda caso da Westdeutscher Rundfunk (WDR), Nokia e Institut für Rundfunktechnik (IRT), consente di inserire nel flusso informativo RDS dati relativi al TMC, al tagging, alle emergenze e può consentire un certo grado di interattività con l'inserimento di informazioni come numeri di telefono e URL. Tra le aziende che producono encoder RDS che offrono questa opportunità c'è per esempio l'americana Audemat con il modello FMB80. Lato ricevitore, è semplicemente questione di programmare la decodifica a valle dei componenti che già oggi demodulano la sottoportante RDS (o RDBS negli USA, che con l'avvento di ricevitori come iPod Nano e lo stesso Microsoft Zune HD, che supporta RT+ nella parte analogica, sta scoprendo un sistema finora diffuso principalmente in Europa), una semplice questione di software. Eppure siamo qui a lamentarci per una radio che non riesce a stare al passo di Internet. Ma chi l'ha detto?
L'articolo di Jurison è chiaramente rivolto ai tecnici delle stazioni radio interessate a sfruttare la funzione di tagging dell'iPod Nano. L'autore osserva giustamente che maggiore è il numero di stazioni impegnate a diffondere questi metadati, maggiore sarà l'interesse da parte dei costruttori di ricevitori, nell'eterno gioco uovo-gallina che caratterizza l'industria. Certo che appare francamente stupido il clima di attesa che inevitabilmente trasforma ogni nuovo standard tecnico in una possibile "rivoluzione", quando i primi a non accorgersi delle rivoluzioni possibili con gli standard precedenti sono proprio i tecnici.

(...)
FM radio review

If you have used the classic iPod user interface, you’ll be right at home. For those new to the iPod, the wheel user interface may take a little time to get used to. Apple also does a great job with its music playing, display, interface and organization on this device. Seeing album art when playing a stored song is a cool and slick feature, and the buttons and controls within the Music, Video and Photos section are intuitive.
The radio, though, is why I ran out and bought one. (Note that we’re talking about only analog FM here; there’s no HD Radio and no AM capability.) The FM tuner works internationally. When you launch the radio for the first time, it asks what region you’re in (Americas, Europe, Japan, etc.). You can then select “Play Radio” and you’re ready to scan the dial. You can use the outer “wheel” or circle of the control pad to scan the virtual radio dial at the bottom of the screen. Clockwise moves the frequency up in the FM band, counterclockwise moves down.
Once you’ve tuned to a station, or after a period of inactivity, the virtual radio dial display goes away and the functionality of the outer wheel changes to become your volume control. Again, for the non-Apple person, this can take time to get used to. At first, I found myself inadvertently changing the volume when wanting to change the station.
If the virtual radio dial has disappeared and you want to change the station, lightly tap the center button; the dial will return. If you’ve come across a station you like, hold the center dial position for about a second and you can select “Add to Favorites.” Once you’ve added several stations to favorites, use the left/right “Last Track/Next Track” buttons to navigate to your presets. This will navigate the stations in order by frequency, from the bottom of the band to the top. There’s no way to have your own preferred sort order, or to position your most favorite stations first, which could be an improvement.
The sensitivity of the receiver is excellent; even with the supplied earbuds, the radio works as well as you’d expect any portable. I’ve used it indoors in many occasions, especially in larger business structures, and it performs well. The Nano seems to do a great job at decoding RDS even on stations that have a low RDS injection rate.

Radio Live Pause

By default, the radio “Live Pause” feature is turned off; as far as the user interface is concerned that’s probably a good thing because when you turn it on, it does make navigating the iPod a little more difficult. That’s because the center tap and next track/previous track/volume buttons now serve three purposes: to turn up the volume, change the station and fast forward/rewind the recorded audio from the station.
This gets a little tricky and at times annoying, so it has been my preference to turn off the Live Pause function unless I want to use it. I would suggest that Apple add another physical button or two in future models to reduce the many functions of the center button. Perhaps moving the volume controls to dedicated buttons like on the iPhone and Touch models would be the best way to handle this.
The radio “Live Pause” feature is neat. Once you turn it on, it continuously records the station to which you are tuned. It even caches the RDS messages the station sent in real time with the audio and displays a little marker of the time of the event; e.g., if you go back at noon through five minutes of recordings, it shows 11:55 a.m. as the time of recording.
You can use the left/right “Last Track/Next Track” buttons to jump one minute behind or ahead, or you can use the wheel “circular” control for precise fast forward/rewinding. Keep in mind that you cannot store the recordings. This feature is just a way to pause 15 minutes of live radio; the content is lost as soon as you tune away from the station.
While this is an interesting feature, I’m not sure of the usefulness for consumers other than to pause something they are enjoying if they are interrupted and need to attend to something else, or to “rewind” something they just heard that they wanted to hear again.
For some, however, this will be a noteworthy addition. It means that if you are listening to a station and you have “Live Pause” activated, you can go back at any time to re-hear the last 15 minutes of radio content. This “radio rewind” lets you go back for a phone number, or the name of a song that the DJ gave at the top of the song but not at the end; or to listen to what a fast-talking traffic reporter just said about the backup on I-81. A user can now catch anything that normally goes by too fast on the radio.

RDS support

When you tune to an FM station that has RDS, the Nano immediately resolves the short, eight-character PS field. If the station also transmits the longer RadioText (RT), or the 64-character field, it will replace the short PS with the full RT. The Nano does a great job displaying your RadioText, and will scroll it if it’s too long for the display. It’s important for stations that have RDS to make sure their PS and RT are correct. I know of stations that have focused on the short eight-character PS because many car receivers only support that field or only display that field automatically. More radios are supporting RT and more radios are now displaying it prominently, so make sure your station’s PS and RT have the station name, song information and other information you want conveyed in the RadioText. If your station doesn’t do RadioText right, your listeners will miss out on what you want them to see.
The Nano also supports RT+, which is the internationally recognized RDS standard to allow you to denote where the Artist and Title reside in the long 64-character RadioText field. With stations that support RT+, this gives a listener with the Nano an “MP3 Player Feel” while listening to your station.
As soon as the Nano decodes the RT, and if the station has RT+ tagging packets, it will copy the Artist and Title out of your RadioText and display the Artist and Title in a separate section of the screen. Kudos to Apple for keeping the original RadioText on the screen, as this allows people to see other promotional messages and station branding still while tuned into the station. It’s quite a handsome display.
If the station you’re tuned to has RT+ encoding, you’ll also note that, next to the title, is a paper clip icon; this denotes that you can “tag” the song. Hold the center button of the Nano when you see this for about two seconds, and a menu will pop up that allows you to “tag” the song for later purchase. This is a great way to enable listeners who like the song you’re playing to purchase it later when they connect their Apple Nano to their computer with iTunes. Here in Syracuse, Citadel (my employer) and Clear Channel stations are encoding; other stations are not.
In future versions, Apple should explore integrating Wi-Fi (802.11) connectivity so you wouldn’t need to hook it to a computer to purchase a song.
The Nano supports Apple’s proprietary iTunes Tagging RDS protocol as well, which allows encoding stations to send the specific Apple ID of a song to allow the listener who tags a song to download the exact version of the song you played. This is particularly helpful for songs that might have various different versions, which will provide a better user experience.
It also allows you to transmit a unique identifier so your station can get credit for a song purchased through iTunes and allows the station to get a commission from Apple if you participate. Luckily, Apple does not require this in order for the Nano to do tagging, so stations that just encode with the international RT+ standard don’t appear to be much different than those who use Apple’s proprietary iTunes Tagging protocol. The next time you attach the Nano to your computer and it synchronizes, any tagged songs show up in iTunes for download. You can click on the tag and look at the song, preview it again, and look at the album art and other songs on the album. If you already have your iTunes associated with an account, you can buy the song with one click.
While some critics have questioned the usefulness of this feature, I think this is an important way to stay relevant with our listeners. Now, when they hear songs our stations play, they can tag them for later purchase. The “killer app” will be when Apple develops a device using this technology that has a Wi-Fi or 3G/4G connection, which is probably not far from happening. Once the music player is connected to the Internet directly, the listener would be able to tag and download that song to their personal connection immediately.

RDS issues

On the whole, Apple did a great job for its first attempt at an FM receiver with RDS support. I did discover a few issues related to the RDS RT+ support. I found that the Nano initially had a problem in its software and would not decode RT+ packets that are placed in a station’s Open Data Application (ODA) groups of 8A or 9A. There was also an issue where the Nano was using the RadioText (group 2A) “Text A/B Flag” as defined in section 3.1.5.3 in the U.S. RBDS Standard as part of the decision process of whether to display a tag instead of solely relying on the Item Toggle Bit as defined in the RT+ ODA Standard, Annex P.
Upon finding these issues, I got in contact with Apple’s engineers and presented my findings. They were very interested and immediately started working on a solution. Apple quickly released the Nano 1.0.2 revision of software on Nov. 9 that corrected the issues. Your Nano can be upgraded by just connecting it to iTunes; it should suggest that you download the new version of software. My contact at Apple was easy to work with and I am encouraged that the company was able to dedicate resources and respond to this problem in relatively quickly. I think Apple is going to be a great partner; there are exciting possibilities when broadcasters and Apple work together.
While the new software release is out, remember that many Nano units in the field probably haven’t been upgraded. Also, I’m sure most stock at retail outlets will have the original version of software for some time. If your station is airing RT+ tagging, I would review which ODA group you are running it in. Some RT+ hardware installations use 8A as a default, and that means it won’t work on the Nano until the user has upgraded their software version. Since it’s difficult to predict if and when all Nanos will have the newer software, I would suggest moving your RT+ ODA groups away from 8A or 9A just to avoid this problem.
After the 1.0.2 release, I noticed another small issue with the Nano’s RT+ tagging support that Apple has acknowledged and is working on. If you’re tagging more than just ITEM.ARTIST and ITEM.TITLE, you should note that in some cases the Nano doesn’t like when these two fields are separated in separate tags.
So, for example, if you are tagging ITEM.ARTIST, ITEM.TITLE and ITEM.ALBUM, be sure to put ITEM.ARTIST and ITEM.TITLE in the same RT+ tagging packet, and then send ITEM.ALBUM in a different RT+ packet. This is a simple work-around until the problem has been addressed by Apple, and it’s compatible with other RT+ receivers like the Zune.
Also, I hope that Apple starts supporting ITEM.ALBUM on the display. Right now, if your station encodes and send the song’s Album data via RT+, it never will show up on the display of the Nano. The Zune HD supports this feature and I hope the Nano does someday too.

Summary

The new Apple Nano offers a good FM tuner and a great user experience for its first product to support an integrated radio. I hope Apple continues to work on improving the user’s experience by improving on some of its issues with RT+ support that I noted above. I also hope Apple publishes its proprietary iTunes Tagging RDS protocol public for the entire industry to see.
If your station isn’t encoding with RDS, you should consider encoding to support this device and a whole host of new products that support RDS on the marketplace.
If your station is encoding with RDS, make sure that you’re paying attention to the data you’re sending in the short eight-character PS, as well as the longer 64-character RadioText. My testing with the Nano shows that most stations are not encoding with the new RT+ standard. With the Nano and the Microsoft Zune line of products, it’s important for all stations that support RDS to add RT+ encoding. Those that don’t encode with RT+ don’t offer the same user experience; and your competition might already be encoding. I strongly suggest you consider adding this functionality; it’s in the best interest of your listeners. As more broadcasters ask for their vendors to support RT+, better, lower-cost solutions should come to market as well.
If broadcasters get on the RT+ encoding bandwagon, it will encourage receiver manufacturers to embrace the standard and incorporate FM tuners and tagging in their devices. I think this is a great opportunity for broadcasters to rally for the RT+ standard and start rapid deployment. If we can get this done, I think we’ll all be delighted at the results. Meanwhile, I hope Apple will consider FM (and HD Radio) tuners in future revisions of its iPhone and iPod Touch flagship products.
Maybe even AM?

Mashup e metadati ci guideranno verso i programmi radiotv

Dall'inesauribile miniera dei blog della BBC estraggo qualche pepita riferibile alle applicazioni e ai prototipi presentati poche settimane fa in occasione di Mashed 2008. Una delle due cose che mi sembrano più curiose (ce ne sono altre ma voglio evitare la sindrome di Stendhal da software esoterico) è il mashup di Patrick Sinclair, che ha messo insieme i feed relativi agli artisti i cui brani sono stati trasmessi dai vari spettacoli radiofonici della BBC con i dati prodotti dalla comunità di MusicBrainz, un metadatabase musicale costruito dagli iscritti accedendo direttamente al sito della comunità o utilizzando alcuni programmi client musicali (per esempio ogni volta che si esegue un CD sul computer il player invia a MusicBrainz i tag e le informazioni relative). Con il mashup di Patrick, accessibile qui, in pratica si ottiene un sistema di raccomandazione automatico che visualizza da un lato gli artisti più ascoltati e dall'altro gli show radiofonici che li trasmettono. Il mashup è stato realizzato con il Semantic Space della University of Southamtpon, un interessante tool capace di creare strutture di oggetti tra loro correlati.

L'altro progetto, credo ancora più significativo, si chiama URIplay ed è in fase di sviluppo, con i soldi della BBC, nei laboratori di Meta Broadcast, una startup londinese specializzata in software per la distribuzione di contenuti video. URIplay viene definito come un DNS (domain name server) per i contenuti multimediali. URI, uniform resource identifier, è la generalizzazione del concetto di URL (l'indirizzo di una pagina Web) e in questo caso l'intenzione è costruire un sistema di metadati che permetta di identificare in modo univoco i contenuti multimediali nello "spazio" definito dai siti delle emittenti radiotelevisive. Proprio come l'albero di un DNS, URIplay funzionerebbe in modo completamente nascosto all'utente, che però avrà modo di accedere ai contenuti e ai programmi radiotelevisivi desiderati in modo assai più diretto e indolore, senza interminabili ricerche sul Web. Voglio citare qui questo passaggio della overview del progetto, i cui autori spiegano che:

URIplay aims to restore simplicity to the experience without reducing choice. We compile and publish metadata files listing the URIs at which content can be played. Each URI is described in terms of media data format, revenue model, and restrictions applied. Developers will be able to use this information and our open API to refer precisely to the content and select appropriate URIs for their users.
URIplay will succeed via a community effort to design it, import data, improve its accuracy and then use it in applications. Below you will find the roles we have identified in this project.