view doc/PCM-file-formats @ 423:cf90077b753c

twamr-tseq-enc: treat dribble input as non-fatal 3GPP VAD2 test sequences dt22.inp and dt23.inp have incomplete frames at the end, hence we need to ignore that dribble in a non-fatal manner in order to pass all tests.
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 07 May 2024 07:20:29 +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. :-)