BBC National re-config - Frankenstein stream

[andimik]

BBC National regularly uses re-configuration of the mux. It has been described first in https://www.rundfunkforum.de/viewtopic.php?f=11&t=55891&start=3330 (and following English language pages).

The issue is called Frankenstein stream due to a very strange output message (see below).

It's impossible to listen to the news (because the re-config is done exactly at the beginning of the hour) on some channels.

A raw file is
see below
(thanks to user DanDAB)

These services play without problems in welle.io

BBC Radio 1 (0xc221) Pri subch= 1 start= 0 CUs= 96 PL=uep 3 bitrate=128
BBC Radio 2 (0xc222) Pri subch= 2 start= 96 CUs= 96 PL=uep 3 bitrate=128
BBC Radio 3 (0xc223) Pri subch= 3 start=192 CUs=140 PL=uep 3 bitrate=192
(it's playing also with 160 kBit compared to Andi's DAB player)

There is no sound after re-config for

BBC Radio 4 (0xc224) Pri subch= 4 start=332 CUs= 96 PL=uep 3 bitrate=128
BBC Radio 5 Live (0xc225) Pri subch= 5 start=428 CUs= 58 PL=uep 3 bitrate=80
BBC Radio 1Xtra (0xc22a) Pri subch=10 start=582 CUs= 96 PL=uep 3 bitrate=128
BBC AsianNetwork (0xc236) Pri subch= 7 start=486 CUs= 48 PL=uep 3 bitrate=64
BBC WorldService (0xc238) Pri subch= 9 start=534 CUs= 48 PL=uep 3 bitrate=64
BBC Radio 4Extra (0xc22c) Pri subch=12 start=774 CUs= 58 PL=uep 3 bitrate=80
BBC Radio 6Music (0xc22b) Pri subch=11 start=678 CUs= 96 PL=uep 3 bitrate=128

See logfile attached
welleio.log

[AlbrechtL]

Thanks for reporting. Please upload your file again.

[andimik]

Sorry for the delay, did not read your answer.

Update: I had provided the file for you on my homepage, but this was in year 2020.

[AlbrechtL]

Thanks for the file. Now I can reproduce the issue.

Do you know when the BBC will switch to DAB+?

[nickpiggott]

The reconfiguration process is entirely normal and part of the standard. In the run-up to reconfiguration, the new configuration is sent interleaved with the current configuration (for at least 15 frames prior to the change), and there's a frame counter to tell you exactly which frame to change over on. I wouldn't call it Frankenstein.

The BBC has never made any comment on a timeline for changing to DAB+. It's possible they'll be the last to change and only change some of their services.

[AlbrechtL]

@nickpiggott Thanks for your explanation. Because I'm living in Germany I'm not effected and thus this bug doesn't have high priority on my list.

But I will leave this issue open because we shall fix it.

Pull requests are welcome!

[AlbrechtL]

Does the BBC still broadcasts via DAB?

[andimik]

Yes, it's still DAB (old), but in Central Europe it's no longer possible to receive the BBC DAB feed, as they are on the Spot Beam on 28.2 East. So I cannot provide current samples ...

[AlbrechtL]

The reconfiguration process is entirely normal and part of the standard. In the run-up to reconfiguration, the new configuration is sent interleaved with the current configuration (for at least 15 frames prior to the change), and there's a frame counter to tell you exactly which frame to change over on.

@nickpiggott Can you point me to that direction where to find this information within the frame?

[nickpiggott]

Hello

It's in section 6.5 (Multiplex Reconfiguration) of EN 300 401.

The C/N flag on the relevant FIGs indicates if that FIG refers to the Current or Next configuration of the multiplex. For example, the ordering of subchannels and the start of each channel may change at a reconfiguration.

[AlbrechtL]

Thanks for that. I just saw that the backend already detects the reconfiguration but is not handling it :-(.

welle.io/src/backend/fib-processor.cpp

Lines 144 to 157 in 330ee0a

	if (changeflag == 0)
	return;
	// else if (changeflag == 1) {
	// std::clog << "fib-processor:" << "Changes in sub channel organization\n") << std::endl;
	// std::clog << "fib-processor:" << "cifcount = %d\n", highpart * 250 + lowpart) << std::endl;
	// std::clog << "fib-processor:" << "Change happening in %d CIFs\n", occurrenceChange) << std::endl;
	// }
	// else if (changeflag == 3) {
	// std::clog << "fib-processor:" << "Changes in subchannel and service organization\n") << std::endl;
	// std::clog << "fib-processor:" << "cifcount = %d\n", highpart * 250 + lowpart) << std::endl;
	// std::clog << "fib-processor:" << "Change happening in %d CIFs\n", occurrenceChange) << std::endl;
	// }
	std::clog << "fib-processor: " << "changes in config not supported, choose again" << std::endl;
	}

Maybe an option is simply retuning to the service. This is not nice but should work.

[AlbrechtL]

OK, I added a workaround in c0434be.

It is not a nice solution because it just restarts the decoder, which creates a short audio drop. But it is better than nothing :-).

Please test https://welle-io-nightlies.albrechtloh.de/20241009_c995c85b_Windows_welle-io-setup_x64.exe.

[beermad]

Thanks for this attempt. Unfortunately it seems not to work.

Log shows output from a test run, with audacious streaming the audio on one channel.
I hope this gives some useful clues; if there's any more information you need, just ask - is there a debug mode that would give more useful data?

welleTest.log

Log from latest production welle-cli at the same time (fortunately I have two dongles). Note that timestamped lines come from my monitor/restart daemon.
wellePrimary.log

[AlbrechtL]

Thanks for the test. I reopened the issue.

Since I'm living in Germany, I can't try this by my own. I did the test with the recording by @andimik.

Can you provide me a RAW file recording? In the expert mode you can do a RAW file recording.

[beermad]

Can you provide me a RAW file recording? In the expert mode you can do a RAW file recording.

Will do. Is that from the option "Enable Tll decoding to console log"? Or is some other option I haven't noticed needed?

[andimik]

No, please have a look at https://www.welle.io/devices/rawfile

[AlbrechtL]

You can also try the experimental RAW file recorder

But you have to catch the reconfiguration. So the best would be to have a sample with +-5 minutes around the reconfiguration.

[beermad]

No, please have a look at https://www.welle.io/devices/rawfile

Great, thanks.
The next reconfiguration I can confidently predict will be late on Monday afternoon. I'll record that and upload it.

[beermad]

Raw DAB dump (uploaded to cloud as it's a bit big to do in browser) https://filedn.com/lnJp6X7QX8y063Wuq1QkInV/20241014_165850_12B.iq

Output from welle-cli -f 20241014_165850_12B.iq -p "BBC Radio4" (using the welle-cli built from your updated files).
log.txt

[AlbrechtL]

Thanks, I got the file!

[andimik]

but the SNR is very bad, hard to get errorfree audio.

[beermad]

but the SNR is very bad, hard to get errorfree audio.

I was surprised how poor the sound quality was after recording the stream using your dab_raw_record.sh script. Though something seemed a bit odd about it, as it ignored my -t argument and I had to kill it manually after the sync failure had occurred.

I wonder if the hard-coded sample rate might need changing, though when I tried doubling the rate it didn't work.

I may try again, dumping from welle-io when the problem recurs tomorrow evening if necessary.

[andimik]

You could also use

• https://github.com/JvanKatwijk/qt-dab/releases/ (save as xml file, this is smaller than sdr)
• https://github.com/KejPi/AbracaDABra/releases (see Ensemble Information menu)

[beermad]

Another attempt at a dump, this time using welle-io.
https://filedn.com/lnJp6X7QX8y063Wuq1QkInV/welle-io-record.iq

I think it stopped recording pretty much as soon as the sync was lost, so just have to hope it managed to get what you need. Much better quality this time round.

[andimik]

Yes, much much better (21 dB)!

[AlbrechtL]

@beermad Thanks for the new file. I just checked it. The SNR is fine now, but I don't see a reconfiguration included.

[beermad]

@beermad Thanks for the new file. I just checked it. The SNR is fine now, but I don't see a reconfiguration included.

Hmmm... Sorry about that. I was pretty sure I'd caught it. I'll have another try and actually check it before uploading it. I have a suspicion it may simply have ground to a halt when the mux reconfigured, so if necessary I'll try one of the other tools you suggested.

[beermad]

This may take a bit longer than I'd hoped. The regular 1800 reconfiguration I was relying on hasn't happened for a few days. I'm having to do some work to find out another time I can rely on.

[beermad]

Apologies for the delay; it seems the BBC's schedule for reconfiguring its multiplex has changed, so I could no longer rely on what was the regular 1700 reconfiguration.
New recording uploaded to my loud server](https://filedn.com/lnJp6X7QX8y063Wuq1QkInV/BBC.uff).

I've double-checked and there's definitely a reconfiguration here. AbracaDABra (which I recorded it with) took the change in its stride, but playing back the recording with well-cli I get the usual crash.

[andimik]

Yes, BBC Radio 5 gets a new subchannel.

0xC225 BBC Radio5Live [ BBC R5L ] ECC: 0xE1, Country: United Kingdom, PTy: News (static), Announcements: No
AudioComponent (primary), SCIdS: 0, Label: 'BBC Radio5Live' [ 'BBC R5L' ], ASCTy: 0x0 (MP2)
      SubChId: 5, Language: English, StartCU: 428, NumCU: 58, UEP #21, Protection level: 3, Bitrate: 80kbps

becomes

0xC225 BBC Radio5Live [ BBC R5L ] ECC: 0xE1, Country: United Kingdom, PTy: News (static), Announcements: No
AudioComponent (primary), SCIdS: 0, Label: 'BBC Radio5Live' [ 'BBC R5L' ], ASCTy: 0x0 (MP2)
      SubChId: 5, Language: English, StartCU: 404, NumCU: 48, UEP #16, Protection level: 3, Bitrate: 64kbps
AudioComponent (secondary), SCIdS: 3, Label: 'BBC Radio5SX' [ 'BBC R5SX' ], ASCTy: 0x0 (MP2)
      SubChId: 8, Language: English, StartCU: 500, NumCU: 48, UEP #16, Protection level: 3, Bitrate: 64kbps

[beermad]

For info, I've been monitoring this more closely than usual (mainly so I can work out the new pattern of reconfigurations to schedule any future tests). I've found three distinct error messages appearing:
Big change (MPEG version, layer, rate). Frankenstein stream? (As given in the original bug report)
Illegal Audio-MPEG-Header 0xf0d044c4 at offset nnnnnn
Hit end of available data

Cheers.

[AlbrechtL]

These error messages are coming direct from the mpg123 library and are indicating that the stream is broken. I mean that's correct because the stream is broken. What we have to do is to restart the decoder once the reconfiguration is detected. In c0434be I tried to restart the decoder but it seems that this is not working :-(.

It is possible for you to provide a IQ RAW file with included reconfiguration?