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
0x10 this means SID, and it means there are 16 words in each 10 ms frame
0x50 this means VAD on,and it means there are 80 words in each 10 ms frame
0 this means VAD off
so I’m very confused, my questions are
whether I encoded with VAD no without VAD, I noticed the second words are always 0x50, what is the reason?
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???
when the second word is 0, what does it mean?
what does 0x6b21 mean
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.
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.