DLS not decoded from some DAB+ services

[nickpiggott]

Environment
dablin_gtk 1.16
Ubuntu 24.03.4LTS
BBC National Multiplex (Ch 12B)

Symptom
DLS Text is not shown when listening to DAB+ services from BBC National multiplex.

Expected Behaviour
DLS Text shown from both DAB (MPEG-2) and DAB+ (HE-AAC) services

Other points
dablin_gtk 1.16 does correctly show DLS text from DAB+ services generated by odr-dabmux / odr-audioenc / odr-padenc
dablin_gtk 1.16 does correctly show DLS text from DAB (MPEG-2) services on the BBC National multiplex
Other radios are correctly showing DLS text from the BBC DAB+ services
The problem seems to be on services encoded on the Factum Radioscape multiplex platform, but legacy receivers are decoding it correctly, so it must be to be specification?

[basicmaster]

The reason for this behaviour is the PAD encoding for the DAB+ services e.g. "BBC Radio1Dance":

In the present case the short X-PAD is used, so the X-PAD of a DAB+ Audio Unit (AU) contains 4 bytes. Also the option to omit the Contents Indicator (CI) is used. At the same time, apparently only every other AU contains an X-PAD field.

ETSI EN 300 401 states in 7.4.2.1:

The contents indicator may be omitted if the X-PAD data sub-field (4 bytes long) contains a continuation of the X-PAD
data group or the byte stream carried in the previous DAB audio frame or DAB+ audio AU (i.e. data for the same user
application).

So strictly speaking, as the previous AU contains no X-PAD at all here, there is a "gap" and this continuation case does not apply.* Hence a contents indicator must be present. As DABlin aims to adhere to the spec, it does not allow the omission of the contents indicator in this case and in the end, no DLS can be decoded here.

You can loosen this strict behaviour by invoking DABlin with the -L parameter. This way the PAD conformance is not strictly followed and in the particular case, the DLS can be decoded:

*Maybe here the original intention has been to not refer to the previous audio frame/unit, but to the nearest preceeding X-PAD, which would definitely make sense. E.g. appending "that contains an X-PAD field" to "previous DAB audio frame or DAB+ audio AU" would fix this.

[nickpiggott]

So the problem is that the wording in EN 300 401 is imprecise, as it's not clear if it means:

• Sequential X-PAD datagroups / bytes in the bytestream
  OR
• Sequential Audio frames / AUs

The interpretation here is that the reference to sequential refers to frames / AUs, therefore the presence of an AU with no X-PAD bytes makes it non contiguous.

However it seems that the multiplex software (which I believe is Factum Radioscape in the cases that I have seen in the UK, not just the BBC National Multiplex) inteprets this as sequential X-PAD datagroups, so where the only X-PAD application is DLS, the CI is always omitted, even if X-PAD bytes are not allocated in every frame/AU.

It looks like clarification would be a good idea. I'll ask some questions.

[lindscornell]

Very interesting! It's many, many years since DAB+ was introduced but this seems to be one of those unforeseen consequences... In DAB audio coding there is PAD in every audio frame (not absolutely required by the specification, but always the case in practice), but in DAB+ audio coding the flexibility to include or not has been used... The wording in EN 300 401 was not changed to reflect this... clearly it should have been. The CI is in the PAD stream, so the inclusion or omission of CI is related to the PAD stream, not to the audio frames/audio access units - we really should respect the communication layers not the physical layers... Luckily EN 300 401 is currently in revision mode in the WorldDAB TC so we can make a change to address this issue. The proposed additional words by "basicmaster" will be added to the working draft revision for discussion. My personal observation is that commercial DAB receiver products do use a looser interpretation of the specification because they present the dynamic labels.

[basicmaster]

It's many, many years since DAB+ was introduced but this seems to be one of those unforeseen consequences.

The DAB and the DAB+ case are actually not that different regarding the PAD presence:

In DAB, the F-PAD field is always present by definition, due to its fixed position within the MP2 frame.
In DAB+, the F-PAD is "present" in one way or the other, as a consequence of 5.4.3 in TS 102 563:

If no data_stream_element() is present at the beginning of the AU, or if the length of the data_stream_element() is less
than two bytes (i.e. an invalid length for PAD data), then the PAD decoder shall react as if the F-PAD field had been
received with both bytes set to zero and no X-PAD data is available.

Hence for both DAB and DAB+, there is always an F-PAD, but the X-PAD field can be present or not. So this CI omission case could have already affected plain DAB.

So far I have never observed this case for DAB, but just for DAB+. This seams reasonable, as with DAB+ the F-PAD (or rather the complete PAD) can be omitted every other frame to save a few bytes, while in DAB this had no effect (as always present).

The CI is in the PAD stream, so the inclusion or omission of CI is related to the PAD stream, not to the audio frames/audio access units - we really should respect the communication layers not the physical layers.

Agreed.

Luckily EN 300 401 is currently in revision mode in the WorldDAB TC so we can make a change to address this issue. The proposed additional words by "basicmaster" will be added to the working draft revision for discussion.

Great, thank you!

My personal observation is that commercial DAB receiver products do use a looser interpretation of the specification because they present the dynamic labels.

This is my observation, too.