6.2.1.  Overload point

The overload point within the digital domain is defined by the (normalized) amplitude value.

How this overload point relates to the analogue world depends on the conversion method between the analog and digital domains, and is beyond the scope of this document. All signals in this manual are relative to this overload point in the digital domain.

1. In floating-point (either single or double precision) implemntations, the representation of this value is exact. In this text, and also in the tools, this data type is called float.

2. In 32 bit 2's complement representation the data can be represented by multiplying the normalized value by 2³¹. For example, the largest possible positive value is represented by 0x7FFFFFFF. The largest negative value is represented by 0x80000000. In this text, and also in the tools, this data type is called long.

3. In 16 bit 2's complement representation the data can be represented by multiplying the normalized value by 2¹⁵. For example, the largest possible positive value is represented by 0x7FFF. The largest negative value is represented by 0x8000. In this text, and also in the tools, this data type is called short.

4. The statements above may be generalized for all wordlengths in fixed-point representation. The idea is to set the decimal point just after the MSb (sign bit).

6.2.2.  Signal power

The power of a signal x(n) with a length of N samples is defined by

A signal which does not contain amplitude values exceeding the overload point can have a maximum signal power of 1.0. This is the power of a DC signal with an amplitude of 1.0 or of any other signal comprising only the values $\pm 1.0$ (e.g., a square wave signal).

6.2.3.  Signal level

The power level in decibels is defined relative to a reference power level $P_0=1.0$:

The level of a signal power $P=1.0$ is thus 0 dBov (where the characters "ov" arbitrarily mean digital overload signal level), which is chosen to be the reference level. A signal with such power level could be either (a) a sequence of maximum positive numbers $(+1)$, (b) a sequence of maximum negative numbers $(-1)$, or (‌c) a rectangular function exercising only the positive or negative maximum numbers $(\pm 1)$. The level of a sinewave with an amplitude (peak value) of 1.0 is therefore $L=-3.01$ dBov.

6.2.4.  Relation between overload and maximum levels

The measurement of signal levels in the digital part of the network is normally expressed by telecommunications engineers as $y$ dBm0, i.e., the level relative to 1 mW in 600 $\Omega$. However, from the software point of view, it is more convenient to represent levels relative to the maximum power that can be stored in integer format on a computer, e.g. $z$ dBov. A conversion between both representations can be expressed as:

For the G.711 encoding rule, a sinewave which exercises the maximum level has a power $Tmax$ of 3.14 dBm0 for A-law, and of 3.17 dBm0 for $\mu$-law. On the other hand, the RMS level of these sinewaves would always be -3.01 dBov. Therefore, $C$ above becomes 6.15 dB for A-law and 6.18 dB for $\mu$-law. For the G.722 wideband coding algorithm, the overload point of the A/D and D/A converters should be 9 dBm0. Therefore, in that case, C becomes 12.01 dB.

The following relationships summarize the discussion:

6.2.5.  Saturation

Saturation is the limitation of signal amplitudes to values equal to or smaller than the overload point:

6.2.6.  Data representation

Unless otherwise noted all waveforms within the signal processing are assumed to have infinite precision and unlimited amplitude. The overload point is therefore the reference point only. In practice these signals may well be represented in 32 bit floating-point arithmetic or high precision integer arithmetic (24 bit for data and coefficients, 48 to 56 bit for products and accumulation). In most cases, 16 or 32 bit integer arithmetic is not precise enough.

Signals derived from 16 bit 2's complement representation (DAT, files, digital I/O interface) should be converted to this (approximately) infinite precision before processing by modules that require floating-point input. Normalization of the floating-point values to the overload point is recommended.

6.2.7.  Data justification

Justification of data here is used without distinction to data alignment and data adjustment: where the upper or lower significant bit of an integer sample is located.

Left-justified data are samples whose most significant bit is located at the leftmost position of the computer storage unit used for it. Remaining low-bit positions must be set to zero.

Right-justified data are samples whose least significant bit is located at the rightmost position of the computer storage unit used for it. Remaining upper bits depend on the data representation: if two's complement, sign extension from sample's MSb to storage's MSb is needed; otherwise, the upper (unused) bits shall be zeroes.

As an example, suppose a 12-bit resolution, two's complement sample, to be stored for processing in a short. If left-justified, then a sign bit (the MSb!) is found in bit 15 (the MSb) of the short that stores it. On the other hand, if right-justified, the LSb will be the bit 0 of the short, in this case. If it is a negative number, there would be sign extension for bit 12 to 15. If it is an unsigned number, the upper 4 bits (in the example) are all zeros. Example illustrates these three cases.

6.2.8.  Equivalent results

Several software tools, such as the G.711 algorithm, are defined in terms of precise fixed-point operations. Therefore, when comparing the output of one of these algorithms on different platforms, or for compilation using different C compilers, one should expect identical sample values for reference processed materials.

Other algorithms, however, may include highly intensive processing, or complex mathematical functions. Examples of these are rate change filters and floating-point arithmetic speech coders, such as the 16 kbit/s LD-CELP of ITU-T Rec. G.728. In such cases, it is expected that the processing of the same reference material on different platforms will generate almost identical results. The generated files will probably be identical for most of the samples,and for some samples they will differ by a small amount, e.g. $\pm 1$, or more rarely by $\pm 2$ or more. For the purposes of the STL, such an implementation is said to produce equivalent results on different platforms.

6.2.9.  Little- and big-endian data ordering

Present computer systems agree only on the data access for byte-oriented data structures. Although computer systems exist whose bytes do not have 8-bits, the majority of the systems implement bytes as 8-bit data structures. In general, the computer architectures do not differ in the way they access the bit-order within a byte. In other words, for the vast majority of the computer systems existing today, the least significant bit occupies the lower memory position (i.e., bit 0), and the most significant bit occupies the higher memory position in the byte (i.e., bit 7). In terms of C operations, if b is a byte structure, then b&0x1 returns the LSb, and (b>>7)&0x1 returns the MSb.

Although most computer architectures agree on the definition of a byte and how its bits are accessed, they vastly differ on how multi-byte structures are accessed. Trivial examples of multi-byte structures are 16-bit short words or 32-bit long words. There are currently two access means currently implemented by different CPUs in the market, which differ on the significance of the bytes that are first read from memory positions.

On the so-called big-endian systems, the first byte read from a multi-byte structure is always the most significant byte. For example, if the two bytes 0x12 (low address) and 0x34 (high address) are stored in two consecutive memory addresses, then the number read and stored in the CPU accumulator would be 0x3412, or 13330 in decimal. The big-endian data organization is, for this reason, also known as high-byte first.

For the so-called little-endian systems, the first byte read from a multi-byte structure is always the least significant byte. For this reason, the little-endian data organization is also known as low-byte first. Using the same example as before, for the two consecutive bytes in memory 0x12 and 0x34, the value loaded on a little-endian CPU will be 0x1234, or 4660 in decimal.

The concept is extended to other multi-byte data structures, such as 32-bit or 64-bit integers. For example, the consecutive bytes 0x12, 0x34, 0x56, and 0x78 would be loaded as the 32-bit integer 0x78563412 on the accumulator of a big-endian CPU and as 0x12345678 on the accumulator of a little-endian CPU.

Table 1 — Example of big- and little-endian systems

Table 1 indicates the data organization for several computer platforms. It should be noted that the data organization is a function of the CPU family rather than of the operating system used. For example, Solaris on Sparc platforms uses big-endian data organization, while Solaris on Intel 80x86/Pentium platforms uses little-endian data organization. Similarly, most Linux systems are little-endian (because they run on Intel 80x86/Pentium CPUs), but several other implementations are actually big-endian (e.g. PowerPC CPU used in Macintosh machines).

The segment of C code in Figure 1 can be used to determine whether a given computer system has big- or little-endian data organization.

#include <stdio.h>
#include <string.h>

int is_little_endian()
{
  /* Hex version of the string ABCD */
  unsigned long tmp = 0x41424344;

  /* Compare the hex version of the four characters with the ASCII version */
  /* On big-endian (or high-byte-first) systems, 0x41 ('A' in ASCII) */
  /* is stored in the first memory position, and the equivalent string */
  /* is "ABCD". On a little-endian (or low-byte-first) system, 0x41 is */
  /* stored in the last position, and the equivalent string will be */
  /* "DCBA". Function strncmp will return 0 if both strings are equal */
  /*  upto the first four characters. */
  return(strncmp("ABCD", (char *)&#x26;tmp, 4));
}

void main()
{
  printf("System is %s-endian\n", is_little_endian()? "little" : "big");
}

Figure 1 — Sample code for determination of byte organization

The approach above determines whether a platform is big- or little-endian, but it does not answer the question of what is the byte orientation in a given file. Although there is no closed-form method for such a determination, there is an empirical method that can be carefully used for speech signals (usually represented using 16-bit linear PCM words) based on two speech properties: speech signals follow a gamma distribution (hence most of the samples have small amplitude), and levels in voiced segments are usually in the -15 dBov through -40 dBov range. For files that have a byte orientation mismatching that of the computer platform, the mostly small samples of the speech signal will be measured as having large amplitude. Hence, if a high-level power is found when measuring the power of a voiced segment (typically around -4 dBov), one can assume that the file needs to be byte-swapped. It is important however to measure the level for voiced segments, since for silent intervals the increase in gain is not so dramatic and will not allow for a conclusion on the byte-orientation of the file.

When the change of format is necessary for short and long data, the operations in Figure 2 should be used. The conversion between big- and little-endian data representation for 16-bit data is simple and is known as byte swapping. The byte swapping operation can be implemented in several fashions. For example,

short swap_one_short(short in)
{
  return (((in>>8)&0xFF) | (in<<8));
}

Figure 2-a — Conversion between little− and big−endian for 32−bit data

Figure 2-b — Conversion between little− and big−endian for 16−bit data

Figure 2 — Conversion between big- and little-endian

It should be noted that the simple byte-swapping above does not work properly for conversion of other multi-byte structures. For the purposes of the STL, however, 16-bit structures is the most import case. For several of the STL modules, the provided test files in general need to be byte swapped in one or another computer platform. The documentation and the "manifesto" accompaining each software tool module describe which files, if any, should be byte-swapped on certain platforms. As default, binary files organized in 16-bit words are provided in big endian format in the STL distribution.

7.2.1.  alaw_compress and ulaw_compress

Syntax:

#include "g711.h"
void alaw_compress (long _smpno_, short _*lin_buf_, short _*log_buf_)
void ulaw_compress (long _smpno_, short _*lin_buf_, short _*log_buf_)

Prototype: g711.h

Description:

alaw_compress performs A law encoding rule according to Recommendation ITU-T G.711, and ulaw_compress does the same for $\mu$ law. Note that input samples shall be left-justified, and that the output samples are right-justified with 8 bits.

Variables:

smpno

Is the number of samples in lin_buf.

lin_buf

Is the input samples' buffer; each short sample shall contain linear PCM (2's complement, 16-bit wide) samples, left-justified.

log_buf

Is the output samples' buffer; each short sample will contain right-justified 8-bit wide valid A or $\mu$ law samples.

Return value: None.

7.2.2.  alaw_expand and ulaw_expand

Syntax:

#include "g711.h"
void alaw_expand (long _smpno_, short _*log_buf_, short _*lin_buf_)
void alaw_expand (long _smpno_, short _*log_buf_, short _*lin_buf_)

Prototype: g711.h

Description:

alaw_expand performs A law decoding rule according to Recommendation ITU-T G.711, and ulaw_expand does the same for $\mu$ law. Note that output samples will be left-justified, and that the input samples shall be right-justified with 8 bits.

Variables:

smpno

Is the number of samples in log_buf.

log_buf

Is the input samples' buffer; each short sample shall contain right-justified 8-bit wide valid A or $\mu$ law samples.

lin_buf

Is the output samples' buffer; each short sample will contain linear PCM (2's complement, 16-bit wide) samples, left-justified.

Return value: None.

7.4.1.  Description of the demonstration program

One program is provided as demonstration program for the G.711 module, g711demo.c.

Program g711demo.c accepts input files in 16-bit linear PCM format for compression operation and produces files in the same format after the expansion operation. The compressed signal will be in 16-bit, right adjusted format, according to the logarithmic law specified by the user. Three operations are possible: linear in, linear out (lili) linear in, logarithmic out (lilo), or logarithmic in, linear out (loli).

7.4.2.  Simple example

The following C code gives an example of companding using either the A- or $\mu$-law functions available in the STL.

#include <stdio.h>
#include "ugstdemo.h"
#include "g711.h"

#define BLK_LEN 256
#define QUIT(m,code) {fprintf(stderr,m); exit((int)code);}

main(argc, argv)
  int             argc;
  char           *argv[];
{
  char            law[4];

  char            FileIn[180], FileOut[180];
  short           tmp_buf[BLK_LEN], inp_buf[BLK_LEN], out_buf[BLK_LEN];
  FILE           *Fi, *Fo;
  void          (*compress)(), (*expand)(); /* pointer to a function */

  /* Get parameters for processing */
  GET_PAR_S(1, "_Law (A,u): ................... ", law);
  GET_PAR_S(2, "_Input File: .................. ", FileIn);
  GET_PAR_S(3, "_Output File: ................. ", FileOut);

  /* Opening input and output LOG-PCM files */
  Fi = fopen(FileIn, RB);
  Fo = fopen(FileOut, WB);

  /* Choose compression/expansion routinies according to the law */
  if (toupper(law[0])=='A')
  {
     compress = alaw_compress;
     expand = alaw_expand;
  }
  else if (tolower(law[0])=='u')
  {
     compress = ulaw_compress;
     expand = ulaw_expand;
  }
  else
    QUIT("Bad law chosen!\n",1);

 /* File processing */
  while (fread(inp_buf, BLK_LEN, sizeof(short), Fi) == BLK_LEN)
  {
    /* Process input linear PCM samples in blocks of length BLK_LEN */
    compress(BLK_LEN, inp_buf, tmp_buf);

    /* Process log-PCM samples in blocks of length BLK_LEN */
    expand(BLK_LEN, tmp_buf, out_buf);

    /* Write PCM output word */
    fwrite(out_buf, BLK_LEN, BLK_LEN, sizeof(short), Fo);
  }

  /* Close input and output files */
  fclose(Fi);
  fclose(Fo);
  return 0;
}

8.3.1.  Introduction

The g711iplc directory contains an ANSI C implementation of the G.711 Appendix I PLC algorithm. The C++ version of this algorithm is in the g711iplc\cpp_cod directory. Sample test programs read lost frame patterns in G.192 file format and apply the PLC algorithm to audio files. The software in the g711iplc directory is covered by a more restrictive copyright than the STL. See the copyrght.txt file for details.

8.3.2.  PLC Algorithm Implementation

A detailed line by line description of the C++ code can be found in section I.3 "Algorithm description with annotated C\+ code" of G.711 Appendix I <<G711-appendix-I>> and will not be repeated here. The public interface functions that are called by applications are covered. The C+ version is in the g711iplc\cpp_code directory (files lowcfe.h and lowcfe.cc). The ANSI C version, contained in the files lowcfe.h and lowcfe.c, is a translation of the C\+ code to C. The interface functions are the same for both versions, with the exception that the C versions of the routines take an extra argument for the data structure that is implicitly passed to C+ member functions in the class instance data. As for other STL modules, only the ANSI C version is compiled during STL2005 building.

#include "lowcfe.h"
LowcFE  _lc_; // No argument constructor

#include "lowcfe_c.h"
g711plc_construct(_LowcFE_c*_); /* explicit constructor call */

void LowcFE::addtohistory(short _s_); /* add a frame to the history buffer */

void g711plc_addtohistory(_LowcFE_c*_, short _*s_);

void LowcFE::dofe(short _*s)_;    /* synthesize speech during loss */

void g711plc_dofe(_LowcFE_c*_, short _*s_);

#include "error.h"
void error(char _*s_, ...);

#include "plcferio.h"
void readplcmask open(readplcmask _*r_, char _*fname_);

#include "plcferio.h"
int readplcmask erased(readplcmask _*r_);

#include "plcferio.h"
void readplcmask close(readplcmask _*r_)

8.3.3.  Test Program

  g711iplc mask.g192 input.raw output.raw

    0x6B21 0x6B21 0x6B21 0x6B21 0x6B21,
    0x6B21 0x6B21 0x6B21 0x6B21 0x6B20

    0x6B21 0x6B21 0x6B21 0x6B21 0x6B21,
    0x6B21 0x6B21 0x6B21 0x6B21 0x6B21,
    0x6B21 0x6B21 0x6B21 0x6B21 0x6B21,
    0x6B21 0x6B21 0x6B21 0x6B20 0x6B20

  g711iplc -noplc mask.g192 input.raw output.raw

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include "error.h"
#include "plcferio.h"
#include "lowcfe.h"

int main(int argc, char *argv[]) {
    FILE        *fi;        /* input file */
    FILE        *fo;        /* output file */
    LowcFE      fesim;      /* PLC simulation class */
    readplcmask mask;       /* error pattern file reader */
    short       s[FRAMESZ]; /* i/o buffer */

    argc--; argv++;
    if (argc != 3)
        error("Usage: g711iplc plcpattern speechin speechout");
    readplcmask_open(&#x26;mask, argv[0]);
    if ((fi = fopen(argv[1], "rb")) == NULL)
        error("Can't open input file: %s", argv[1]);
    if ((fo = fopen(argv[2], "wb")) == NULL)
        error("Can't open output file: %s", argv[2]);
    while (fread(s, sizeof(short), FRAMESZ, fi) == FRAMESZ) {
        if (readplcmask_erased(&mask))
            fesim.dofe(s);      /* lost frame */
        else
            fesim.addtohistory(s);  /* received frame */
        fwrite(s, sizeof(short), FRAMESZ, fo);
    }
    fclose(fo);
    fclose(fi);
    readplcmask_close(&#x26;mask);
    return 0;
}

8.3.4.  Loss Pattern Conversion Utility

The PLC directory includes a tool, asc2g192, for converting ASCII loss pattern files containing sequences of 0s and 1s into G.192 format pattern files. In ASCII loss pattern files, a "1" represents a lost frame and a "0" represents a received frame. For example, to create a 10% uniform loss pattern with each loss being 10ms, use a text editor to create a text file called fe10.txt:

  0000000001

Then, convert it to the G.192 format for use by the g711iplc program with the following command:

  asc2g192 fe10.txt fe10.g192

Similarly, to create a 10% uniform loss pattern with each loss being 20ms (2 frames for each loss), create the text file fe10_2.txt:

  00000000000000000011

Then convert it to the G.192 format with:

  asc2g192 fe10_2.txt fe10_2.g192

The asc2g192 conversion program ignores new lines and carriage returns in the input file so the patterns can span multiple lines.

9.1.1.  PCM format conversion

The input signal $s\left(k\right)$, in either A- or $\mu$-law format, must be converted into linear samples. This expansion is accomplished using the same algorithm in G.711 [20], but converting from signed magnitude to 14-bit two's complement samples.

9.1.2.  Difference Signal Computation

This block simply calculates the difference between the (expanded) input signal and the estimated signal:

9.1.3.  Adaptive Quantizer

A 15-level, non-uniform adaptive quantizer is used to quantize the difference signal. Before the quantization, this signal is converted to a logarithmic representation⁷ and scaled by a factor ($y\left(k\right)$), that is computed in the scale factor adaptation block (see below).

The output of this block is $I\left(k\right)$, and it is used twice; first, is the ADPCM coded (quantized) sample; second, is the input to the backward part of the G.721 algorithm, to provide information for quantization of the next samples. One relevant point to notice here is that the backward adaptation is done using the quantized sample. If one starts the decoder from this very point, one will find identical behaviour. That is why only the quantized samples are needed in the decoder (i.e., no side information).

9.1.4.  Inverse Adaptive Quantizer

The inverse adaptive quantizer takes the signal $I\left(k\right)$ and converts it back to the linear domain, generating a quantized version of the difference signal, $d_q\left(k\right)$. This is the input to the adaptive predictor, such that the estimated signal is based on a quantized version of the difference signal, instead of on the unquantized (original) one.

9.1.5.  Quantizer Scale Factor Adaptation

This block computes $y\left(k\right)$, the factor used in the adaptive quantizer and inverse quantizer for domain conversion. As input, this block needs $I\left(k\right)$, but also $a_l\left(k\right)$, the adaptation speed control parameter. The reason for the latter is that the scaling algorithm has two modes (bimodal adaptation), one fast, another slow. This has been done to accomodate signals that in nature produce difference signals with large fluctuations (e.g. speech) and small fluctuations (e.g. tones and voice-band data), respectively.

This block computes two scale factor (fast, $y_u\left(k\right)$, and slow, $y_l\left(k\right)$) based on $I\left(k\right)$, which combined using $a_l\left(k\right)$ produce $y\left(k\right)$.

9.1.6.  Adaptation Speed Control

This block evaluates the parameter $a_l\left(k\right)$, which can be seen as a proportion of the speed (fast or slow) of the input signal, and is in the range [$0,1$]. If 0, the data are considered to be slowly varying; if 1, they are considered to be fast varying.

To accomplish this, two measures of the average magnitude of $I\left(k\right)$ are computed ($d_{ms}\left(k\right)$ and $d_{ml}\left(k\right)$). These, in conjunction with delayed tone detect and transition detect flags ($t_d\left(k\right)$ and $t_r\left(k\right)$, calculated in the Tone Transition and Detector block), are used to evaluate $a_p\left(k\right)$, whose delayed version ($a_p\left(k-1\right)$) is used in the definition of $a_l\left(k\right)$, limiting the range to [$0,1$]⁸.

An analysis of $a_p\left(k\right)$ gives insight on the nature of the signal: if around the value of 2, this means that the average magnitude of $I\left(k\right)$ is changing, or that a tone has been detected, or that it is idle channel noise; on the other side, if near 0, the average magnitude of $I\left(k\right)$ remains relatively constant.

9.1.7.  Adaptive Predictor and Reconstructed Signal Calculator

The adaptive predictor has as its main function to compute the signal estimate based on the quantized difference signal, $d_q\left(k\right)$. It has 6 zeroes and 2 poles, structure that covers well the kind of input signals expected for the algorithm. With these coefficients, and past values of $d_q\left(k\right)$ and $s_e\left(k\right)$, the updated value for the signal estimate $s_e\left(k\right)$ is computed.

The two sets of coefficients (one for the pole section, $a_i\left(k\right),i=1..2$, other for the zero section, $b_i\left(k\right),i=1..6$) are updated using a simplified gradient algorithm. At this point, since a situation in which the poles cause instability may arise, the two pole coefficients $a_i$ have their ranges limited. In addition, if a transition from partial band signal is detected (signaled by $t_r\left(k\right)$), the predictor is reset (all coefficients are set to 0), remaining disabled until $t_r$ comes back to zero⁹.

The reconstructed signal $s_r\left(k\right)$ is calculated using the signal estimate $s_e\left(k\right)$ and the quantized difference signal $d_q\left(k\right)$.

9.1.8.  Tone Transition and Detector

This block is one of the changes from the Red Book version. It was added to improve algorithm performance for signals originating from FSK modems operating in the character mode. First, it checks if the signal has partial band (e.g., a tone) by looking at the predictor coefficient $a_2\left(k\right)$, that defines the signal $t_d\left(k\right)$. Second, a transition from partial band signal indicator $t_r\left(k\right)$ is set, such that predictor coefficients can be set to 0 and the quantizer can be forced into the fast mode of operation.

9.1.9.  Output PCM Format Conversion

This block is unique to the decoder. Its sole function is to compress the reconstructed signal $s_r\left(k\right)$, which is in linear PCM format, using A or $\mu$ law, and is a complement of the PCM format conversion block.

9.1.10.  Synchronous Coding Adjustment

This block is also unique to the decoder. It has been devised in order to prevent cumulative distortions occuring on synchronous tandem codings (ADPCM—​PCM—​ADPCM, etc., in purely digital connections, i.e., with no intermediate analog conversions), provided that:

• the transmission of the ADPCM and the intermediate PCM are error-free, and

• the ADPCM and the intermediate PCM are not disturbed by digital signal processing devices.

9.1.11.  Extension for linear input and output signals

An extension of the G.726 algorithm was carried out in 1994 to include, as an option, linear input and output signals. The specification for such linear interface is given in its Annex A [6].

This extension bypasses the PCM format conversion block for linear input signals, and both the Output PCM Format Conversion and the Synchronous Coding Adjustment blocks, for linear output signals. These linear versions of the input and output signals are 14-bit, 2's complement samples.

The effect of removing the PCM encoding and decoding is to decrease the coding degradation by 0.6 to 1 qdu, depending on the network configuration considered (presence or absence of a G.712 filtering).

Currently, this extension has not been incorporated in the STL.

9.2.1.  G726_encode

Syntax:

#include "g726.h"
void G726 encode (short _*inp_buf_, short _*out_buf_, long _smpno_, char
                  _*law_, short _rate_, short _reset_, G726_state _*state_)

Figure 3 — Packing of G.726-encoded signals (right-aligned, parallel format)

Prototype: g726.h

Description:

Simulation of the ITU-T G.726 ADPCM encoder. Takes the A or $\mu$ law input array of shorts inp_buf (16 bit, right-justified, without sign extension) with smpno samples, and saves the encoded samples in the array of shorts out_buf, with the same number of samples and right-justified. An example of the sample packing for the G.726 encoded bitstream is shown in Figure 3.

The state variables are saved in the structure state, and the reset can be stablished by making reset equal to 1. The law is A if law=='1', and mu law if law=='0'.

Variables:

inp_buf

Is the input samples' buffer; each short sample shall contain right-justified 8-bit wide valid A or $\mu$ law samples.

out_buf

Is the output samples' buffer; each short sample will contain right-justified 2-, 3-, 4-, or 5-bit wide G.726 ADPCM samples, depending on the rate used.

smpno

Is the number of samples in inp_buf.

law

Is a char indicating if the law for the input samples is A ('1') or $\mu$ ('0'). See note below.

rate

Is a short indicating the number of bits per sample to used by the algorithm: 5, 4, 3, or 2.

reset

Is the reset flag (see note below):

• 1: reset is to be applied in the variables;

• 0: processing is carried out without setting state variables to the reset state.

Please note that this should normally be done only in the first call to the routine in processing a sample stream.

state

The state variable structure; all the variables here are for internal use of the G.726 algorithm, and should not be changed by the user. Fields of this structure are described above.

Return value: None.

9.2.2.  G726_decode

Syntax:

#include "g726.h"
void G726 decode (short _*inp_buf_, short _*out_buf_, long _smpno_, char
                  _*law_, short _rate_, short _reset_, G726_state _*state_)

Prototype: g726.h

Description:

Simulation of the ITU-T G.726 ADPCM decoder. Takes the ADPCM input array of shorts inp_buf (16 bit, right-justified, without sign extension) of length smpno, and saves the decoded samples (A or $\mu$ law) in the array of shorts out_buf, with the same number of samples and right-justified.

The state variables are saved in the structure state, and the reset can be stablished by making reset equal to 1. The law is A if law=='1', and mu law if law=='0'.

Variables:

inp_buf

Is the input samples' buffer; each short sample will contain right-justified 2-, 3-, 4-, or 5-bit wide G.726 ADPCM samples.

out_buf

Is the output samples' buffer; each short sample shall contain right-justified 8-bit wide valid A or $\mu$ law samples.

smpno

Is the number of samples in inp_buf.

law

Is a char indicating if the law for the input samples is A ('1') or $\mu$ ('0'). See note below.

rate

Is a short indicating the number of bits per sample to used by the algorithm: 5, 4, 3, or 2.

reset

Is the reset flag (see note below):

• 1: reset is to be applied in the variables;

• 0: processing done without setting state variables to reset state.

Please note that this should normally be done only in the first call to the routine in processing a sample stream.

state

The state variable structure; all the variables here are for internal use of the G.721 algorithm, and should not be changed by the user. Fields of this structure are described above.

Return value: None.

9.4.1.  Description of the demonstration programs

Two programs are provided as demonstration programs for the G.726 module, g726demo.c and vbr-g726.c.

Program g726demo.c accepts input files in either 16-bit, right-justified A- or $\mu$-law format (as generated by g711demo.c) and encodes and/or decodes using one of the G.726 bit rates (16, 24, 32, or 40 kbit/s). Linear PCM files are not accepted by the program. Three operations are possible: logarithmic in, logarithmic out (lolo) logarithmic in, ADPCM out (load), or ADPCM in, logarithmic out (adlo).

Program vbr-g726.c can perform the same functions as g726demo.c, however it is capable of two additional features. It can perform in variable bit rate mode, which is switched at user-specified frame sizes (i.e. number of samples), and it can operate from 16-bit linear PCM input files. In the latter case, A-law is used to compand the linear signal prior to G.726 encoding, since G.726 Annex A [6] is not yet implemented in the STL.

9.4.2.  Simple example

The following C code gives an example of G.726 coding and decoding using as input speech previously encoded by either the A- or $\mu$-law functions available in the STL. The output samples will be encoded using the same law of the input signal.

#include <stdio.h>
#include "ugstdemo.h"
#include "g726.h"

#define BLK_LEN 256

void main(argc, argv)
  int             argc;
  char           *argv[];
{
  G726_state      encoder_state, decoder_state;
  char            law[4];
  short           bitrate, reset;
  char            FileIn[180], FileOut[180];
  short           tmp_buf[BLK_LEN], inp_buf[BLK_LEN], out_buf[BLK_LEN];
  FILE           *Fi, *Fo;

  /* Get parameters for processing */
  GET_PAR_S(1, "_Law: ......................... ", law);
  GET_PAR_I(2, "_Bit-rate: .................... ", bitrate);
  GET_PAR_S(2, "_Input File: .................. ", FileIn);
  GET_PAR_S(3, "_Output File: ................. ", FileOut);

  /* Opening input and output LOG-PCM files */
  Fi = fopen(FileIn, RB);
  Fo = fopen(FileOut, WB);

 /* File processing */
  reset = 1;                    /* set reset flag as YES */
  while (fread(inp_buf, BLK_LEN, sizeof(short), Fi) == BLK_LEN)
  {
    /* Process input log PCM samples in blocks of length BLK_LEN */
    G726_encode(inp_buf, tmp_buf, BLK_LEN, law, bitrate, reset, &#x26;encoder_state);

    /* Process ADPCM samples in blocks of length BLK_LEN */
    G726_decode(tmp_buf, out_buf, BLK_LEN, law, bitrate, reset, &#x26;decoder_state);

    /* Write PCM output word */
    fwrite(out_buf, BLK_LEN, sizeof(short), Fo);

    if (reset)
      reset = 0;                /* set reset flag as NOMORE */
  }

  /* Close input and output files */
  fclose(Fi);
  fclose(Fo);
}

10.1.1.  Extension for linear input and output signals

An extension of the G.727 algorithm was carried out in 1994 to include, as an option, linear input and output signals. The specification for such linear interface is given in its Annex A [7].

This extension bypasses the PCM format conversion block for linear input signals, and both the Output PCM Format Conversion and the Synchronous Coding Adjustment blocks, for linear output signals. These linear versions of the input and output signals are 14-bit, 2's complement samples.

The effect of removing the PCM encoding and decoding is to decrease the coding degradation by 0.6 to 1 qdu, depending on the network configuration considered (presence or absence of a G.712 filtering).

Currently, this extension has not been incorporated in the STL.

Figure 4-a — Encoder

Figure 4-b — Decoder

Figure 4 — G.727 encoder and decoder block diagrams

10.2.1.  G727_reset

Syntax:

#include "g727.h"
void G727_reset (g727_state _*st_);

Prototype: g727.h

Description:

Reset ITU-T G.727 embedded ADPCM encoder or decoder state variable.

10.2.2.  G727_encode

Syntax:

#include "g727.h"
void G727_encode (short _*src_, short _*dst_, short _smpno_, short _law_,
                  short _cbits_, short _ebits_, g727_state _*state_);

Prototype: g727.h

Description:

Simulation of the ITU-T G.727 embedded ADPCM encoder. Takes the A or $\mu$ law input array of shorts src (16 bit, right- justified, without sign extension) of length smpno, and saves the encoded samples in the array of shorts dst, with the same number of samples and right-justified. The ADPCM samples will have cbits core bits, and ebits enhancement bits.

The state variables are saved in the structure state, which should be initialized by g727_reset() before use. A-law is used if law=='1', and $\mu$-law if law=='0'.

Variables:

src

Is the input samples' buffer; each short sample shall contain right-justified 8-bit wide valid A or $\mu$ law samples.

dst

Buffer with right justified short ADPCM-encoded samples with cbits core bits and ebits enhancement bits. Unused MSbs are set to zero.

smpno

Is a short indicating the number of samples to encode.

law

Is a char indicating if the law for the input samples is A ('1') or $\mu$ ('0').

cbits

Number of core ADPCM bits.

ebits

Number of enhancement ADPCM bits.

state

The state variable structure; all the variables here are for internal use of the G.727 algorithm, and should not be changed by the user.

Return value: None.

10.2.3.  G727_decode

Syntax:

#include "g727.h"
void G727_decode (short _*src_, short _*dst_, short _smpno_, short _law_,
                  short _cbits_, short _ebits_, g727_state _*state_);

Prototype: g727.h

Description:

Simulation of the ITU-T G.727 embedded ADPCM decoder. Takes the ADPCM input array of shorts src (16 bit, right-justified, without sign extension) of length smpno, and saves the decoded samples (A or $\mu$ law) in the array of shorts dst, with the same number of samples and right-justified. The ADPCM samples must have cbits core bits, and ebits enhancement bits.

The state variables are saved in structure st, which should be initialized by g727_reset() before use. The law is A if law=='1', and $\mu$ law if law=='0'.

Variables:

src

Buffer with right justified short ADPCM-encoded samples with cbits core bits and ebits enhancement bits. Unused MSbs are zero.

dst

Is the input samples' buffer; each short sample shall contain right-justified 8-bit wide valid A or $\mu$ law samples.

smpno

Is a short indicating the number of samples to encode.

law

Is a char indicating if the law for the input samples is A ('1') or $\mu$ ('0').

cbits

Number of core ADPCM bits.

ebits

Number of enhancement ADPCM bits.

state

The state variable structure; all the variables here are for internal use of the G.727 algorithm, and should not be changed by the user.

Return value: None.

10.4.1.  Description of the demonstration program

One program is provided as demonstration program for the G.727 module, g727demo.c.

Program g727demo.c accepts input files in either 16-bit, right-justified A- or $\mu$-law format (as generated by g711demo.c) and encodes and/or decodes using the G.727 algorithm for the user-specified number of $N_c$ core bits and $N_e$ enhancement bits. The effective encoding bitrate will then be $16\times \left(N_c+N_e\right)$ kbit/s. Linear PCM files are not accepted by the program, since G.727 Annex A [7] is not yet implemented in the STL. Three operations are possible: logarithmic in, logarithmic out (default) logarithmic in, ADPCM out (option -enc), or ADPCM in, logarithmic out (option -dec).

10.4.2.  Simple example

The following C code gives an example of G.727 coding and decoding using as input speech previously encoded by either the A- or $\mu$-law functions available in the STL. The output samples are encoded using the same law of the input signal.

#include <stdio.h>
#include "ugstdemo.h"
#include "g727.h"

#define BLK_LEN 256

void main(argc, argv)
  int             argc;
  char           *argv[];
{
  G727_state      encoder_state, decoder_state;
  char            law;
  short           core, enh;
  char            FileIn[180], FileOut[180];
  short           tmp_buf[BLK_LEN], inp_buf[BLK_LEN], out_buf[BLK_LEN];
  FILE           *Fi, *Fo;

  /* Get parameters for processing */
  GET_PAR_C(1, "_Law: ......................... ", law);
  GET_PAR_I(2, "_Core bits: ................... ", core);
  GET_PAR_I(2, "_Enhancement bits: ............ ", enh);
  GET_PAR_S(2, "_Log-PCM Input File: .......... ", FileIn);
  GET_PAR_S(3, "_Log-PCM Output File: ......... ", FileOut);

  /* Opening input and output LOG-PCM files */
  Fi = fopen(FileIn, RB);
  Fo = fopen(FileOut, WB);

  /* Reset state variables */
  g727_reset(&#x26;encoder_state);
  g727_reset(&#x26;decoder_state);

  /* File processing */
  while (fread(inp_buf, BLK_LEN, sizeof(short), Fi) == BLK_LEN)
  {
    /* Process input log PCM samples in blocks of length BLK_LEN */
    G727_encode(inp_buf, tmp_buf, BLK_LEN, law, core, enh, &#x26;encoder_state);

    /* Process ADPCM samples in blocks of length BLK_LEN */
    G727_decode(tmp_buf, out_buf, BLK_LEN, law, core, enh, &#x26;decoder_state);

    /* Write PCM output word */
    fwrite(out_buf, BLK_LEN, sizeof(short), Fo);
  }

  /* Close input and output files */
  fclose(Fi);
  fclose(Fo);
}

11.1.1.  General characteristics

LD-CELP modified the structure present in the classical CELP-type coders [37] to meet the performance requirements for the algorithm, as well as to allow its implementation in real-time. However, it kept the basic structure of CELP coders, which is the the search in codebooks using an analysis-by-synthesis approach.

Traditionally, an analog signal is digitized into a 64 kbit/s bitstream with 8 bits per sample (ITU-T Rec. G.711), hence a 16 kbit/s bitstream would be equivalent to quantizing using 2 bits per sample. Since LD-CELP uses a basic frame of five samples, this implies that the vector quantization codebook has 1024 vectors (represented by 10-bit indices). Each codevector is the result of a 3-bit scalar gain and a shape vector of dimension 5 (represented by 7 bits). The scalar gain has one sign bit and two magnitude bits, being symmetrical around 0. This allows doubling the range of amplitudes represented by the shape codebook without duplicating the search complexity for the optimal codevector.

The codebook was trained with the same perceptual weighting¹¹ implemented in the codec, what takes into account the adaptation effect in the predictor and of the excitation gain; this has a better performance than populating the codebook with Gaussian random numbers, which was the traditional approach for CELP coders [37].

After populating the codebook, indices are assigned to these values to organize the codevectors inside the codebook. To ensure a better SNR in the decoder for error-prone channels, a pseudo Gray coding was used for the indices. With this, a single error affecting the codebook index will shift it to a codeword very close to the original one, contrary to what would happen if the indices were randomly distributed.

11.1.2.  Type of algorithm specification

The specification of an algorithm can be made in one of three methods [38]: bit-exact, bitstream, and algorithm-exact specification. The bit-exact specification implies that all variables and operations inside the algorithm have the bit length and representation precisely defined; this is the type of specification historically used for ITU speech and audio codecs, e.g. G.722, G.726, and G.729. Another approach consists in only specifying the bitstream format (or syntax) and the decoder; additionally, it is common practice to provide a reference encoder and decoder, which can usually be modified to reduce complexity or improve performance. This type of specification was used for regional cellular codec standards in Japan and USA, e.g. VSELP, for video codecs, as well as in the MPEG suite of audio and video codecs. Finally, algorithm-exact specification implies in describing in detail all parts of the algorithm, without however specifying variable length or precision. An algorithm specification made in one of these three ways can additionally be defined in terms of fixed-point arithmetic (only integer variables) or of floating-point.

The original G.728 algorithm is specified in terms of floating-point operations. Therefore, it is a non-bit-exact specification that describes precisely the operations for its implementation [38]. A fixed-point (albeit non-bit-exact) implementation of G.728 was subsequently designed to enable efficient implementation in digital circuit multiplication equipment, which maintained full interoperability with the original floating-point version¹². An implication of this approach is the need to define procedures for more sophisticated implementation and interoperability verification than the ones used for bit-exact algorithms.

Historically, the choice for an initial implementation in floating-point was only allowed due to the availability at the time of commercially available floating-point DSPs. Even though they are common place today, back in early 1990's this was a breakthrough decision. This was further motivated by the fact that it was uncertain whether the original time schedule and performance requirements could be met if the group were to pursue a fixed-point (possibly bit-exact) implementation. In retrospect, the quality and deadlines targets could have been met, but the safe approach was to go for a floating-point specification.

11.1.3.  Delay

LD-CELP has an algorithmic delay¹³ of 625 $\mu s$ (five-sample frame) and a (total) one-way delay of less than 2 ms. To obtain this delay while keeping the required quality, the designers adopted a backward predictor adaptation technique.

11.1.4.  Backward adaptation

In the traditional CELP approach, the excitation, the LPC coefficients and gain are transmitted, while with LD-CELP only the excitation is transmitted. For this to work, the LPC analysis is made with the quantized version of the signal and the excitation gain is updated based on the gain embedded in the samples previously quantized.

In the LD-CELP encoder there are three backward-adaptive structures: the LPC synthesis filter, the perceptual weighting filter and the excitation gain unit. In addition to these three structures, the decoder also has a backward adaptive post-filter.

Figure 6 — LD-CELP hybrid windowing

11.1.5.  Windowing used in the adaptation

In LD-CELP, except for the long-term post-filter in the decoder, all backward adaptive structures use LPC analysis. The LPC prediction coefficients are calculated using the auto-correlation method [39]. In this method, windowing is necessary to increase the prediction gain.

Normally, a Hamming window is used, but this is not appropriate for LD-CELP. The LD-CELP analysis block has only 5 samples, compared to the conventional 160 to 256 samples normally used. Hence, using a Hamming window would imply a significant overlap of windows across frames and a high computational complexity [41]. It was noticed that in the backward adaptation context of LD-CELP, the Barnwell recursive windowing technique [42] gave higher prediction gains than the Hamming windowing, in addition to a higher subjective quality for the processed speech. For this reason, the LD-CELP version tested in Phase 1 of subjective assessments used a modified adaptive windowing [43], [44]. This way, it was possible to obtain a better quality, a more balanced computational load and a lower complexity for frequent predictor updates [45].

However, aiming at a future fixed-point implementation with minimal changes compared to the floating-point version (since interoperability was a requirement), a hybrid windowing technique was developed [41], [23], with results equivalent to those of the Barnwell version¹⁴. This was implemented in the version tested in Phase 2 of testings and today is present in G.728 (see Figure 6). With it, it was possible to keep the same quality (since the shape of both the hybrid and recursive windows is the same) while reducing the computational complexity between 20% and 30%. The objective was to reduce the complexity by mixing a recursive portion using the Barnwell technique with a non-recursive one, however maintaining the overall shape of the Barnwell window. The windowing was implemented such that the $m$ most recent samples are superimposed using the non-recursive portion of the window, and the samples previous to the $m$-th sample are considering in the recursive portion of the window. This window has a characteristic that non-recursive part has a sinusoidal shape and the recursive part has a decaying exponential (so as to lessen the influence of older past samples).

In terms of equations [23], [43], the hybrid window $w_m\left(k\right)$ is defined by:

where

and $0<\alpha <1$, $0<b<1$ and $c$ are constants specific to each of the backward adaptive structures of the algorithm.

In the auto-correlation method, the i-th auto-correlation coefficient $R_m\left(i\right)$ of the input signal $s\left(n\right)$ is calculated as:

Where $r_m^{\mathrm{\backslash cal}R}(i)$ and $r_m^{\mathrm{\backslash cal}N}(i)$ are respectively the recursive and non-recursive components of the i-th auto-correlation coefficient described by:

and

Considering a predictor of order $M$ with an adaptation (update) cycle of $L$ samples, the i-th auto-correlation coefficient of the next adaptation cycle will be:

with

and

Therefore, it can be seen that $r_{m+L}^{\mathrm{\backslash cal}R}(i)$ is recursively calculated from its value $r_m^{\mathrm{\backslash cal}R}(i)$ from the previous adaptation cycle and that the auto-correlation coefficients always have a recursive and a non-recursive portion.

11.1.6.  White noise correction

The use of the auto-correlation method for the calculation of the LPC coefficients has embedded in it the calculation of the inverse of the auto-correlation matrix, even though this is not explicitly made in methods such as the Levinson-Durbin method, where the prediction (and reflection) coefficients are iteratively calculated.

However, these are equivalent operations, and if the auto-correlation matrix is ill-conditioned¹⁵, the LPC coefficients calculated by the Levinson-Durbin method can lead to an unstable filter. This effect will be even more pronounced when high-order LPC filters are used, as in this case. A simple technique to reduce the matrix ill-conditioning consists in adding white noise to the signal on which the prediction will be made, since this will fill the spectral valleys with noise and would reduce the dynamic range of the spectrum. From the computational point of view, however, it is interesting to adopt an equivalent procedure, designated in G.728 as "white noise correction".

Let's consider a voice signal $s\left(k\right)$ whose auto-correlation function is $R_s\left(i\right),i=1..M$, where $M$ is the prediction filter order. In a synthetic notation,

Similarly, we can associate to a white noise signal $n\left(k\right)$ an auto-correlation function $R_n\left(i\right)$, or:

If we add signal and noise, the resulting auto-correlation function $R\left(i\right)$ is:

where G is a constant designated white noise correction factor. The SNR is given as a function of G:

As $n\left(k\right)$ is a white noise, its auto-correlation function is given by:

Consequently:

This way, it can be seen that it is sufficient to add a certain value $G$ to the coefficient $R_s\left(0\right)$ to reduce the ill-conditioning of the auto-correlation matrix. The value of $G$ is defined by the level of noise that one wants to "add" to the signal.

In LD-CELP, this technique is used to, without increasing the computational complexity, add noise at approximately 24 dB below the signal level ($G$=1/256) and lessen ill-condition of the auto-correlation matrix for the LPC synthesis filter and the perceptual weighting filter.

11.1.7.  Bandwidth expansion

A common technique in CELP coders consists in attenuating the formant peaks through a bandwidth expansion of the LPC spectrum¹⁶:

where ${\widehat{a}}_i$ is the i-th coefficient calculated by the predictors and $\lambda$ is a constant that satisfies $\lambda <1$ and $\lambda \approx 1$.

The effect of the expansion is to move the predictor poles inside the unity circle. Additionally, the impulse response of the model gets shorter, reducing the transmission error propagation inside the adaptation mechanism.

11.1.8.  Input and output formats

Since LD-CELP is an algorithm also designed for use in the PSTN, the input and output signal representation follows the ITU-T Rec. G.711 format (either A or $\mu$ law)¹⁷.

Since the internal algorithm operations are performed in linear PCM format, the first block in Figure 5-a consists in the expansion of the log-PCM samples into linear format; complimentary, the last block in Figure 5-b, after all decoding processing, does the compression of the linear samples into the selected log-PCM law.

11.2.1.  LPC synthesis filter

The synthesis filter uses LPC coefficients and has order 50, and generates the quantized signal from the de-normalized excitation vector. The reason for such a high order is explained below.

A very common technique used in speech coders, in particular CELP coders, is the use of long-term prediction, or forward-adaptive pitch prediction. Conventional LPC prediction is normally based on a small number of LPC coefficients (usually, 10 to 12 in narrowband speech signal [39],pp.419—​420), what does not allow to do a long term prediction that takes into account the pitch period. The use of pitch predictors is needed to make whiter the excitation signal obtained after a conventional LPC analysis, thus better exploring the signal predictability. However, since LD-CELP only transmits the excitation information, the pitch prediction would also need to be backward-adaptive, as done in [29], [34]. This technique, however, is very sensitive to transmission errors due to the high filter orders, what makes the errors to propagate over a large number of samples. The use of artificial re-initializations could solve the problem, but since the algorithm was required to operate at high bit error rates, e.g., ${10}^{-2}$ equivalent to 160 errors per second, this would not work for the LD-CELP [43].

Together with the error propagation issue, it was noticed that the improvement introduced by the pitch predictor for female speakers was much higher than for male speakers¹⁸ [43].

This way, with the problems of the backward-adaptive pitch predictor with transmission errors and the larger importance of the pitch prediction for female speech, it was decided to explore the predictability of the female speech using a high-order synthesis filter predictor, so that most of the pitch values for female speaker would be covered. It was then found empirically that an order of 50 for the LPC synthesis filter produced good results¹⁹, replacing the "low order LPC predictor and pitch predictor" traditionally used in CELP coders.

11.2.2.  Perceptual weighting filter

The general form of the perceptual weighting filter is [46]:

where:

and $q_i$ are the quantized LPC coefficients and $M$ is the LPC predictor order.

Its function is to model the spectral envelope of the error signal, so that it becomes similar to the spectrum of the input voice signal, this way masking the distortion which, without this weighting, could be perceived by the user. By using the weighted error signal to select the codevector, this codevector will be the one that, on the decoder, will produce the lowest quantization noise perceived by the user, increasing in the decoder the subjective quality [47].

For CELP coders, (${\gamma }_1,{\gamma }_2=\left(1.0,0.8\right)$ are normally used. In LD-CELP Phase 1 and 2, $\left({\gamma }_1,{\gamma }_2\right)=\left(0.9,0.4\right)$ and $\left({\gamma }_1,{\gamma }_2\right)=\left(0.9,0.6\right)$ were used, respectively, what resulted in a lower perceived noise level. Parameter ${\gamma }_2$ was changed to allow the codec to meet the three transcoding requirement, condition for which the codec had failed the performance requirement in Phase 1 [48].

The predictor order $M$ was set here to 10 to avoid artifacts²⁰ that appeared with the use of higher order filters (e.g. 50, as in the synthesis filter). To compensate for the low order, instead of using a sub-set of the main predictor coefficients (which in principle could be the same computational structure), an independent predictor is applied on the input signal (noting that the main predictor operates on the quantized samples). This is justified by two facts: since the perceptual weighting is not necessary on the decoder, nothing obliges the prediction to be made on the quantized signal; and (more importantly) the use of the original signal allows the more precise calculation of the spectral envelope.

11.2.3.  Search of optimal excitation codevector

For each sample vector $s\left(n\right)$, a search is made to find which of the 1024 codevectors generates the lowest (perceptually weighted) average quadratic error. The selected codevector has its index transmitted to the decoder and is fed back to the adaptive part of the encoder (a replica of the decoder inside the encoder), to be used as excitation for the synthesis filter. An efficient search algorithm was selected for the LD-CELP algorithm [49], [50], which is described in detail in the Recommendation [23].

11.2.4.  Denormalizing quantized excitation

To increase coding efficiency, the 1024 codevectors in the codebook represent typical excitation (obtained by training of this codebook from a large corpus of speech signals), whose amplitude has been normalized. Therefore the excitation vector to be used in the synthesis filter needs to be denormalized, which is done in the excitation denormalization block. The adaptation mechanism for this block is described below.

11.2.5.  Adaptation of excitation gain

The optimal index transmitted to the decoder represents the normalized value of the excitation vector found for the input signal. Therefore, for the signal reconstruction (both in encoder and decoder), it is necessary to calculate the excitation gain value to be used for the denormalization of the excitation gain. This can be done using a fixed value pre-determined using a long-term statistical analysis of the possible gain values (similar to the fixed coefficient predictors and quantizers) of a large corpus of speech signals. A more optimal approach is to use an adaptive calculation of the gain. In LD-CELP, the calculation of the gain uses a mixed technique, which uses a fixed offset of 32 dB for the gain (empirically obtained), which is associated to a 10-th order LPC predictor using the auto-correlation method and hybrid windowing. This predictor adapts the gain around the fixed offset, in order to increase its precision.

The denormalized error signal $e\left(n\right)$ can be expressed in terms of the excitation gain $\sigma \left(n\right)$ and the normalized error $y\left(n\right)$ by:

If ${\sigma }_y^2\left(n\right)$ and ${\sigma }_e^2\left(n\right)$ are respectively the mean square values of $y\left(n\right)$ and $e\left(n\right)$, then:

We can predict the excitation gain $\sigma \left(n\right)$ from the past values of the denormalized gain ${\sigma }_e$ using the predictor:

Here, the predictor order is $P=10$.

It should be noted that this predictor, when combined with the last two equations, can be seen as a predictor with $P$ poles and $P$ zeros that uses $\log {\sigma }_y\left(n-i\right)$as input:

The gain adaptation is backward-adaptive, as in other parts of LD-CELP. The use of the auto-correlation method for calculating the coefficients $p_i$ guarantees the stability of the filters above, what implies a filter response that falls asymptotically to zero. This limits the propagation of transmission errors, indicating a certain robustness of this block to transmission errors. This robustness brings the poles and zeros closer together, shortens the predictor impulse response and further limits the propagation of errors within the algorithm.

11.2.6.  Adaptation of perceptual adaptation filter

To adapt the coefficients of the perceptual weighting filter the auto-correlation method is applied over the buffered (unquantized) input signal using a hybrid window, white-noise correction, and the Levinson-Durbin algorithm. The LPC coefficients are then multiplied by the factors ${\gamma }_1$ and ${\gamma }_2$, which define the degree of perceptual weighting.

11.2.7.  Adaptation of LPC synthesis filter

The LPC predictor coefficients for the synthesis filter are adapted using the quantized input signal. Similar to the perceptual weighting filter, hybrid windowing, white noise correction and Levinson-Durbin algorithm are used (albeit with different parameters for the hybrid window and a larger order of 50 for the LP filter). After calculation of the LPC coefficients, these pass through the spectral widening and then are input to the synthesis filter.

11.3.1.  Post-filter and its adaptation

A post-filter [52] consists of a time-variant filter put at the output of a decoder with the intention to improve the subjective signal quality.

Post-filtering, a technique very common in CELP coders, was not used in the first phase of testing for two reasons. The distortion introduced by post-filtering accumulates with multiple transcodings (tandem), what can compromise speech quality²¹. Besides that, post-filtering introduce phase distortions that can make it difficult to decode properly voice-band data that relies on phase to carry information (e.g. DPSK) [53], [45].

Since the Phase 1 algorithm did not pass the three-tandem connection condition, it was modified with introduction of post-filtering for Phase 2. However, the use of traditional post-filtering would imply unacceptable distortions for the reasons mentioned above. Then instead of optimizing the post-filter for each transcoding, it was optimized for three transcodings, thus implying a smaller amount of post-filtering for each tandem step [43]. This allowed the overall distortion added by the post-filtering to remain within acceptable levels, while the subjective quality for three transcodings saw a significant improvement (a 26% increase in the MOS scores). Even for a single transcoding there was a good improvement in the subjective quality. During the Phase 2 tests, the change showed to be a good compromise, increasing the subjective quality while maintaining a good performance for voice-band data.

The LD-CELP post-filter consists of three blocks: a long-term post-filter, a short-term post-filter and an automatic gain control (AGC).

The long-term post-filter (also called pitch post-filter), is basically a comb filter with a fundamental frequency being the reciprocal of the pitch period. This filter is described by the following equation:

where $p$ is the pitch period obtained by a pitch predictor and $g_l$ and $b$ are coefficients adapted from 240 buffered excitation samples. In LD-CELP, $p$ varies between 20 and 140 (57 to 400 Hz).

This way, when this post-filtering is applied to the synthesized signal, the spectrum regions around the multiples of the fundamental frequency are emphasized. This emphasizes pitch perception, thus resulting in a higher subjective quality.

The short-term post-filter, on the other hand, is used to reduce the audible coding noise by emphasizing the peaks and attenuating the valleys in the input signal spectrum. This is justified by the fact that perceptually the regions around LPC spectrum peaks, i.e. the formant regions, are more important than the regions around the valleys.

The short-term post-filter is implemented as a low-pass filter with the same number of poles and zeroes which cascades a first-order high-pass filter. The high-pass filter serves to compensate the muffling effect of the first low-pass filter. The general form of the short-term post-filter is given by:

where:

and ${\stackrel{\sim }{\gamma }}_1$, ${\stackrel{\sim }{\gamma }}_2$ and ${\stackrel{\sim }{\gamma }}_3$ are constants, $a_i$ are the LPC coefficients, $M$ is the predictor order and $k_1$ is the first reflection coefficient.

It should be noted that the high-pass filter is implemented with an adaptive coefficient, the reflection coefficient $k_1$. Therefore, the filter characteristics might not always be that of a high-pass. Long-term speech statistics measurements at the time of development of the algorithm using about 10 minutes of speech showed that $k_1<0$ for major part of time (around 92%) (see Figure 7), thus guaranteeing that filter is a high-pass for the most part of the of the input signals.

Figure 7 — Histogram of $k_1$ values for 10 minutes of speech

In LD-CELP, the filter order of $A\left(z\right)$ is 10 and the $a_i$ coefficients, as well as the reflection coefficient $k_1$, are obtained during the adaptation of the decoder synthesis filter. Constants $\left({\stackrel{\sim }{\gamma }}_1,{\stackrel{\sim }{\gamma }}_2,{\stackrel{\sim }{\gamma }}_3\right)$ were empirically determined as (0.65,0.75,0.15).

Finally, the AGC is responsible for making that the power of the decoded signal after post-filtering be approximately the same as before post-filtering. The AGC is calculated by the ratio of the average signal amplitudes before and after post-filtering. This avoids too much attenuation or clipping.

11.4.1.  Floating-point G.728

The source code for the floating-point version of G.728 resides in the directory g728/g728float. All public interface function declarations and data structures needed to call the coder can be found in the header file g728.h. The package includes a demonstration program, g728.c, that shows how to call the encoder, decoder, and decoder with packet loss concealment. The demonstration program can run the coder on the G.728 test vectors.

The floating-point version of the coder can be compiled to use either double precision or single precision floating-point arithmetic. If compiled with -DUSEDOUBLES, g728.h defines the Float typedef as a C double. If compiled with -DUSEFLOATS, Float is a C float. Float is declared in g728.h as:

#ifdef USEDOUBLES
typedef double Float;
#endif
#ifdef USEFLOATS
typedef float  Float;
#endif

Single precision runs faster. Double precision runs slower but is more likely to give results that are bit-exact across different machines. When compiling for use with the test vectors double precision arithmetic should be used.

The include file, g728.h also defines a Short type:

typedef short  Short;

to hold signed 16-bit integers.

11.4.2.  G.728 Floating-point Encoder

g728.h defines a C structure, G728EncData, to hold the encoder state variables. Its contents are described in the G.728 standard. Here we emphasize how to use it, rather than its internal members. Before calling the encoder G728EncData should be initialized with a call to g728encinit:

void g728encinit(
     G728EncData *e    /* encoder state, initialize */
);

Once initialized, frames of speech can be encoded with:

void g728encode(
    Short       *index,  /* output indices */
    Float       *input,  /* input speech */
    int          sz,     /* input size - must be multiple of IDIM */
    G728EncData *e       /* i/o encoder state */
);

The input speech should be an array of Float`s in the range of -32768. to 32767. `sz is the dimension of the input array, and must be a multiple of the coder frame size, IDIM. IDIM is defined to be 5 in g728.h. index is the output of the encoder. It is an array of codevector indices that are transmitted to the decoder. index has dimension sz / IDIM, as one codevector will be output for each input frame of IDIM speech samples. Only the least significant 10 bits of each index value are set. The 3 bits of gain index bits are in bits 0 to 2 (0 being the least significant bit), and the 7 bits of shape index are in bits 3 to 9. Bits 10 to 15 in each index value are unused and contain zeros. If an application desires to compactly transmit the codevectors for multiple frames, it will have to extract the lower 10 bits from each index word and pack the bits.

The floating-point G.728 software package includes utility functions for converting between `Short`s (16-bit integers) and `Float`s:

extern void g728_cpyr2i( /* convert Floats to Shorts,
                      * with saturation and rounding */
    Float *f,   /* input: float array */
    int   sz,   /* input: array size */
    Short *s    /* output: short array */
);
extern void g728_cpyi2r( /* convert Shorts to Floats */
    Short *s,   /* input: short array */
    int   sz,   /* input: array size */
    Float *f    /* output: float array
);

These are used by the test program, g728.c. A simple encoder loop that reads in frames of 16-bit linear PCM, encodes them with floating-point G.728, and outputs the index vectors is in the following code fragment:

#include "g728.h"

Short       ix;         /* output: index */
Short       s[IDIM];    /* input: 16-bit speech */
Float       f[IDIM];    /* converted to Float */
G728EncData e;          /* encode state */

g728encinit(&e);        /* initialize encoder state */
while (fread(s, sizeof(Short), IDIM, speechinf) == IDIM) {
        g728_cpyi2r(s, IDIM, f);        /* convert Short to Float */
        g728encode(&ix, f, IDIM, &e);   /* encode */
        fwrite(&ix, sizeof(Short), 1, indexf);  /* write to file */
}

We have omitted the details of opening the files. The code in the (mode == M_ENC) section of g728.c is a more complicated example that allows frame sizes that are multiples of IDIM, does more error checking, and also allows byte swapping of the input and output files.

11.4.3.  G.728 Floating-point Decoder

g728.h defines a C structure, G728DecData, to hold the decoder state variables. Many of the decoder state variables replicate the state variables in the encoder. There are additional sections for variables associated with the post-filter and packet loss concealment. As with the encoder, the G728DecData must be initialized before it can be used:

void g728decinit(
    G728DecData *d    /* decoder state, initialize */
);

Once initialized, frames of speech can be decoded with:

void g728decode(
    Float       *speech, /* output: speech */
    Short       *index,  /* input: indices */
    int         sz,      /* input: size - must be multiple of IDIM */
    G728DecData *d       /* i/o: decoder state */
);

speech points to the output speech array. sz is the dimension of the output speech array. Like at the encoder, it must be a multiple of the coder frame size, IDIM. index is a pointer to the array of input codevectors. As with the encoder index should be dimension sz / IDIM. Five speech samples will be produced for each input codevector. The format of the index words is the same as in the encoder.

If the output speech is to be converted back to 16-bit linear PCM, the conversion routine should take care of rounding and saturation. The utility conversion routine, g728_cpyr2i, described above, takes care of this. Here is a code fragment that can be used to implement a floating-point decoder:

#include "g728.h"

Short       ix;         /* input: index */
Float       f[IDIM];    /* output: speech, Float */
Short       s[IDIM];    /* output: speech, converted to 16-bit int */
G728DecData d;          /* decode state */

g728decinit(&d);        /* initialize decoder state */
while (fread(&ix, sizeof(Short), 1, indexf) == 1) {
    g728decode(f, ix, IDIM, &d);     /* decode */
    g728_cpyr2i(f, IDIM, s);         /* convert to Short */
    fwrite(s, sizeof(Short), IDIM, speechoutf);
}

Again we have omitted the details of opening the files. The code in the (mode == M_DEC) section of g728.c is a more complicated example that allows frame sizes that are multiples of IDIM, does more error checking, and also allows byte swapping of the input and output arrays.

An additional interface routine, g728setpostf, allows the post-filter in decoder to be turned on or off. By default, the post-filter is on after initialization, but it can be disabled as required by several of the G.728 test vectors:

void g728setpostf(
    int          i,     /* in: 1 postfilter on, 0 off */
    G728DecData *d      /* i/o: state variables */
);

11.4.4.  G.728 Floating-point Encoder/Decoder

The following program fragment shows how to run the encoder and decoder together. It combines the fragment from the encoder, with the fragment from the decoder, and uses the utility functions to convert between Floats and Shorts. The loop sequence is: read in a frame of speech, convert to Float, encode, decode, convert the output from Float to Short, and write the resulting speech to a file:

#include "g728.h"

Short       ix;         /* index */
Short       s[IDIM];    /* 16-bit speech vector*/
Float       f[IDIM];    /* Float speech vector */
G728EncData e;          /* encode state */
G728DecData d;          /* decode state */

g728encinit(&e);        /* initialize encoder state */
g728decinit(&d);        /* initialize decoder state */
while (fread(s, sizeof(Short), IDIM, speechinf) == IDIM) {
    g728_cpyi2r(s, IDIM, f);       /* convert Short to Float */
    g728encode(&ix, f, IDIM, &e);  /* encode */
    g728decode(f, ix, IDIM, &d);   /* decode */
    g728_cpyr2i(f, IDIM, s);       /* convert to Short */
    fwrite(s, sizeof(Short), IDIM, speechoutf);
}

The code that opens and closes the input and output files is omitted.

11.4.5.  G.728 Floating-point Decoder with Packet Loss Concealment

The floating-point code supports the Packet Loss Concealment (PLC) algorithm in G.728 Annex I. This algorithm generates a synthetic speech output at the decoder and maintains the decoder internal state variables if the input codevectors are lost in transmission. This feature is implemented with two more functions. The first PLC function:

void g728setfesize(
    int    plc25msec,   /* input: PLC frame size, in 2.5msec */
    G728DecData *d      /* i/o: decoder state */
);

sets the PLC frame size, in increments of 2.5ms (20 samples). This function should be called after the G728DecData has been initialized with a call to g728decinit. If the PLC frame size argument, plc25msec, is set to 1, each lost frame will correspond to 20 samples. This variable: plc25msec should be in the range of 1 to 8, corresponding to a packet loss size of between 2.5 ms (20 samples) and 20 ms (160 samples). If the call to g728setfesize is omitted, the default PLC frame size is 10 ms (80 samples). The PLC algorithm uses state variables from the post-filter, so the post-filter must be activated when running the PLC algorithm.

The second PLC function:

void g728decfe(
    Float       *speech,  /* output: speech */
    int         sz,       /* input: size, in samples, PLC framesize */
    G728DecData *d        /* i/o: decoder state */
);

is similar to the g728decode function except it takes no input index vector. It serves two functions: it signals the decoder that the current frame is lost, and it generates the synthetic output signal for the frame. The sz argument is the number of samples in the PLC frame size. Since there are 20 speech samples in 2.5 ms of speech, the sz argument to g728decfe should be 20 times the plc25msec argument passed to g728setfesize. For frames that do not have losses, the standard g728decode function should be called.

A code fragment that shows how to call the PLC functions for a 10 ms PLC frame size (80 samples) is shown below:

#include "g728.h"

Short       ix[80/IDIM];/* input: index vectors */
Float       f[80];      /* output: Float array */
Short       s[80];      /* output: converted to 16-bit speech */
G728DecData d;          /* decode state */

g728decinit(&d);        /* initialize decoder state */
g728setfesize(4, &d);   /* 4 * 2.5msec frames = 10 msec */
while (fread(ix, sizeof(Short), 80/IDIM, indexf) == 80/IDIM) {
    if (ferasedin())
        g728decfe(f, 80, &d);           /* PLC decode */
    else
        g728decode(f, ix, 80, &d);     /* normal decode */
    g728_cpyr2i(f, 80, s);             /* convert to Short */
    fwrite(s, sizeof(Short), 80, speechoutf);
}

As in the previous section, the details on opening the files are omitted. Function ferasedin() returns 1 if the current frame should call the packet loss concealment code, and 0 if the standard decoding routine should be called. The code in the (mode == M_PLC) section of g728.c shows a more complicated version of the PLC loop that supports setting of the PLC frame size from the command line.

11.4.6.  Fixed-point G.728

The source code for the fixed-point version of G.728 resides in the directory g728/g728fixed. All interface functions and data structures needed to call the coder can be found in the file g728fp.h. The interface mirrors the floating-point version of the codec, although the routines and data structures have different names, and the input and output speech arrays are Shorts instead of Floats. The fixed-point package also includes a demonstration program, g728fp.c, that shows how to call the encoder, decoder, and decoder with packet loss concealment. The demonstration program can run the coder on the test vectors. Please note that the fixed-point and floating-point test vectors are different sets of files.

The fixed-point G.728 algorithm internally uses double precision floating-point arithmetic to simulate some fixed-point operations. At the time this simulation was written, this sped up the run-time and allowed the coder to run in real-time on early Pentium-based computers. With today's 64 bit integer machines and faster processors, there are likely to be better alternatives for simulating accumulator guard bits. The fixed-point simulation code should generate bit-exact output for all the test vectors.

Rather than repeating the interface presented in the floating-point section, the Table 2 lists the differences between the fixed-point and floating-point versions.

Table 2 — Differences between G.728 fixed-point and floating-point versions

11.4.7.  G.728 Fixed-point Encoder/Decoder

The program fragment below shows how to run the fixed-point encoder and decoder together. Speech is input from a file, encoded, decoded, and the output speech is written back to a file:

#include "g728fp.h"

Short         ix;       /* index */
Short         s[IDIM];  /* 16-bit speech vector*/
G728FpEncData e;        /* encode state */
G728FpDecData d;        /* decode state */

g728fp_encinit(&e);     /* initialize encoder state */
g728fp_decinit(&d);     /* initialize decoder state */
while (fread(s, sizeof(Short), IDIM, speechinf) == IDIM) {
    g728fp_encode(&ix, s, IDIM, &e);   /* encode */
    g728fp_decode(s, IDIM, &d);        /* decode */
    fwrite(s, sizeof(Short), IDIM, speechoutf);
}

This code closely resembles the code fragment for the floating-point code. Note that the input and output speech arrays to the encoder and decoder are Shorts so there is no need to call the Float to Short conversion routines. Input and output speech arrays are 16-bit linear full range PCM.

11.4.8.  G.728 Demonstration Program

Both the floating-point and fixed-point versions of the G.728 coder software provide a demonstration program, defined in g728.c and g728fp.c, respectively, that can be used for four functionalities: encode, decode, decode with packet losses, and encode and decode a file in a single pass. Scripts are also provided to run G.728 on the test vectors. The test vectors themselves are not part of the STL. The floating-point version compiles the program into a binary called g728. The fixed-point version compiles into a binary called g728fp. Since the programs provide an identical user interface, we will only discuss g728. In the examples below, substitute g728fp for g728 to use the fixed-point version of the coder.

The demonstration programs expect speech input and output files to be header-less, and contain binary 16-bit linear full range PCM. By default it is assumed that the files are in the native byte order of the machine. The byte order of the input and output files can be overridden on the command line with the options -little (for little-endian files) and -big (for big-endian files). When the -little or -big options are given, the software first determines if the current machine is a big-endian or little-endian machine. If the machine has the same endian characteristics as the requested file, no byte swapping is performed on the input and output files. If there is a mismatch, byte swapping is performed. For example, the G.728 test vector files are little endian files. Giving the -little option on Sun SPARC and MIPS processors (big-endian machines) will cause the input files to be byte swapped before processing, and output data streams to be byte-swapped before being written to files. On Intel processors, the -little option is a "no-op".

Bit-streams are in the format of the ITU G.728 test vectors. For every 5 input speech samples, a single 16-bit binary word is output. Only the least significant 10 bits of each 16-bit output word are used. The G.728 gain index (3 bits) resides in bits 0 to 2 (0 being the least significant bit), and the shape index (7 bits) resides in bits 3 to 9.

Input PLC mask files are ASCII files that contain '0's and '1's. A '1' implies the current frame is lost and should be concealed. A '0' implies the normal decoding routine should be called for the current frame. The PLC files may also contain newlines and return characters that will be ignored. If any other character occurs in the file, it is an error, and the program will exit with an error message. If the PLC mask file reaches the end of the file but there are still frames to decode, the PLC file will roll over and seek back to the beginning of the file. For example, a PLC mask file containing '00000000000000000001' can be used to introduce a 5% uniform loss pattern.

The demonstration program supports several other options. Options should appear in the command line before the mode of the coder:

-nopostf

Turn off the post-filter in the decoder. This is required to run many of the test vectors. For normal operation the post-filter should be on.

-stats

PLC concealment option to print out statistics on how many frames were processed and concealed.

-plcsize msec

set the PLC concealment frame size, in milliseconds. This is how much speech will be concealed by a single lost packet. Only a limited set of values are acceptable: 2.5, 5, 7.5, 10, 12.5, 15, 17.5 and 20. The default value is 10 ms.

11.4.9.  G.728 Demonstration Program Modes

The program has 4 modes: encode, decode, decode with PLC, and encode and decode. To run the encoder use:

  g728 enc speech.infile bitstream.outfile

To run the decoder use:

  g728 dec bitstream.infile speech.outfile

To run the combined encoder and decoder use:

  g728 encdec speech.infile bitstream.outfile speech.outfile

To run the decoder with Packet Loss Concealment with the default 10ms PLC frame size:

  g728 plc bitstream.infile plcmask.infile speech.outfile

11.4.10.  G.728 Demonstration Program with Test Vectors

Scripts (testall.sh for Linux and Unix; testall.bat for Windows machines) are provided for running the demonstration programs on the the G.728 test vectors. The scripts use binary compare functions to see if the encoder and decoder output files differ from the expected results. For the fixed-point code an exact match is expected. For the floating-point code an exact match is not guaranteed. However, when compiled to use double-precision arithmetic (-DUSEDOUBLES) we have observed an exact match on all platforms we have tested the code on. If the floating-point code is compiled with the option -DUSEFLOATS, differences in the test vectors should be expected. For further details on the test vector verification procedure when the outputs do not match, please refer to G.278 Appendix I.

A script (testplc.sh, testplc.bat) is also provided to run the PLC algorithm on one of the test vectors. This program is only to demonstrate how to invoke the PLC algorithm, and does not compare the output with file. It is not possible to compare the outputs to a fixed file since the PLC algorithm uses a random number generator to extract the excitation when it determines whether a lost packet frame is in an unvoiced region of speech. Depending on where the packet losses occur, the output may be different for each run on the same file.

12.1.1.  Functional description of the SB-ADPCM encoder

Figure 9 shows block diagram of the SB-ADPCM encoder which comprises the following main blocks.

Figure 9 — Block diagram of the SB-ADPCM encoder

12.1.1.2.  Lower subband ADPCM encoder

Figure 10 gives block diagram of the lower subband ADPCM encoder. To transmit the lower band, the encoder was designed to operate at 6, 5 or 4 bits per sample, corresponding to 48, 40 or 32 kbit/s, respectively. The ADPCM algorithm is very similar to the embedded ADPCM algorithm of Recommendation ITU-T G.727 [22]. It is an embedded ADPCM with 4 core bits and 2 additional bits. The embedded property was introduced to prevent degradation in speech quality when the encoder and the decoder operate during short intervals in different modes.

Figure 10 — Block diagram of the lower subband ADPCM encoder

12.1.1.7.  Higher subband ADPCM encoder

Figure 11 shows block diagram of the higher subband ADPCM encoder. This encoder is designed to operate at 2 bits per sample, corresponding to a fixed bitrate of 16 kbit/s. The encoder algorithm is very similar to the lower band one but with the following main differences. The quantizer is a 4-level non-linear adaptive quantizer. The higher subband ADPCM encoder is not embedded, hence the inverse quantizer uses the 2 bits in the feedback loop.

Figure 11 — Block diagram of the higher subband ADPCM encoder

12.1.2.  Functional description of the SB-ADPCM decoder

Figure 12 shows block diagram of the SB-ADPCM decoder.

12.1.2.3.  Higher subband ADPCM decoder

This decoder (see Figure 14) is identical to the feedback portion of the higher subband ADPCM encoder described in the Section clause 12.1.1. Here, the output is reconstructed signal $r_H$.

Figure 12 — Block diagram of the SB-ADPCM decoder

Figure 13 — Block diagram of the lower subband ADPCM decoder

Figure 14 — Block diagram of the higher subband ADPCM decoder

12.1.3.  Functional description of the basic Packet Loss Concealment functionality

In 2006, basic index domain PLC functionality (zero index and frame repeat algorithms) for detected frame errors were included in the standalone decoder tool. The numbering and description of the four basic algorithms provided can be seen in Table 3.

Table 3 — Basic PLC algorithms supported by the G.722 standalone decoder

The PLC actions in the G.722 standalone decoder are activated by incoming G.192 frames that do not have a valid G192_SYNC header tag. Note that in November 2006, ITU-T SG16 approved two new Appendices to G.722 for Packet Loss Concealment (PLC). These two Appendices (Appendices III and IV [63], [64]) provide better quality over the basic PLC functionality included in STL.

12.2.1.  G.192 bit stream format for standalone G.722 encoder and decoder

As described previously, G.722 is an embedded algorithm which supports network scaling of the bitstream in three bitrates: 48, 56 and 64 kbit/s. To support this functionality within the G.192 file format the G.722 encoder writes the 16 kbit/s embedded bits in the end of every G.192 bitstream frame.

For every 16 kHz sample, there are eight G.722 encoded bits (an octet index) to be transported in the G.192 frame. Bits b1 and b0 are the embedded bits and bits b2-b7 are the non-embedded bits. In a G.192 frame, the b2 bits are written first in chunk, followed by that of b3, until b7 bits. After all b7 bits are written, b1 bits are written and then b0 bits. By sorting bits in this manner, truncation of a G.192 type G.722 frame bitstream from 64 kbit/s to 48 or 56 kbit/s is made easy. Figure 15, Figure 16 and Figure 17 show how the G.192 frames are composed for various bit rates (64, 56, 48 kbit/s) and example frame sizes (10, 5, 20 ms). G.192 format is useful for enhanced simulation of G.722, however actual application transport formats may be different (e.g. as defined in [4] and as used in [18]).

Figure 15 — Example of a G.192 compatible G.722 encoder output frame for a 10 ms input frame size. This frame has a length of 640 bits and a G192_SYNC (0x6B21) header tag, in the G.192 file each g722 bit is stored as a 16 bit word.

Figure 16 — Example of a G.192 compatible G.722 56 kbit/s encoder output frame for a 5 ms input frame size. This frame has a length of 280 bits and a G192 SYNC (0x6B21) header tag.

Figure 17 — Example of G.192 compatible G.722 48 kbit/s encoder output frame for a 20 ms input frame size. This frame has a length of 960 bits and a G192 SYNC (0x6B21) header tag.

12.2.2.  Standalone G.722 Encoder specific operation

If the encoder can not read a complete input frame it stops its processing, this means that the final decoder output file may be up to a frame shorter than the input speech file.

12.3.1.  g722_encode

Syntax:

#include "g722.h"
long g722_encode (short _*inp_buf_, short _*g722_frame_, long _smpno_,
                  g722_state _*g722_encode_);

Prototype: g722.h

Description:

Simulation of the ITU-T G.722 64 kbit/s encoder. Takes the linear (16-bit, left-justified) input array of shorts inp_buf (16 bit, right-justified, without sign extension) with smpno samples, and saves the encoded bit-stream in the array of shorts g722_frame.

The state variables are saved in the structure pointed by g722_encode, and the reset can be established by making a call to g722_reset_encoder.

Variables:

inp_buf

Is the input samples' buffer with smpno left-justified 16-bit linear short speech samples.

g722_frame

Is the encoded samples' buffer; each short sample will contain the encoded parameters as right-justified 8-bit samples.

smpno

Is a long with the number of samples to be encoded from the input buffer inp_buf.

g722_encode

A pointer to the state variable structure; all the variables here are for internal use of the G.722 algorithm, and should not be changed by the user. Fields of this structure are described above.

Return value:

Returns the number of speech samples encoded.

12.3.2.  g722_decode

Syntax: