DAB+ decoder for OpenWebRX

[T-Shilov]

Dear Jakob, this is only a request.

In the city Kiev, Ukraine, there are 14 radio stations broadcasting in the digital standard DAB+ .

The frequency used is 222.064 MHz, so the distance receive is small.
It would be nice if the whole world listened this radio stations.
Please, add the DAB+ decoder to the OpenWebRX.

Thank! :-)

[jketterl]

Is there any commonly used decoding software that works on the commandline?

[dc7ds]

Welle.io cli Gesendet SD mobil

…

Am 16.07.2020 um 09:19 schrieb Jakob Ketterl ***@***.***>:  Is there any commonly used decoding software that works on the commandline? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jketterl]

Alright, seems to check out. Will still require some other work to be done beforehand since I suppose nobody would want to listen to DAB+ at 11kHz audio. That's the same limitation in the audio chain that prevents wideband FM.

[T-Shilov]

Dear Jakob, I assure you that the sound in DAB+ format is excellent and not inferior to classical FM :-)

I myself was amazed when I first heard this wonderful digital sound.
Probably the great sounding comes from the high 64 kbps bitrate and the AAC codec.
If You want, I will make an audio recording so that you can so sure the high quality of DAB+ sound
PS. This receiver adopts classic FM radio and DAB+

[jketterl]

Thanks for the offer, it won't be necessary, I do have a DAB+ capable device available. I hear that many people are complaining about the low bitrates, I'm not really too involved into it, so that discussion doesn't really matter much to me. The local radio stations' content is of very little interest to me personally.

Still, audio reproduction in OpenWebRX wouldn't do it justice, at least as long as the current audio pipeline was to be used. It is transferring audio at a maximum sample rate of 12kHz (depending on the client), so the maximum audio frequency that could be heard on the output would be 6kHz (Nyquist). Basically, it would sound as dull and muffled as an AM station.

[T-Shilov]

You have convinced me.
Although it is a pity that it did not work out :(

[jketterl]

I'm not saying that it won't work... as I said before, it will need more work ahead to make it possible.

[nmaster2042]

I don't know if this could be included into openwebrx but there is a DAB/DAB+ console decoder:
https://github.com/Opendigitalradio/dablin
There is debian package avaliable:
https://packages.debian.org/search?keywords=dablin

[jketterl]

not looking to good, on both ends. both welle.io as well as dab2eti require direct access to the rtlsdr device, which is of course impossible, since it would be in use by OpenWebRX. I haven't found a way to pass IQ data on STDIN, which is how demodulators are normally fed. welle.io may be fed by faking an input file with a fifo... and dablin may be fed with an ETI stream, if there's a tool available that would allow converting IQ data to ETI.

Mind you, all the algorithms are in place, it's just that nobody thought of this more advanced use case, or of a more modular design. Dablin appears to me more as a proof of concept, whereas welle.io seems to be designed rather as a stand-alone radio application...

[T-Shilov]

Well, if such difficulties arise in the implementation of this algorithm, then it is not necessary to do it.
In this situation, it is better to focus on solving other, more necessary tasks for OpenWebRX.

[nmaster2042]

@jketterl: I missed the ETI from IQ needed in the openwebrx context.

I found a tool here https://github.com/JvanKatwijk/eti-stuff
It can actually read raw files and extract ETI and then feed dablin.

But I agree, DAB is probably not the most waited feature.

[andimik]

@jketterl

I hear that many people are complaining about the low bitrates

Well, please don't complain about DAB+ itself.

Lots of European countries have got a much better sound on DAB+ than on FM thanks to bitrates > 88 kBit.

If you want to listen how it should sound, please click on this link

http://www.dabmon.de/p/8004/playlist/9.m3u

144 kBit of Classical public service of BR in Bavaria, Germany.

Remark: this is NOT an Internet Stream, it's the DAB monitor.

[jketterl]

I'm not complaining. I'm only explaining why I don't think it's worth the effort.

[jketterl]

Alright, I finally got around to working on this. I ported the code from dab2eti into a csdr module so that it can work with arbitrary IQ data. The output is then passed to dablin for audio decoding. The result does work, but is very CPU hungry. From what I can tell, the latter is inherent to the original code. Will need to see if there is potential for optimization.

If you want to try it, this is on the "develop" branch, experimental repository and docker :latest tags.

[basicmaster]

@jketterl I added a RIFF WAVE output to DABlin's next branch which should allow you to retrieve the actual sample rate and channel count, for playback of the decoded audio.

[jketterl]

So... here's the thing. The issue with the sample rate mismatch came up repeatedly on the mailing list, with various people making suggestions on how to address the issue. I was complaining about the fact that there's no proper issue to track this (see here). Somebody obviously thought that it was a good idea to open up an issue over on the dablin project to have you guys fix this problem.

What I actually was looking for was a place to be able to discuss the various different approaches on how to solve this issue, with all the involved pros and cons.

I'm not even sure if the solution, as proposed, is even viable since I have no component available to parse the WAV header. It hasn't been debated weather a RIFF / WAV header is even suitable for this purpose (as far as I remember, it contains the length of the file, which does not apply to streaming data). And on top of that, any solution that requires changes to the dablin code is going to require extra efforts in the distribution (we don't build dablin packages yet, and it may take a year or longer until this change has propagated to the distributions).

So yeah... I don't know if this solves the problem. I'll have to look how much effort it would be. And there's still no issue here on this repository to track all of this.