about G729 framing details

HI, all

I have a question on G729 framing details

I used a G729 codec to encode a .wav file

before encoding, it is about 300 KB
after encoding using G729 without VAD , the encoded G729 file is still about 300 KB, why isn’t there any compression on bytes?

after encoding using G729 with VAD, the encoded file is about 250KB, only 50 KB smaller?

Besides, according to a post, the first word(two bytes) in the G729 file is 0x6b21, what does this mean?

and the second word is

  1. 0x10 this means SID, and it means there are 16 words in each 10 ms frame
  2. 0x50 this means VAD on,and it means there are 80 words in each 10 ms frame
  3. 0 this means VAD off

so I’m very confused, my questions are

  1. whether I encoded with VAD no without VAD, I noticed the second words are always 0x50, what is the reason?

  2. I know that in a 10 milli-second G711 frame, there are 80 bytes. However, here in G729, the number of bytes are either 32(16 words) or 160(80 words) in a 10 ms frame, it seems to me the G729 compression is worse than G711???

  3. when the second word is 0, what does it mean?

  4. what does 0x6b21 mean

  5. why the size of the G729 file is nearly the same as the .wav files


I don’t know that much about these formats, but I do understand bitrates and their relationship to file size.

Bitrate is kilo_bits_ per second, and (as you probably know) there are 8 bits in a byte. If you know the bitrate and the playing-time, you can calculate (or estimate) file size. Wikipedia says G.729 is 8 or 6.4kbps. Does that agree with your information?

What’s the playing time of your clip? If my calculations are correct… And please double-check this… 300kB @ 8kbps should give you about 5 minutes of audio.

What’s the bit-depth and sample rate (kHz) of your WAV file (I assume it’s 1-channel mono). From this information you can calculate the bitrate of the original WAV.

thanks for your information
but I think this information is not to my point, thanks though

You may be trying to achieve heroic compression and bitrate reductions using too small a sample. Modern compression algorithms work by comparing portions of the show to redundant portions so both need not be sent. There are far fewer opportunities to do that in a short clip than a much longer one.

There is another fuzzy rule that modern compression techniques are aggressively front-loaded. You know the H.264 and MPEG4 compressors are doing their job when they take all night to produce a highly compressed, high-quality half-hour show. So if your job is over in a fraction of a second, the tools may be broken or something else may be wrong.

Also a side note, the newer tools also screw up the timer functions. “Expected Time To Completion” starts out deceasing nicely at the beginning of the compression job, and then slows dramatically as the comparison modules kick in. More than one editor has left for lunch confident that the fifteen minute compression job would be done when they got back. An hour later, it’s at 13 minutes and getting slower.

The up side of that process is a perfect-appearing show in a small fraction of the bits.


thank you for your post, but it is a bit abstract form me
Can you help explain the questions I listed in the post?

Isn’t it 80 bits?

You may be more likely to find someone that can answer you questions on Asterisk G.729 Google group.