FreeCalypso > hg > gsm-codec-lib
comparison doc/PCM8-conversions @ 236:4c7d0dc1eecb
doc/PCM8-conversions: finish encoding description
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Mon, 08 May 2023 03:28:40 +0000 |
| parents | 0ee1a66c1846 |
| children | e4a4bf11f37c |
comparison
equal
deleted
inserted
replaced
| 235:0ee1a66c1846 | 236:4c7d0dc1eecb |
|---|---|
| 99 * Mu-law encoding is the real hair-raiser: if the input to the to-be-implemented | 99 * Mu-law encoding is the real hair-raiser: if the input to the to-be-implemented |
| 100 encoder has 14 or more bits (including the most practical problem of 16-bit | 100 encoder has 14 or more bits (including the most practical problem of 16-bit |
| 101 2's complement input), there are no less than 3 different ways to implement | 101 2's complement input), there are no less than 3 different ways to implement |
| 102 this encoder! | 102 this encoder! |
| 103 | 103 |
| 104 Let us now look at the 3 different ways of encoding a 14-bit or 16-bit 2's | |
| 105 complement linear PCM input to G.711 mu-law. In this analysis we shall use | |
| 106 14-bit notation, with 2's complement inputs contained in the domain | |
| 107 [-8192,8191]. The difference between the 3 identified ways of mapping from this | |
| 108 domain to mu-law have to do with boundaries between quantization intervals. | |
| 109 Tables 2a and 2b in the G.711 spec list all defined quantization intervals and | |
| 110 all decision values that mark boundaries between them; here is a digested form | |
| 111 of the beginning of the canonical quantization table for either side of zero: | |
| 112 | |
| 113 Quantization interval Quantized value | |
| 114 (range of magnitudes) (absolute) | |
| 115 --------------------------------------- | |
| 116 0-1 0 | |
| 117 1-3 2 | |
| 118 3-5 4 | |
| 119 ... | |
| 120 29-31 30 | |
| 121 31-35 33 | |
| 122 35-39 37 | |
| 123 ... | |
| 124 91-95 93 | |
| 125 95-103 99 | |
| 126 ... | |
| 127 | |
| 128 This canonical quantization table is defined in terms of absolute values, and | |
| 129 is therefore fully symmetric around zero. A careful look at the above table | |
| 130 raises a question: which quantization interval (and thus which PCMU octet | |
| 131 output) should be selected if the input value to the encoder has a magnitude | |
| 132 exactly equal to one of the threshold points, or decision values as they are | |
| 133 officially called? In other words, what should the encoder do if the magnitude | |
| 134 of the 14-bit input value equals 1, 3, 5, ..., 31, 35, 39 etc? The answer to | |
| 135 this question is where the 3 candidate mappings under our consideration differ: | |
| 136 | |
| 137 * The "compress" function of G.726 operating in mu-law mode selects the higher | |
| 138 (in absolute value) quantization interval at every decision value threshold, | |
| 139 on both sides of zero: see Table 15/G.726. PCMU octet 0x7F (meaning -0) will | |
| 140 never be emitted by this version, and an input sequence of -3, -2, -1, 0, 1, | |
| 141 2, 3 will map to quantized values -4, -2, -2, 0, 2, 2, 4. | |
| 142 | |
| 143 * The ulaw_compress() function in G.191 STL behaves like the G.726 version for | |
| 144 positive values, but selects the smaller-absolute-value quantization interval | |
| 145 for negative inputs. Given the same input sequence as above, the output will | |
| 146 correspond to quantized values -2, -2, -0, 0, 2, 2, 4. (Quantized value -0 | |
| 147 is PCMU octet 0x7F.) | |
| 148 | |
| 149 * The s2u[] table in toast_ulaw.c in libgsm source is flat-out wrong and should | |
| 150 not be used or considered further (and because those authors did not include | |
| 151 the source for whatever program they used to generate their broken s2u[] and | |
| 152 u2s[] tables, we have no way to really analyze them), but one CAN construct a | |
| 153 new table for the same function, using the upper 13 bits of 16-bit 2's | |
| 154 complement input to generate PCMU output - see our dev/s2u-regen.c program | |
| 155 and its output table in dev/s2u-regen.out. The resulting mapping is | |
| 156 "mirrored" around zero compared to G.191 STL ulaw_compress(): for the same | |
| 157 input sequence as in the previous two examples, the output will correspond to | |
| 158 quantized values -4, -2, -2, 0, 0, 2, 2. Just like the G.726 version, this | |
| 159 look-up table version will never emit PCMU octet 0x7F for -0. | |
| 160 | |
| 161 It is important to note that all GSM speech decoders produce 2's complement | |
| 162 outputs that are only 13 bits wide, not 14 - therefore, when the input to the | |
| 163 G.711 encoder comes from the output of a GSM speech decoder, the difference | |
| 164 between all 3 alternatives listed above is masked, with all 3 producing | |
| 165 identical output. | |
| 166 | |
| 167 For production software, our (Themyscira) recommendation is to use look-up | |
| 168 tables (dev/s2a-regen.out and dev/s2u-regen.out) for both A-law and mu-law | |
| 169 encoding, using the upper 12 bits from 16-bit 2's complement input for A-law | |
| 170 encoding and the upper 13 bits for mu-law encoding. |