This short article presumes serious understanding of the DAB protocol.

This very special DAB topic is a little older. Double-byte contents indicators do not appear in newer versions of any DAB spec. If you are involved in the development of provider equipment that encodes data via X-PAD you can safely ignore all this entirely.
If you work on receiver decoders however, there is a very small risk that your software will be fed with X-PAD data sometimes that uses double byte indicators; simply because there are documents around that do describe them.

Many PAD parsers do not care about double-byte contents indicators for a simple reason:
Double-byte contents indicators are not even mentioned in EN 300 401 –  and TR 101 496-2 is not widely known amongst developers.

Is it important?
– Yes and no:
I never have seen double-byte indicators in real life and I’m not sure if anyone does use them. I’m very sure that a normal radio equipment need not be able to understand the services that someone indicates by double-byte indicators.

However, if a parser is not prepared for double-byte indicators it may interpret the second byte of the first double-byte indicator as a normal indicator itself and this might cause big trouble.

What are double-byte contents indicators?

A normal contents indicator is one byte in size and carries 5 bits for the XpadApplicationType and 3 bits as the length indicator. A double-byte contents indicator has a value of 31 in the XpadApplicationType bit-field of the first byte and is immediately followed by a second byte that extends the XpadApplicationType; so the resulting XpadApplicationType value is 31 plus the value of the second byte.

According to EN 300 401 an XpadApplicationType  value of 31 is simply ‘not used’, according to TR 101 496-2 however, a value of 31 indicates the first byte of a double-byte indicator.

A simple solution:

If a parser shall not care about the applications indicated by double-byte contents indicators but shall work correctly for all other applications in all situations it may follow this simple procedure:

  • If the XpadApplicationType of the first byte in the contents indicator list is 31:
    -> forget the entire X-PAD field!
  • If the contents indicator list starts with two normal single byte contents indicators and the XpadApplicationType of the third byte is 31:
    -> assume the contents indicator list is 4 byte long (this is the offset of the first subfield) and consume only the subfields for the first two applications.
  • If an XpadApplicationType of 31 should appear in the second byte after one normal single-byte contents indicator or in the fourth byte after three normal single-byte contents indicators:
    -> this is illegal and I suggest to discard the entire X-PAD field!

Since it is not allowed to let a single-byte indicator follow a double-byte indicator, this solution should be safe and complete.

It is not too hard to parse even double-byte indicators correctly but this recipe can quickly fix older parsers.