Speech Coding Samples

[napoleon9th]

Why do the G.711 coder's and decoder's source files reference a different api?!? They both have the following preprocessor directive:

#include "g729api.h"

Also, a number of lines later, the G.711 coder uses the "apiG729EncodeVAD" function, while no corresponding "apiG711EncodeVAD" function is defined in g711api.h... This is almost the only place where replacing 729 with 711 is not possible. What's the idea about that?!?

Message Edited by Napoleon9th on 11-02-2005 05:36 AM

[Vyacheslav_Baranniko]

Hi

I think the latest IPP 5.0 speech-coding samplesresolves most of theseissues.Now USC interface is uniformly implemented accross all speech codecs enabled in IPP.

Vyacheslav

[napoleon9th]

For what it's worth, i AM talking about the latest speech-coding samples... (The ones with the USC interface) I am just trying to make sense out of the fact that the G.711 USC implementation uses functions from G.729, considering that (iirc) G.711 cannot use VAD. :|

[napoleon9th]

And another issue. Why does your USC implementation require the USCDecoderPreProcessFrame function, thus adding 6 bytes of redundant information to each frame?!?

[Igor_B_Intel1]

Hi,

Our inplementation of G711 codec conforms to ITU G.711/G.711.I/G.711.II standards and able to detect VAD, do PLC. It uses VAD module from G729 codecs. Thats why it requests VAD functions from G729. So the length of input frame is 10 ms. To use pure G711 codec you have to disable VAD. But using G711 code with VAD turned on can significantly reduce size of sended data in RT conversation.

As for additional 6 bytes:

The header of the USC file format is similar to the header of WAVE file format for non-PCM data. Bitstream frames are consecutively stored in data section of the USC file. Each bitstream frame is stored with small header followed by the bitstream data.
A header comprises of six octets: first three octets represent bitrate in bps, the second octet represents frame type and latter two octets contain the pure bitstream data length, not including the header length. The bitsrteam data follows after the header. In some cases, depending on the silence compression scheme used, the codec can produce an empty bitstream and so a frame header with zero data length is created.

Function USCDecoderPreProcessFrame reads this 6 bytes to fill the fields in "USC_Bitsream *in" structure.

Of course, it depends on using USC file format. If you doesn't usethis format you won't have to waste 6 bytes.

Igor S. Belyakov

[napoleon9th]

Thanks for the detailed answers. :)