AMR_fixed_point.zip_AMR_fixed_point.zip_amr fixed_amr 定点_fft and

README.TXT for AMR speech encoder and decoder ETSI Release 7.4.0 ================================================================================ Installation ------------ Assuming all delivered files are in the same directory, issuing "make" or "make VAD=VAD1" on a Unix system compiles the source code and builds two standalone programs called "encoder" and "decoder" which use the ENS VAD option. To compile with the Motorola VAD, use "make VAD=VAD2" To compile with weighted MOPS count enabled use "make [VAD=VAD#] MODE=WMOPS". To verify the correct installation the files spch_unx.inp, spch_unx.cod, and spch_unx.out are provided for the ENS VAD option and the files spch_un2.cod and spch_un2.out for the Motorola VAD option. These files contain data in MSBbyte first order. The corresponding files spch_dos.* and spch_do2.* contain the same data in LSByte first order. A mode control file (allmodes.txt) is also supplied. To verify the encoder, use encoder -dtx -modefile=allmodes.txt spch_unx.inp tmp.cod or encoder -dtx -modefile=allmodes.txt spch_un2.inp tmp.cod for the ENS or the Motorola VAD option, respectively, and compare the output tmp.cod to spch_unx.cod or spch_un2.cod. To verify the decoder, use decoder spch_un2.cod tmp.out or decoder spch_unx.cod tmp.out for the ENS or the Motorola VAD option, respectively, and compare the output tmp.out to spch_unx.out or spch_un2.out. On LSByte first systems, spch_dos.*/spch_do2.* must be used instead of spch_unx.*/spch_un2.* A shell script "amr_chk.csh" is provided for Unix systems which performs these tests automatically. The command line syntax is as follows: amr_chk.csh [-vad2] unix for MSB first systems (such as SUN workstations), or amr_chk.csh [-vad2] dos for LSB first systems (such as Linux on a PC). By default, it is assumed that the executable was compiled with the ENS VAD option. To check the Motorola VAD version, the option "-vad2" must be given on the command line. Note that this verification procedure only performs a very basic installation verification and is not a proof of overall bitexact operation. Command line options for encoder program ---------------------------------------- The general syntax is encoder [options] amr_mode input_file bitstream_file or encoder [options] -modefile=mode_file input_file bitstream_file In the first case, amr_mode must be one of MR475, MR515, MR59, MR67, MR74, MR795, MR102, or MR122. In the second case, the text file mode_file must contain the mode names to be used (one line per speech frame, each line containing one of the mode names mentioned above). An example file iterating trhough all mode names is supplied (allmodes.txt). The following options are recognized: -dtx enables DTX operation Command line options for decoder program ---------------------------------------- The general syntax is decoder [option] bitstream_file output_file The following option is recognized: -rxframetype expect RX frame type instead of TX frame type in input file. This only useful for simulations with other components between encoder and decoder. File formats ------------ The encoder input and decoder output files contain are 8 kHz, 16 bit/sample data. The output file length is always a multiple of 320 bytes because of the frame length of 160 samples. The encoder will only process whole input frames, i.e. for input files whose length is not a multiple of 160 samples the last <size> - n*160 samples are not processed. The encoder output/decoder input files ("bitstream files") contain frames which are structured as follows: 1 word frame type 244 words encoded speech parameter bitstream (one bit per word, each word contains either 0x0001 or 0x0000), unused bits written as 0x0000 for modes < MR122 1 word mode information 4 words unused (written as 0x0000 by encoder) The frame type written by the encoder (TX frame type) can have one of the following values: 0x0000 TX_SPEECH (normal speech frame) 0x0001 TX_SID_FIRST (first SID frame after speech) 0x0002 TX_SID_UPDATE (SID update frame in DTX) 0x0003 TX_NO_DATA (empty frame in DTX) If invoked without the -dtx option, the encoder only produces type 0x0000 (TX_SPEECH) frames. The decoder normally accepts the output format and frame type produced by the encoder. However, using the option -rxframetype, it can be forced to expect frames with RX frame type instead of TX frame type. In that case, it can NOT directly read files produced by the encoder because the frame types do not match. The RX frame type coding is as shown below: 0x0000 RX_SPEECH_GOOD (normal speech frame) 0x0001 RX_SPEECH_PROBABLY_DEGRADED (probably degraded speech frame) 0x0002 RX_SPEECH_PROBABLY_BAD (probably bad speech frame) 0x0003 RX_SPEECH_BAD (bad [erased] speech frame) 0x0004 RX_SID_FIRST (first SID frame after speech) 0x0005 RX_SID_UPDATE (SID update frame in DTX) 0x0006 RX_SID_BAD (corrupted SID frame) 0x0007 RX_NO_DATA (no data received) The coding of the mode information field in the bitstream files is as follows: 0x0000 MR475 4.75 kbit/s 0x0001 MR515 5.15 kbit/s 0x0002 MR59 5.90 kbit/s 0x0003 MR67 6.70 kbit/s 0x0004 MR74 7.40 kbit/s 0x0005 MR795 7.95 kbit/s 0x0006 MR102 10.20 kbit/s 0x0007 MR122 12.20 kbit/s Motorola VAD ------------ Summary: Version 2.0.1 incorporates the Voice Activity Detector option 2. Either option 1 or option 2 can be compiled via the respective command "make VAD=VAD1" or "make VAD=VAD2". This package has been verified to be backward compatible with version 2.0.0. That is, version 2.0.0 encoder is bit-exact to version 2.0.1 when compiled with the VAD=VAD1 argument. It has also been verified that version 2.0.1 compiled with the VAD=VAD1 argument is bit-exact to version 2.0.1 compiled with the VAD=VAD2 argument when run in non-DTX mode. Only the vad_flag output of the vad2() function will affect the subsequent state of the encoder process. No other outputs are generated, nor are any encoder state variables directly modified by the use of the VAD2 option. The co-existence of the two VAD options is achieved through the use of conditional compiler directives. That is, for every instance where the existing code has been modified, there is a corresponding "#ifdef VAD2" where code has been added, and a corresponding "#ifndef VAD2" where code related to the VAD1 option is to be omitted. It should be noted that the conditional compile was purposefully triggered from a single define to avoid, for example, the cases where both (or neither) a VAD1 and/or VAD2 compiler directives were defined. Furthermore, the integration impact of the VAD2 option was kept to a minimum by allowing the typedef for the vadState structure to be dependent on the compiler directive. This was accomplished by "typedef-ing" vadState1 for VAD1, and vadState2 for VAD2, and then further defining the typedef to be used as: #ifndef VAD2 #define vadState vadState1 #else #define vadState vadState2 #endif The result is that very few mod