How about a small audio file associated with each station.

[softwareen...@googlemail.com]

How about a small audio file associated with each station.
eg. An mp3 file that says "Planet Rock"..... to improve browsing experience (especially while driving)
Maybe an extended one too "Planet Rock - where rock lives"

[Andy Buckingham]

An interesting idea, I suspect this could be added to the SI document
against a service.

In theory, it could be done within the constraints of the existing
specification using the <link> attribute against a <service> node,
e.g.

<service>
<link uri="http://host/id.mp3" mimeValue="audio/id+mpeg">
</service>

Using the mimeValue this way is a little hacky, but the spec currently
offers no specific "machine-readable" way to explain the context of
the audio clip and I suspect we'd want a way to tell a client not to
simply expose a UI element that links to the audio file.

However, the use of audio clips as identifiers in this way could throw
up issues, for example:

1. Some broadcasters may not support it, what would a client do when
navigating to these services?
2. Additional data to retreive, store and maintain.
3. Additional overhead on broadcasters to prepare the audio content
and also ensure it's kept up-to-date should services change name etc.
4. Consistency in terms of volume and style when navigating a large
list of stations.
5. Rather than a short station ID, a malicious user may put a 30s
advert or an entire audio track in the spot.

My preferred approach, which reduces the complexity for broadcasters
and allows clients to have a consistent approach, would be to use
Text-to-Speech (TTS) to render the data within the SI file.

This can have issues with station names not always being interpreted
correctly by TTS engines and causing unusual pronunciations, but
possibly with the inclusion of a phonetic station name attribute this
could be improved. Standards such as X-SAMPA[1] exist and could be
employed alongside an additional attribute in the spec.

<service>
<phoneticName>fri:\@_Xnt_v</phoneticName>
</service>

In combination with the existing description fields both of your
suggested strings could be spoken.

[1] https://en.wikipedia.org/wiki/X-SAMPA

> --
> You received this message because you are subscribed to the Google Groups
> "RadioEPG developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to radioepg-develo...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[softwareen...@googlemail.com]

I don't want to shoot down my own idea, but ...

I suppose a .mp3 file could cause a licensing issue.

They could to be mp2s I suppose as any DAB radio at least can decode those.

I appreciate that text-to-speech has many advantages,

but if I was a broadcaster I think I'd like to have my own 'jingle'.

I don't think a broadcaster not supporting it would be a problem.

Just fall-back to text-to-speech

Consistency in volume - that's a VERY good point !

Anyway, it was just a thought.

Thanks for at least thinking about it :-)

Regards,

Pete

[Ben Poor]

If it's a jingle or sonic logo or something like that, would be best under a mediaDescription element. It's not just for station logos!