GSM-FR

[rporter]

I'm looking to use the IPP library to implement a GSM-FR encoder and decoder. Someone had cached a copy of the GSM-FR sample code (w_ipp-speech-coding-samples_p_4.0.002.zip). Is there a newer version of the sample code? Perhaps one targeted forLinux? I could be persuaded to use the GSM-AMR sample code, if it is just a simple configuration change.

The above sample GSM-FR code does not seem to work for me! When I encode an all zero input (with VAD disabled), the lower nibble of the first byte of output is 0x8, instead of the 0xD the spec says it should be. The decoder also checks this, and tells me to discard the frame...

Thanks,

Rick

[rporter]

I mispoke, the upper nibble of the first byte should be 0xD, and I get 0x0 from the encoder.

[rporter]

I got around the problem by adding the 0xD to the upper nibble of the first byte. With that, I am able to use the IPP code to pass some basic tests (e.g. tone in equals tone out).

[Vladimir_Dudnik]

Hi, there is updated version of Speech coding samples in IPP v4.1, please check IPP webpage for details

Regards,
Vladimir

[Vyacheslav_Baranniko]

The IPP GSMFR codec produces pure 260 bit frame. '0d' nibbleis to be added ahead of each framefor RTP, see for example,TS 101 318 V1.1.1 (1998-08),clause 5.1:

The GSM full rate codec has frame length of 260 bits. In the canonical encoding used for RTP, the bits are packed beginning from the most significant bit. Every frame is coded into one 33 octet (264 bit) buffer. Every such buffer begins with a 4 bit magic value or signature (0xD, binary 1101), followed by the MSB encoding of the fields of the frame.

[telefonie]

Yes,vbaranniist right for normal GSMFR (GSM 6.10),

as an addition: MS GSM 6.10 use another RTP-format.

They dont uses magic bits andconcatenate to frames. So they get 65 octeds for 2 frames (every frame has 32,5 octeds).

Microsoft does its own way. Unfortually the dont reveal its modifications.

Message Edited by telefonie on 10-13-2005 02:44 AM