RadioVIS Text Length
Ben Poor
The message MUST NOT be longer than 128 characters. A receiver receiving a message longer than this should ignore the message.
The message MUST NOT be longer than 128 characters (a maximum of 512 bytes using 4 bytes per character). A receiver receiving a message longer than this should ignore the message.
The information in this email and any of its attachments is intended solely for the addressees and is confidential. If you receive this message in error, please immediately notify the sender, destroy any copies and delete it from your computer system.
The contents may contain information which is confidential and may also be privileged. Any part of this email may not be used, disseminated, forwarded, printed or copied without authorisation.
Liability cannot be accepted for any statements, views or opinions made which are clearly the sender's own and not expressly made on behalf of any of the companies below.
Global Radio UK Ltd (6251684) / Global Radio Holdings Ltd (4077052) / This is Global Ltd (6288359) / Global Radio Ltd (923454) / Global Radio Services Ltd (3296557) / Global Talent Group Ltd (3601691) / Global Talent Management Ltd (4631297) / Global Talent Music Ltd (5522116) / Global Talent Publishing Ltd (3509421) / Global Talent TV Ltd (4506139) / Global Talent Records Ltd (3598411) / Global Charities Ltd (4359098) Registered Office: 30 Leicester Square, London WC2H 7LA
Paolo
there could be a problem with the new requirement. RadioVIS text message inherits from DAB Dynamic Label Segment, and the maximum DLS message length is 128 bytes. So using UTF-8 (or even UTF-16) reduces the available encoded characters well below 128.
Maybe this constraint should be kept for backward compatibility. Of course an evolution of text messages could also be considered but it's a different problem.
So I suggest:
The message MUST NOT be longer than 128 bytes. A receiver receiving a message longer than this should ignore the message.
Kind regards
Paolo
Robin Cooksey
Hi Paolo,
I think it might be a good idea to look at this from the other direction.
RadioVIS text is based on DAB DLS, but I’m not convinced that its limitations should be kept – I don’t see a problem if RadioVIS text becomes more capable than DAB DLS. (Indeed, it’s already more capable than FM-RDS RadioText, on FM stations – which is limited to 64 bytes).
However, I think it is necessary for RadioVIS text to be at least as capable as DAB DLS –so that broadcasters can easily re-use existing text for RadioVIS.
As Ben says, for Stomp, the default character encoding is UTF-8. I think it would be wise to stay with UTF-8, rather than supporting other character encodings. This means that a broadcaster may need to re-encode a DAB DLS message in UTF-8, to make it available via RadioVIS.
Looking at the possible cases of DAB DLS character encodings:
If DAB was in UTF-8 – obviously it will take 128 bytes to re-encode in UTF-8.
If DAB was in UCS-2, that’s up to 64 UCS-2 characters – so it could take up to 192 bytes to encode in UTF-8 (a UCS-2 character is up to 16 bits, which take 3 bytes in UTF-8).
If DAB was in EBU, the worst case EBU character takes 3 bytes in UTF-8 – so it could take up to 384 bytes.
So, if the RadioVIS text was limited to 128 bytes, and is UTF-8, there could be perfectly valid DAB DLS messages which couldn’t therefore be re-encoded for RadioVIS – it would need to allow at least 384 bytes.
I think it might be better to keep with the spirit of the 128 character limit, and define the maximum length of a RadioVIS text message as Ben suggests – as 128 characters. As it’s UTF-8 encoding, the maximum length is therefore four times this – 512 bytes.
This will allow for the worst case DAB DLS message (in any character encoding) to be re-encoded in UTF-8 for RadioVIS, but also allows the worst case Unicode character (4 bytes in UTF-8) to be supported; rather than artificially limiting the maximum length based on supported DAB character sets.
In other words, I think I agree with Ben’s proposal.
Best regards,
Robin
Paolo
extending the DLS 128bytes limit seems to be reasonable, limitations are not written in the stone and it would be easier for us to re-encode DLS if using charsets different from UTF-8. I agree with you.
On the other hand, this is an implicit extension to the original RadioVIS spec. 128 characters is limiting, and somehow arbitrary (it enhances old FM-RDS RT ok, but it's the spirit of a 30 years old protocol - more or less). If we relax the 128 bytes DLS limit as you're suggesting, which can be a good thing, my *personal* opinion is that we could further enhance it, trying to find a new commercial requirement for text messages. For example, it's difficult to send news in 128 characters. We can think about it.
Kind regards
Paolo
James Cridland
What's the point of the 128 character limit? Is it purely display?
What would happen if some stations were to send longer than 128 characters?
How about "messages longer than 128 characters on-screen may be truncated or ignored by receivers"?
Why shouldn't we be sending more than 128 characters? Twitter is 140 after all...
Just asking, like
J
Robin Cooksey
Partly display, but also so that receivers can allocate suitable buffers to handle the messages.
In fact, as Ben quoted, the RadioVIS 1.1 specification currently says: “A receiver receiving a message longer than this should ignore the message”. So, effectively it’s already saying that messages longer than that should be ignored by receivers.
The proposed clarification really is around the meaning of the word “characters” – it’s clarifying that this means “UTF-8 characters, which can each take up to 4 bytes to encode”; rather than being an extension to the existing spec.