FreeCalypso > hg > gsm-codec-lib
view doc/PCM-file-formats @ 242:f081a6850fb5
libgsmfrp: new refined implementation
The previous implementation exhibited the following defects,
which are now fixed:
1) The last received valid SID was cached forever for the purpose of
handling future invalid SIDs - we could have received some valid
SID ages ago, then lots of speech or NO_DATA, and if we then get
an invalid SID, we would resurrect the last valid SID from ancient
history - a bad design. In our new design, we handle invalid SID
based on the current state, much like BFI.
2) GSM 06.11 spec says clearly that after the second lost SID
(received BFI=1 && TAF=1 in CN state) we need to gradually decrease
the output level, rather than jump directly to emitting silence
frames - we previously failed to implement such logic.
3) Per GSM 06.12 section 5.2, Xmaxc should be the same in all 4 subframes
in a SID frame. What should we do if we receive an otherwise valid
SID frame with different Xmaxc? Our previous approach would
replicate this Xmaxc oddity in every subsequent generated CN frame,
which is rather bad. In our new design, the very first CN frame
(which can be seen as a transformation of the SID frame itself)
retains the original 4 distinct Xmaxc, but all subsequent CN frames
are based on the Xmaxc from the last subframe of the most recent SID.
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Tue, 09 May 2023 05:16:31 +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. :-)