FreeCalypso > hg > gsm-codec-lib
view doc/PCM-file-formats @ 581:e2d5cad04cbf
libgsmhr1 RxFE: store CN R0+LPC separately from speech
In the original GSM 06.06 code the ECU for speech mode is entirely
separate from the CN generator, maintaining separate state. (The
main intertie between them is the speech vs CN state variable,
distinguishing between speech and CN BFIs, in addition to the
CN-specific function of distinguishing between initial and update
SIDs.)
In the present RxFE implementation I initially thought that we could
use the same saved_frame buffer for both ECU and CN, overwriting
just the first 4 params (R0 and LPC) when a valid SID comes in.
However, I now realize it was a bad idea: the original code has a
corner case (long sequence of speech-mode BFIs to put the ECU in
state 6, then SID and CN-mode BFIs, then a good speech frame) that
would be broken by that buffer reuse approach. We could eliminate
this corner case by resetting the ECU state when passing through
a CN insertion period, but doing so would needlessly increase
the behavioral diffs between GSM 06.06 and our version.
Solution: use a separate CN-specific buffer for CN R0+LPC parameters,
and match the behavior of GSM 06.06 code in this regard.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Thu, 13 Feb 2025 10:02:45 +0000 |
| parents | a217a6eacbad |
| children |
line wrap: on
line source
What file format should be used for 16-bit PCM sample recordings? The first (in the order of development) group of utilities in the present package that need to read and write such files are gsm[e]fr-encode and gsm[e]fr-decode, designed to mirror amrnb-enc and amrnb-dec from opencore-amr FOSS package; these utilities read and write WAV files and even use WAV reading and writing functions copied from opencore-amrnb test code. However, as I (Mother Mychaela) keep developing more tools, my use cases become more diverse: in some use cases WAV is most convenient (e.g., when playing or recording with SoX tools), but in other use cases a raw sample file without any header is much more convenient. To address this diversity of use cases, a pair of conversion utilities have been written: pcm16-raw2wav converts from raw format to WAV pcm16-wav2raw converts from WAV to raw format Both utilities take a mandatory command line argument specifying the endian order for the raw format - there is no default. Going forward, I (Mother Mychaela) prefer big-endian format for raw PCM16 files: aside from it being the network byte order on the Internet, 16-bit and 32-bit numbers appear "naturally" in hex dumps in BE, but not in LE. Therefore, newly developed utilities will read and write PCM16 data in "robe" format - "robe" is English pronunciation play on "raw BE", and it is also the ritual garment worn by Themyscira telecom priestesses. :-)