Week 07 – Audio decoding

Audio decoding

The implementation of the audio decoding splits into two tasks:

• MPEG 1/2 Audio Layer II decoding for DAB audio frames
• MPEG 4 HE-AAC v2 decoding (with additional firecode check and Reed Solomon error repair with included interleaving) for DAB+ audio frames

MPEG 1/2 Audio Layer II

The MPEG 1/2 coding standard is a lossy audio data compression. The principle of the system is described in figure 1.

Figure 1: Block diagram of DAB audio coding

Summarized, the codec uses a psychoacoustic model of the human ear. It applies a superior quantization of those sub-band samples that are allocated in frequency ranges for which the ear is more sensitive to and coarse quantization for more insensitive ones.

For implementation, I used kjmp2 which is a minimal MPEG-1/2 Audio Layer II decoder library from Martin J. Fiedler. No additional error correction as for DAB+ is applied and therefore the DAB audio frame (= logical frame) matches with an MPEG audio frame:

Figure 2: MPEG and DAB frames

The ancillary data field of MPEG 2 is used for Programme Associated Data (PAD) which contains audio related data.

I implemented an mp2_decode block which decodes the DAB audio frames to PCM (Pulse Coded Modulation) frames. Unfortunately all the DAB services in my area are DAB+ and therefore not coded with MPEG 2 but MPEG 4. I won’t be able to test my block, until I created the according MPEG 2 encoder or got any validation data from a transmitting DAB service.

The problem with vectors

Most existing blocks of gr-dab have vector inputs and outputs. This seems reasonable because all the transport mechanisms of DAB are actually based on vectors, for example a Fast Information Block or a convolutional codeword. But when it comes to long frames like a logical frame, a Common Interleaved Frame or even a whole transmission frame, the vector passing between blocks gets a little problematic. A vector summarizes its containing elements to one item and this gets kind of a big problem especially when the vector length is not a power of 2. The gr buffer tries to allocate a certain number of items, vectors in this case, and finally needs to get a power of 2 bytes due to his binary nature. The buffer increases the number of items until he gets to a power of two bytes. This total length can get extremely huge and can lead to a performance bottleneck in the flowgraph. Because the DAB transceiver should be a live running system, these performance losses must be avoided. I already started to reimplement some blocks and am going to continue this work in the next weeks. The output and input streams therefore change from vectors to single bytes/floats/complex. A frame is kept together by setting the number of output items to a multiple of the frame length ( = former vector length).

Outlook

I am planning to create the MPEG 4 AAC v2 decoder next week. I already began with the implementation but issues occurred that I have to solve in the following week.

 

Luca