view doc/EFR-testing @ 585:3c6bf0d26ee7 default tip

TW-TS-005 reader: fix maximum line length bug TW-TS-005 section 4.1 states: The maximum allowed length of each line is 80 characters, not including the OS-specific newline encoding. The implementation of this line length limit in the TW-TS-005 hex file reader function in the present suite was wrong, such that lines of the full maximum length could not be read. Fix it. Note that this bug affects comment lines too, not just actual RTP payloads. Neither Annex A nor Annex B features an RTP payload format that goes to the maximum of 40 bytes, but if a comment line goes to the maximum allowed length of 80 characters not including the terminating newline, the bug will be triggered, necessitating the present fix.
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 25 Feb 2025 07:49:28 +0000
parents 1e8569000049
children
line wrap: on
line source

When it comes to codec libraries, testing for correctness is essential, and EFR
is no exception.  There is a set of EFR encoder and decoder test sequences
published by ETSI in ts_100725v050200p0.zip (GSM 06.54), and our suite of tools
includes gsmefr-etsi-enc and gsmefr-etsi-dec test programs that operate on the
representation formats used by these test sequences.  Because these test
programs are based on libgsmefr EFR_encode_frame() and EFR_decode_frame()
functions, seeing gsmefr-etsi-enc produce output that matches official ETSI
*.cod files proves that libgsmefr encoder is correct, and seeing gsmefr-etsi-dec
produce output that matches official ETSI *.out files proves that libgsmefr
decoder is correct.

For debugging, we also have gsmefr-cod-parse and gsmefr-dec-parse utilities that
parse ETSI *.cod and *.dec file formats and dump their content in human-readable
form similar to gsmrec-dump.

Please note that all ETSI test sequence file formats are endian-dependent: their
original programs read and write 16-bit words in the local machine's native byte
order, and whenever you are working with published test sequence files, you have
to check to see if they are BE or LE.  Our gsmefr-etsi-{enc,dec} and
gsmefr-{cod,dec}-parse programs support both byte orders; the default is LE
(matching the main parts of ts_100725v050200p0.zip), or you can select BE with
-b option.