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.