home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
g
/
bugs.stl
next >
Wrap
Text File
|
1994-11-03
|
6KB
|
200 lines
Compilation of bug reports for the STL92 Compilation of bug reports for the STL92 Compilation of bug reports for the STL92
After the distribution of the STL92, several "bugs" were reported.
This is a complete list of bugs so far discovered.
STL92 MANUAL STL92 MANUAL STL92 MANUAL
>HQ Filters impulse response
Figure 3.8 shows the impulse response for the high-quality
(FIR) filters, and many users expected this figure to be symetric
(see Figure 3.7 of the Manual). Because of the decimation process,
the figure is asymetric, what caused many inquires by misled
users. A note should be added to the figure in a new release of
the manual to clarify the issue.
> Example in Chapter 3
PKI found an error in the example program in page 38 of the
Chapter 3, "Rate Change", of the STL92 Manual. Instead of:
| /* Convert to dB */
| H_k = 10 * log10(H_k / (double) (out_size - 4 * N)) -
inp_pwr;
it should be
| H_k = 10 * log10(H_k / (double) (out_size - 2 * N)) -
inp_pwr;
because the loop goes from 2*N to outsize-2*N.
> FIR filter equation
Also in the same Chapter, bottom of page 18, the first
equation should have "h" with index "i" instead of "k", thus
reading "h(i).x(k-i)".
> MNRU operation & DC levels
Although not a bug of the tools, it was discovered that
speech files with significant DC level have bad behaviour when
processed by the MNRU. This was found for both the UGST and CSELT
MNRU, and studies showed that it would happen in any scheme
following the specification the the CCITT Rec.P.81 [See
contribution from CPqD/Telebras sent to SQEG and to UGST in the
4th quarter of 1992]. In further versions of the STL Manual, a
word of warning should be put on this aspect.
> Changes to Chapter 6
Additionally, Mr.Mostafa Sherif (ATT) suggested a number of
changes in Chapter 6, on the G.721 module. The pages of the
chapter with his proposed changes are in Annex 3 of TD1 (XV/2,
Nov.92).
TOOLS TOOLS TOOLS:
>Module G721
CNET found an error in the synchronous coding adjustment
block for u law of the G.721 module, function " G721_sync()" in the
file " g721.c". The requested correction begins in line 2934,
replacing
| if (id > im && ss == 1 && mask == 127)
| ss = 0;
by
| if (id > im && ss == 1 && mask == 127)
| {
| ss = 0;
| mask--;
| }
because in this case, if SP=255 and ID>IM, the SD should be
127, instead of 126, according to table 2 of the G.721, Blue Book.
> HQDEMO and PCMDEMO
A bug was found by PKI in the print-out of parameters in the
demonstration programs for the HQFLT and PCMFLT modules, files
"hqdemo.c" and " pcmflt.c", when the program aborted under Turbo-
C++. No specific changes were suggest, but what is needed is to
change all the " %d" by " %ld" in printf() calls, when it refer to
"long" (instead of "short") integers.
> SV56DEMO.C
When printing results mixing longs and floats with printf,
a bug happened with Turbo/Borland-C++. As for the hqdemo and
pcmfltdemo, the solution is to replace all the %d by %ld when the
related variable is a long, not an int. This does not happen for
users in VMS and Unix.
> UGST-UTL.C
Two serious bugs have been found by PKI in the module ugst-
utl.c, affecting only speech data with resolutions different of
16-bits/sample.
The first one was in function function sh2fl() (conversion
of short samples to float) for bit resolutions other than 16 bits.
The piece of code is:
| /* Shift of left-adjusted samples to the desired
resolution */
| if (resolution != 16)
| {
| resolution = 16 - resolution;
| for (k = 0; k < n; k++)
| ix[k] >>= resolution;
| }
The suggested solution is given below:
| /* Shift of left-adjusted samples to the desired
resolution */
| if (resolution != 16)
| {
| long tmp = 16 - resolution;
| for (k = 0; k < n; k++)
| ix[k] >>= tmp;
| }
In the header file for this very module, it was found an
error in the macro fl2sh_14bit():
| #define fl2sh_14bit(n,x,y,r) fl2sh(n,x,y,r?2.0:0.0,0xFFFB)
and the solution:
| #define fl2sh_14bit(n,x,y,r)
fl2sh(n,x,y,r?2.0:0.0,(short)0xFFFC)
> XENCODE.C and XDECODE.C
Besides not being part of the distribution of the STL92,
these tools have been used for exchange of non-ASCII files during
the development of tools, and exchange of documents between
members of the UGST.
Problem have been found in transferring data when the
encoded file has trailing blanks, which some mailservers strip-
off. This causes an error ("short file") when decoding the files.
Another problem has been identified when transferring files
via X.25 between CPqD and FTZ when ASCII files got corrupted. This
shows the need for an error detection scheme (CRC or checksum) for
the program.