Week 10 – Audio encoding

This week I finished the MPEG Audio Layer II encoder for DAB transmission and the MPEG 4 HE-AAC encoder for DAB+ transmission.

Encoding the MPEG Audio Layer II for DAB

As described in a former blog post, the DAB audio frame structure only slightly differs from the MPEG Audio Layer II structure. The major differences are the use of the ancillary data that are structured in F-PAD (Fixed – Programme Associated Data) and X-PAD (eXtended – Programme Associated Data) in the DAB system. For this case, the ODR mmbTools project patched the free software mp2 audio encoder TooLAME to a DAB adapted version called libtoolame-dab which I included in the gr-dab module.

The quality assurance of the mp2 encoder can be done with any audio player that is capable of decoding the MPEG-1 Layer II codec. I encoded an audio test sample with the implemented GNU Radio mp2 encoding block and the audio player (in my case VLC media player) was able to play the produced mp2 file.

After successfully implementing the encoder, I could eventually test the mp2 decoder with my produced DAB audio frames. The loopback test (PCM_source – mp2_encoder – mp2_decoder – audio_sink) passed. The produced audio file sounded similar to the PCM source file that I fed into the test. Of course, the PCM source and sink files actually differ because mp2 is a lossy compression but the subjective congruence is sufficient in this case.

Encoding the MPEG 4 HE-AAC for DAB+

I finished the implementation of the mp4 encoder as well. The module is linked against a patch of the FDK-AAC Codec Library for Android by the Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V.. The patch, which is now a dependency for the gr-dab module, is maintained by Opendigitalradio for the ODR-AudioEnc module.

The mp4 encoding block supports different sample rates (32kHz and 48kHz) and includes (optional) an afterburner. It supports a bunch of profiles which use a mix of certain audio optimization tools (AOT) and result in different compression levels and different computation costs. The following AOTs can be applied:

• AAC-LC: Low Complexity AAC (1.5 bits per sample)
• HE-AAC Dualband SBR: High-Efficiency AAC with dualband Spectral Band Replication (0.625 bits per sample)
• HE-AAC Downsampled SBR: High-Efficiency AAC with downsampled Spectral Band Replication (1.125 bits per sample)
• HE-AAC v2: HE-AAC with Parametric Stereo (0.5 bits per sample)

The encoder block itself picks the most appropriate encoding profile. The default profile is AAC-LC and for extremely low audio bit rates it switches to  Parametric Stereo or SBR for stereo or mono mode, respectively.

Contrary to the mp2 encoder, the mp4 encoder cannot be tested by an audio player because it uses a special DAB bit stream syntax. A loopback test against my mp4 decoder passed. This validates the encoder, because I already tested the decoder against reference data of the SWR ensemble “over the air”.

DAB+ live reception

Until now I always worked with recorded reference data and did all my tests with them. So I thought it would be time to actually do a live reception. I therefore created a python script for DAB+ reception with an USRP. It is only a prototype to test a live reception and does not aim to be user-friendly due to the fact that I am going to write a user-friendly GUI after all in the next weeks. The test went pretty well, I got a smooth audio stream!

In some cases, I got burst errors. These error bursts which aren’t necessarily correctable lead to a gap in the audio stream. In my current implementation, when the firecode or the Reed Solomon check fail, the superframe (= 120 ms audio) is dumped and the decoder immediately takes the next superframe to produce the next PCM samples without making a break. The current receiver, as is, kind of redoubles the time in which the audio stream is faulty:

1. The erroneous and cut out frames results in a choppy audio stream and this is very annoying for the listener because the brokenly audio stream replaces the beginning of the next bar and therefore destroys the rhythm completely.
2. Due to the dumped frame, a time asynchronicity is produced that finally ends up in an buffer underflow of the sound driver which is finally leading to stuttering audio.

I will stick with this solution right now, but I am adding the issue to a list of “nice to have” improvements that I am going to challenge after GSoC.

Outlook

After I completed my milestones for the second evaluation period, I can now start with the GUI. In contrast to my proposal plans and after discussing with my mentors, I am going to use pyQt4 instead of pyQt5 to avoid any issues with python3 and GNU Radio. I am going to start with the user interface which is going to be a simple (but nice) front end for DAB/DAB+ transmission and reception. In a second step I am planning to add a developer interface that is including lots of cool plots and measurements for geeks.

 

Luca