A.2 Description of digital test sequences
3GPP46.032Full rate speechRelease 17TSVoice Activity Detector (VAD) for full rate speech traffic channels
A.2.1 Test sequences
The VAD algorithm uses results from the full rate speech encoder defined in GSM 06.10. In the testing of the VAD, it is assumed that the relevant speech encoder functions have been verified by the test sequences defined in GSM 06.10.
The five types of input sequences are briefly described below.
Spectral comparison
The two kinds of statements of the spectral comparison algorithm (subclause 3.4), arithmetic statements and control statements, are tested by separate test sequences.
Arithmetic statements:
spec_a1.*
spec_a2.*
Control statements
spec_c1.*
spec_c2.*
spec_c3.*
spec_c4.*
Threshold adaptation
There are two types of tests to verify the threshold adaptation described in subclause 3.6:
adapt_i1.*
adapt_i2.*
The initial test sequences test the acf0 and VAD decision. A fault in the VAD decision will cause all the other sequences to fail, so it is recommended that this test is run before all other tests.
adapt_m1.*
adapt_m2.*
The main test sequences will check the basic threshold adaptation mechanism.
Periodicity detection
pitch1.*
pitch2.*
These sequences check the periodicity detection algorithm described in subclause 3.5.
Tone detection
The tone detector test sequences are only required for downlink VAD implementations. There are three types of test to verify the tone detection algorithm described in subclause 3.10. The first test sequence tests the operation of the tone detector by means of a frequency sweep:
freq_sw.*
The following test sequences test the prediction gain calculation within the tone detector:
pred1.*
pred2.*
The following sequences test the second order pole frequency calculation within the tone detector:
pole1.*
pole2.*
"Safety" and initialization
safety.*
This sequence checks that safety tests have been implemented to prevent zero values being passed to the norm function. It checks the functions described in the Adaptive Filtering and Energy Computation subclause (subclause 3.1), and the Predictor Values Computation (subclause 3.3). This sequence also checks the initialization of thvad and the rvad array.
Real speech
good_sp.*
bad_sp.*
Because the test sequences cannot be guaranteed to find every possible error, there is a small possibility that an implementation of the correct output for test sequences, but fail with real speech. Because of this, an extra set of sequences are included that consist of barely detectable speech and very clean speech.
There are 3 different file extensions:
*.inp: speech encoder input sequences, binary files
*.vad: output flag of the VAD algorithm, ASCII files
*.cod: TX DTX handler output sequences, binary files for comparison with VAD/DTX handler output.
The *.cod files contain speech coder output information in the format described in clause 4.
It should be noted that there is no requirement in GSM 06.12 for a bit exact implementation of the averaging procedure to calculate the "LAR" and "xmax" parameters in the SID frames. Different implementations are allowed.
The algorithms used for the calculation of the LAR and xmax parameters of the SID frames are therefore reproduced below:
LAR averaging:
| FOR i = 1 to 8:
| L_Temp = 2; /* const. for rounding*/
| | FOR n = 1 to 4:
| | L_Temp1 = LAR[j‑n](i); /*conversion 16 ‑‑> 32 bit*/
| | L_Temp = L_Add( L_Temp , L_Temp1 );
| | NEXT n
| L_Temp = L_temp >> 2;
| mean (LAR(i)) = L_Temp; /*conversion 32 ‑‑> 16 bit*/
| NEXT i;
xmax averaging
L_Temp = 8; /* const. for rounding*/
| FOR n = 1 to 4:
| | FOR i = 1 to 4:
| | L_Temp1 = xmax[j‑n](i); /*conversion 16 ‑‑> 32 bit*/
| | L_Temp = L_Add( L_Temp , L_Temp1 );
| | NEXT i
| NEXT n
L_Temp = L_Temp >> 4;
mean (xmax) = L_Temp; /*conversion 32 ‑‑> 16 bit*/
A.2.2 File format description
All the *.inp and *.cod files are written in binary using 16 bit words, while all *.vad files are written in ASCII format. The sizes of the files are shown in table A.2.1, A.2.2 and A.2.3. The detailed format of the *.inp and *.cod files is in accordance with the descriptions given in GSM 06.10 clause 5.
Table A.2.1: File sizes for *.inp extension files
File: |
Frames: |
Size in bytes: |
spec_a1.inp |
22 |
7 040 |
spec_a2.inp |
22 |
7 040 |
spec_c1.inp |
48 |
15 360 |
spec_c2.inp |
48 |
15 360 |
spec_c3.inp |
48 |
15 360 |
spec_c4.inp |
48 |
15 360 |
adapt_i1.inp |
67 |
21 440 |
adapt_i2.inp |
48 |
15 360 |
adapt_m1.inp |
403 |
128 960 |
adapt_m2.inp |
376 |
120 320 |
pitch1.inp |
35 |
11 200 |
pitch2.inp |
35 |
11 200 |
freq_sw.inp |
560 |
179 200 |
pred1.inp |
126 |
40 320 |
pred2.inp |
126 |
40 320 |
pole1.inp |
97 |
31 040 |
pole2.inp |
42 |
13 440 |
safety.inp |
5 |
16 00 |
good_sp.inp |
312 |
99 840 |
bad_sp.inp |
312 |
99 840 |
Table A.2.2: File sizes for *.cod extension files
File: |
Frames: |
Size in bytes: |
spec_a1.cod |
22 |
3 344 |
spec_a2.cod |
22 |
3 344 |
spec_c1.cod |
48 |
7 296 |
spec_c2.cod |
48 |
7 296 |
spec_c3.cod |
48 |
7 296 |
spec_c4.cod |
48 |
7 296 |
adapt_i1.cod |
67 |
10 184 |
adapt_i2.cod |
48 |
7 296 |
adapt_m1.cod |
403 |
61 256 |
adapt_m2.cod |
376 |
57 152 |
pitch1.cod |
35 |
5 320 |
pitch2.cod |
35 |
5 320 |
freq_sw.cod |
560 |
85 120 |
pred1.cod |
126 |
19 152 |
pred2.cod |
126 |
19 152 |
pole1.cod |
97 |
14 744 |
pole2.cod |
42 |
6 384 |
safety.cod |
5 |
760 |
good_sp.cod |
312 |
47 424 |
bad_sp.cod |
312 |
47 424 |
Table A.2.3: File sizes for *.vad extension files
File: |
Frames: |
Size in bytes: |
spec_a1.vad |
22 |
88 |
spec_a2.vad |
22 |
88 |
spec_c1.vad |
48 |
192 |
spec_c2.vad |
48 |
192 |
spec_c3.vad |
48 |
192 |
spec_c4.vad |
48 |
192 |
adapt_i1.vad |
67 |
268 |
adapt_i2.vad |
48 |
192 |
adapt_m1.vad |
403 |
1 612 |
adapt_m2.vad |
376 |
1504 |
pitch1.vad |
35 |
140 |
pitch2.vad |
35 |
140 |
freq_sw.inp |
560 |
2 240 |
pred1.vad |
126 |
504 |
pred2.vad |
126 |
504 |
pole1.vad |
97 |
388 |
pole2.vad |
42 |
168 |
safety.vad |
5 |
20 |
good_sp.vad |
312 |
1 248 |
bad_sp.vad |
312 |
1 248 |