Skip to main content
Topic: DAB+: Can the specifics of encoding be determined from the signal? (Read 2478 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

DAB+: Can the specifics of encoding be determined from the signal?

While playing around with SDR, I decided to check out the local DAB+ stations.

In my area there are two DAB+ stations that I can receive, one on T-DAB block 5C and 9A.
The bitrates of the available programming is either 48kBit/s, 64kBit/s, 72kBit/s, 96kBit/s, 98kBit/s, 104kBit/s, and 112kBit/s.

The channels run by our public broadcasting service, on block 9A, with all channels at 96kBit/s.
On block 5C, there are a number of private radio channels and a couple public broadcaster channels. One of those is geared towards cultural audio broadcasting and transmits at 112kBit/s, the regular rock radio channels use 64kBit/s or 72kBit/s, and two channels geared to spoken programming, one of those is a religious channel, submit at 48kBit/s.
The classic radio channel, uses 104kBit/s.

As I don't see the bitrate change, I assume it's encoded at a fixed rate, this would make sense for over-the-air radio broadcasting.
I'm wondering if this is a DAB+ requirement, but I certainly believe so, as the bandwidth is probably priced differently.

Is it possible to extract information about the encoder from the stream itself? Such as which one was used, and encoder settings perhaps? If the data isn't available in some form of metadata (I haven't looked into exactly how a DAB+ channel is composed), can these settings and information be somehow estimated perhaps?

I'm using a DAB decoding library right now, which does most of the encoding for me, and just presents me with a tiny bit of information (like the bitrate), and returns a PCM stream which I can then directly forward to my sound device, via libav and pulseaudio.

My original goal was to inspect TPEG data channels, but when I'm looking at the audio anyway, why not.

EDIT: I assume most people know this, but DAB+ uses HE-AAC-v2

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #1

Is it possible to extract information about the encoder from the stream itself? Such as which one was used, and encoder settings perhaps? If the data isn't available in some form of metadata (I haven't looked into exactly how a DAB+ channel is composed), can these settings and information be somehow estimated perhaps?

I'm using a DAB decoding library right now, which does most of the encoding for me, and just presents me with a tiny bit of information (like the bitrate), and returns a PCM stream which I can then directly forward to my sound device, via libav and pulseaudio.

My original goal was to inspect TPEG data channels, but when I'm looking at the audio anyway, why not.

EDIT: I assume most people know this, but DAB+ uses HE-AAC-v2

 know that certain file formats include information about the required decoding in their headers.  For example, the well known .wav file specification: http://soundfile.sapp.org/doc/WaveFormat/ 

I do a lot of what I do related to the forensics of file provenance is accomplished by looking at the decoded audio stream with a FFT.

44/16 PCM .wav is practically speaking an overkill file format and a lot of perceptual coders throw away actual audio bandwidth to obtain more efficient coding.  This is done in stages so really low bitrates are rarely anything like broadband enough to be sonically transparent.

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #2
know that certain file formats include information about the required decoding in their headers.  For example, the well known .wav file specification: http://soundfile.sapp.org/doc/WaveFormat/ 

I do a lot of what I do related to the forensics of file provenance is accomplished by looking at the decoded audio stream with a FFT.

44/16 PCM .wav is practically speaking an overkill file format and a lot of perceptual coders throw away actual audio bandwidth to obtain more efficient coding.  This is done in stages so really low bitrates are rarely anything like broadband enough to be sonically transparent.
Before I can examine the headers, I kinda have to know what to look for, as I don't know the container format, etc.

The AAC stream is contained in the ETI format which is the 2048kBit/s stream on a DAB channel, containing all subchannels and forward error correction. As far as I can tell, the ETI stream contains the subchannel audio streams in an ADTS format. The ETI spec I'm reading right now, isn't particularly clear about this, but it kindof allures to:

http://www.etsi.org/deliver/etsi_i_ets/300700_300799/300799/01_30_9733/ets_300799e01v.pdf
and
http://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_20/en_300401v020101a.pdf

So each subchannel contains its own error correction, which is selectable. Inside that, are frames containing MOT (pictures, etc.) textual data containing the current song name, etc. and the actual audio.

I've had a look at ODR-AudioEnc: http://wiki.opendigitalradio.org/ODR-AudioEnc
However I haven't yet figured out what kind of container it uses. I still believe it's some ADTS container.

What makes this entire issue a bit more difficult, is that you can squeeze a DAB (MP2/Musicam) and DAB+ (HE-AAC-v2) stream into the same subchannel. This is done to make the channels (called "Blocks" when talking about DAB/DAB+) backwards compatible to people who bought a DAB radio before around 2011, when DAB+ started to become more widespread than DAB. I believe both streams are in their own containers, though.

If this effort goes nowhere, I'd like to analyze the signal itself. Although I doubt that I'll be able to make great assumptions, which encoder was used, I don't think they leave a very distinctive fingerprint in the signal itself, etc.

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #3
When you dive a bit deeper into the stream, bear in mind that DAB+ uses a 960 AAC window instead of the more common 1024 one. Many typical decoders can't decode this correctly. It's part of the HE-AAC spec but since it's only used in digital radio (as far as I know) most decoder implementations simply skipped it. Here is five years of discussion about implementing it in FFMPEG. If decoders stumble on a MDCT window of 960, some analysis tools might do too and return unreliable results.

I have never found out why DAB+ uses this slightly unusual setup but I have wondered whether it has something to do with the additional transport encapsulation and Reed-Solomon error correction that needs to be put around the audio stream.

Quote
I assume most people know this, but DAB+ uses HE-AAC-v2
Not necessarily, it usually depends on the bitrates. A good setup would use HE-AACv1 for bitrates above about 48 kb/s and HE-AACv2 below 48, although in radio nothing is certain. You may encounter slightly odd things such as HE-AACv1 being used above 96 kb/s for instance (when vanilla AAC would do) and it will depend on whether the multiplex operator knows what they're doing.

As for which encoders are used. If you receive blocks 5C and 9A and stations using these bitrates I am going to take a punt (OK, an educated guess) and say you live in Germany (Saarland?). In that case, Media Broadcast GmbH is your infrastructure owner and they will operate the multiplexers that do the actual final encoding.

I might be wrong but I think I recall that Media Broadcast uses multiplexers from Factum so to find out which encoder you are hearing you’d need to find out which encoder Factum puts in their appliances. It could be an in-house developed encoder although I think it's more likely they will have licensed an existing commercial AAC encoder implementation (Blackfin?), probably cheaper than developing one themselves.
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #4
When you dive a bit deeper into the stream, bear in mind that DAB+ uses a 960 AAC window instead of the more common 1024 one. Many typical decoders can't decode this correctly. It's part of the HE-AAC spec but since it's only used in digital radio (as far as I know) most decoder implementations simply skipped it. Here is five years of discussion about implementing it in FFMPEG. If decoders stumble on a MDCT window of 960, some analysis tools might do too and return unreliable results.
Ok, the shorter MDCT window is something I haven't though about, but when analyzing the signal with Matlab, this shouldn't be much of an issue.

I have never found out why DAB+ uses this slightly unusual setup but I have wondered whether it has something to do with the additional transport encapsulation and Reed-Solomon error correction that needs to be put around the audio stream.
Error correction in DAB is done in various selectable strengths, so a subchannel might have a lower audio bitrate, but the strength might be bigger.

Quote
I assume most people know this, but DAB+ uses HE-AAC-v2
Not necessarily, it usually depends on the bitrates. A good setup would use HE-AACv1 for bitrates above about 48 kb/s and HE-AACv2 below 48, although in radio nothing is certain. You may encounter slightly odd things such as HE-AACv1 being used above 96 kb/s for instance (when vanilla AAC would do) and it will depend on whether the multiplex operator knows what they're doing.
All audio streams on the two blocks I can decode are all HE-AAC-v2. I've confirmed them so far myself. Even the one subchannel at 112kBit/s, uses HE-AAC-v2. Traditionally, other HE-AAC profiles have been used, but they usually default to -v2 it'd seem.

As for which encoders are used. If you receive blocks 5C and 9A and stations using these bitrates I am going to take a punt (OK, an educated guess) and say you live in Germany (Saarland?). In that case, Media Broadcast GmbH is your infrastructure owner and they will operate the multiplexers that do the actual final encoding.
Erm, no I live quite far from Saarland, but OK, the "Bundesmux" multiplexer is operated by Media Broadcast, the other by the public broadcaster (in my case NDR).

I might be wrong but I think I recall that Media Broadcast uses multiplexers from Factum so to find out which encoder you are hearing you’d need to find out which encoder Factum puts in their appliances.
Oh, how did you find out what muxers Media Broadcast uses? I might be able to find out which one the NDR uses, too. I was considering simply emailing them and see if I get a response. I'm interested in that, because a couple months ago, I recall Fraunhofer presenting an xHE-AAC appliance (19" rack mount device) at some sort of tech convention. xHE-AAC was supposed to be rolled out for Digital Radio Mondiale, but I've never heard of anything after that.
I'd assume that appliance makers like these, directly license a Fraunhofer encoder, or something. How to find out which one they use, is kinda beyond me.

I'm still not exactly sure, how the AAC stream is contained, though. As I understand it, the ETI channel contains metadata for each subchannel, but is the AAC stream within each subchannel contained, or a raw AAC stream, with all relevant metadata contained in the ETI as well? I doubt that. It seems as if the AAC is contained in an ADTS stream, within the ETI. I'll have a look at dabtools and see if it can display data of the ETI a bit better.

Unfortunatelly, the spec isn't really clear about all that. They didn't even bother putting a channel diagram in there...

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #5
When you dive a bit deeper into the stream, bear in mind that DAB+ uses a 960 AAC window instead of the more common 1024 one. Many typical decoders can't decode this correctly.
Aha, that would explain why foobar2000 plays such streams slower than it should.
In theory, there is no difference between theory and practice. In practice there is.

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #6
Oh, how did you find out what muxers Media Broadcast uses? I might be able to find out which one the NDR uses, too. I was considering simply emailing them and see if I get a response.
The big hardware suppliers tend to send out a press release when they secure a big sale. Being selected to provide the hardware for a nationwide infrastructure provider is (literally) a big deal for them so they tend to shout it from the roof tops in industry media. Here are Factum's announcements for networks in Belgium, Switzerland and Malta for instance.

I tried a quick search to see if I could find anything but unfortunately "Media Broadcast" is a very generic search term and "Germany" is not specific enough. Any announcement will probably have been early 2008 or earlier so quite some time ago.

Quote
I'm still not exactly sure, how the AAC stream is contained, though. As I understand it, the ETI channel contains metadata for each subchannel, but is the AAC stream within each subchannel contained, or a raw AAC stream, with all relevant metadata contained in the ETI as well? I doubt that. It seems as if the AAC is contained in an ADTS stream, within the ETI. I'll have a look at dabtools and see if it can display data of the ETI a bit better.

Unfortunatelly, the spec isn't really clear about all that. They didn't even bother putting a channel diagram in there...
I'm afraid that is a level of detail I don't have either. Perhaps the people at OpenDigitalradio.org might be able to help you. They have created an open source broadcasting solution so I'd expect they would need to know how to create a DAB+ compliant stream. Otherwise the people behind eti-tools?
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #7
When you dive a bit deeper into the stream, bear in mind that DAB+ uses a 960 AAC window instead of the more common 1024 one. Many typical decoders can't decode this correctly.
Aha, that would explain why foobar2000 plays such streams slower than it should.

That is indeed the problem. I don't think slower is the right way to describe it, though, it is more that the pitch of what's being played is lower. That makes it sound as if it is slowed down a bit.

As Foobar2000 uses FFMPEG it would need to be solved there and the fix will eventually make its way to Foobar too.
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #8
Oh, how did you find out what muxers Media Broadcast uses? I might be able to find out which one the NDR uses, too. I was considering simply emailing them and see if I get a response.
The big hardware suppliers tend to send out a press release when they secure a big sale. Being selected to provide the hardware for a nationwide infrastructure provider is (literally) a big deal for them so they tend to shout it from the roof tops in industry media. Here are Factum's announcements for networks in Belgium, Switzerland and Malta for instance.

I tried a quick search to see if I could find anything but unfortunately "Media Broadcast" is a very generic search term and "Germany" is not specific enough. Any announcement will probably have been early 2008 or earlier so quite some time ago.
OK, but this is a good idea to start from. Hardware supply deals to public media broadcasters should be a good enough deal to do a press release, I'd imagine.

Quote from: polemon
[...]
Unfortunatelly, the spec isn't really clear about all that. They didn't even bother putting a channel diagram in there...
I'm afraid that is a level of detail I don't have either. Perhaps the people at OpenDigitalradio.org might be able to help you. They have created an open source broadcasting solution so I'd expect they would need to know how to create a DAB+ compliant stream. Otherwise the people behind eti-tools?
Yes, them and the developers of qt-dab are my prime source of information right now. However sieving through the source code to understand the format is a bit annoying. But if I can find enough time, I'll do that, then.

Re: DAB+: Can the specifics of encoding be determined from the signal?

Reply #9
Actually, I was wrong. It seems DAB+ indeed uses a variety of AAC profiles. However from the software source it wasn't clear about that, there's a lot of autodetecting going on, etc.

At this point, it'd be interesting if DAB+ would accept an AAC-LC or AAC-LD stream.

 
SimplePortal 1.0.0 RC1 © 2008-2018