📄 readme
字号:
Dear Tony RobinsonRecently I retrieved the routines for the CCITT G.711 standardfrom the ftp server at Cambridge University.I noticed a remark "Thoughly tested by ajr and believed bug free.", and I am therefore e-mailing you since I have found some (minor) bugs in these routines. These are described below.I am enclosing an updated version of these routines and a main programfor their inclusion. If you agree with my comments and updating you are very welcome to replace theexisting routines with these. I assume several people have applied these routines for conversion, so maybe it would be a good idea to notify the relevant news groups, but I will let you to decide on that.With the very best wishes Borge Lindberg Bugs in g.711 routines:-----------------------Tables for A-law /u-law conversion:-----------------------------------_u2a /* u- to A-law conversions */: 81, 82, 83, 84, 85, 86, 87, 88, should be 80, 82, 83, 84, 85, 86, 87, 88,_a2u[128] /* A- to u-law conversions */: 73, 74, 75, 76, 77, 78, 79, 79, should be 73, 74, 75, 76, 77, 78, 79, 80,The bugs found in the routines below, never occur on quantized 16 bitdata (data originating from a prior A- og u-law to linear conversion).function linear2alaw:----------------------Generates wrong A-law value for linear input values in the range [-7 .. -1].Segment numbers are found from full range values. This has to be changedto 13-bit range values - otherwise a linear2alaw - alaw2linear - linear2alawsequence is not guaranteed to give identical A-law values.function linear2ulaw:----------------------Generates wrong u-law values for linear input values having numericvalue above 32635 since clipping is omitted and results in somethinglike wrap-around.Segment numbers are found from full range values. This has to be changedto 14-bit range values - otherwise a linear2ulaw - ulaw2linear - linear2ulawsequence is not guaranteed to give identical u-law values.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -