mpf_codec_encode and mpf_codec_decode returning different values for LPCM codec

[Google Code Exporter]

This "bug" is based on the premise that encoding and decoding speech using the 
LPCM codec should make no change to the speech signal whatsoever (if this 
assumption is incorrect, this is not a bug). In other words, one would expect 
that after mpf_codec_encode(encoder->codec,A,B) and 
mpf_codec_decode(encoder->codec,B,C), the content of A should be identical to 
the content in C. This is not the case though.


What version of the product are you using? On what operating system?

URL: https://unimrcp.googlecode.com/svn/trunk
Repository Root: https://unimrcp.googlecode.com/svn
Repository UUID: f001bc3a-424a-0410-80a0-a715b8f413a8
Revision: 1996
Last Changed Rev: 1988
Last Changed Date: 2013-05-23 20:11:15 +0200 (Thu, 23 May 2013)

URL: https://unimrcp.googlecode.com/svn/solutions/asterisk-unimrcp
Repository Root: https://unimrcp.googlecode.com/svn
Repository UUID: f001bc3a-424a-0410-80a0-a715b8f413a8
Revision: 1996
Last Changed Rev: 1995
Last Changed Date: 2013-05-29 23:28:52 +0200 (Wed, 29 May 2013)

Red Hat Enterprise 5.5


To reproduce this bug:

- in libs/mpf/src/mpf_encoder.c, modify the mpf_encoder_process to print out 
the frame before encoding. Decode the encoded frame and print the frame out 
again 
(mpf_codec_decode(encoder->codec,&encoder->frame_out.codec_frame,&frame->codec_f
rame);). Some samples differ slightly.

E.g.

mpf_codec_encode(encoder->codec,&frame->codec_frame,&encoder->frame_out.codec_fr
ame)
...
       int i = 0;
       for (; i < frame->codec_frame.size; i+=2) {
         int16_t *k = (int16_t*)(frame->codec_frame.buffer + i);
         printf("%d ",*k);
       }
       printf("\n");
...
       mpf_codec_decode(encoder->codec,&encoder->frame_out.codec_frame,&frame->codec_frame)
...
       i = 0;
       for (; i < frame->codec_frame.size; i+=2) {
         int16_t *k = (int16_t*)(frame->codec_frame.buffer + i);
         printf("%d ",*k);
       }
       printf("\n");
...

for one frame gives the following output:
before: -5 -1 -1 0 1 -1 0 0 0 0 -8 -15 -15 -24 -15 -8 8 16 40 48 64 72 80 80 80 
73 48 48 41 31 40 48 48 72 104 132 196 228 292 340 396 460 492 524 556 556 556 
556 524 460 396 308 228 132 48 -40 -132 -212 -292 -356 -428 -492 -556 -620 -684 
-748 -812 -924 -988 -1052 -1116 -1180 -1180 -1180 -1180 -1116 -1052 -988 -924 
-812

after:  -8  0  0 0 0  0 0 0 0 0 -8 -16 -16 -24 -16 -8 8 16 40 48 64 72 80 80 80 
72 48 48 40 32 40 48 48 72 104 132 196 228 292 340 396 460 492 524 556 556 556 
556 524 460 396 308 228 132 48 -40 -132 -212 -292 -356 -428 -492 -556 -620 -684 
-748 -812 -924 -988 -1052 -1116 -1180 -1180 -1180 -1180 -1116 -1052 -988 -924 
-812

Original issue reported on code.google.com by [e-mail] on 14 Aug 2013 at 11:14

[Google Code Exporter]

I suppose the issue can be closed now.

Original comment by [e-mail] on 5 Sep 2014 at 2:37

• Changed state: Verified

[Google Code Exporter]

Hi Derik,

Thanks for the detailed description. 

If you meant the G.711 codec, then it's not completely lossless. The deference 
you experienced is more or less normal. In r2002, though, I have patched the 
current implementation of the G.711 algorithm to make it bit-exact with ITU-T 
reference implementation.

Original comment by [e-mail] on 26 Sep 2013 at 1:40