1 [ comments on fixes to lower sampling frequencies 7   encoder by Seymour Shlien, to appear in dist09. Jon ]   * Here is a log of the bugs I have found and. corrected as well as those I would like to see corrected.  -- Seymour       / Problem: The scalefac's in layer 3 are always 0  for all scale factor bands.   * It was noticed that the parameter ratio in- passed to iteration_loop was always the same. 1 The array ratio is computed by the psychoacoustic  model L3psycho_anal.  / In L3psycho_anal (l3psyc.c) it was noticed that 0 all the variables (arrays) used to compute ratio- (en,thm,eb,thr) were not changing. In fact no - energy was coming out of the fft at line 479. - In fact savebuf was all 0's. In fact syncsize ) was 0 preventing savebuf to be filled and 2 used in the fft. In fact the code for initializing. syncsize was #ifdef out in lines 159 to 176 of l3psyc.c  0 When I put the code back in, the program crashed2 at line 169 where the function read_absthr(absthr,.  sfreq_idx) was called. It crashed because the- array absthr was not allocated, because  line * 152 /* absthr = (FLOAT *) mem_alloc(..) */ was commented out.      - Once the psychoacoustic model was reactivated - a whole new set of problems appeared. I guess 6 there was a reason for deactivating the psychoacoustic% model. The following output appeared.   # encode -l 3 -p 2 /ldisk/bascl_4.raw  Encoding configuration:  Algorithm=MPEG-1. Layer=III   mode=stereo   extn=0   psy model=2* samp frq=44.1 kHz   total bitrate=320 kbps, de-emph=0   c/right=0   orig=0   errprot=offH input file: '/ldisk/bascl_4.raw'   output file: '/ldisk/bascl_4.raw.mpg' slots/frame = 10445 frac SpF=0.898, tot bitrate=320 kbps, s freq=44.1 kHz , Fractional number of slots, padding required, {   0}absthr[][] sampling frequency index: 1. {   1}{   2}Sent 8348 bits = 1043 slots plus 4( {   3}Sent 8348 bits = 1043 slots plus 4( {   4}Sent 8348 bits = 1043 slots plus 4( {   5}Sent 8348 bits = 1043 slots plus 4( {   6}Sent 8348 bits = 1043 slots plus 4( {   7}Sent 8348 bits = 1043 slots plus 4  1 First the bitstream formatter started to complain 7 that bitstream produced did not end on a byte boundary.   = Secondly, when running the decoder there was an inconsistency 4 on where the last main_data_block ended and the next% main_data_block began as shown below:   ) rigel% decode /ldisk/bascl_4.raw.mpg junk ; Input file = '/ldisk/bascl_4.raw.mpg'  output file = 'junk' ; the bit stream file /ldisk/bascl_4.raw.mpg is a BINARY file O HDR: s=FFF, id=1, l=3, ep=off, br=E, sf=0, pd=1, pr=0, m=0, js=0, c=0, o=0, e=0 2 alg.=MPEG-1, layer=III, tot bitrate=320, sfrq=44.1$ mode=stereo, sblim=32, jsbd=32, ch=2Q {   0}{   1}{   2}{   3}Not enough main data to decode frame 3.  Frame discarded. E {   4}{   5}Not enough main data to decode frame 5.  Frame discarded. E {   6}{   7}Not enough main data to decode frame 7.  Frame discarded. E {   8}{   9}Not enough main data to decode frame 9.  Frame discarded. F {  10}{  11}Not enough main data to decode frame 11.  Frame discarded.F {  12}{  13}Not enough main data to decode frame 13.  Frame discarded.F {  14}{  15}Not enough main data to decode frame 15.  Frame discarded.  0 Third, the value of part2_3_length in the header3 did not seem to be correct. Even when the number of 2 big values was zero and all the spectral intensity1 levels were zero, part2_3_length was still large. 1 (It was probably not correct before the changes.) - Part2_3_length is supposed to bethe number of : main_data bits used to encode the scalefactors and Huffman- code data. It does NOT include stuffing bits. 2 Part2_3_length is used to determine the end of the5 count1 region where quadruple Huffman codes are used. 2 Stuffing bits are supposed to be put at the end of3 the main_data, not interspersed inside the granules 
 and channels.   7 Finally, the code for selecting the correct global_gain ' and scalefactors was still not working.   / In summary the encoder was now worse than ever.   2 Examining the code and running some simulations, I beleive that in loop.c  5 (1) The starting value for quantizerStepSize returned 1 by quantanf_init, is too large so the outer_loop  4 inner_loop code does not operate properly. The value3 should be small and negative so that initially more 2 bits than are allowed are used to encode the data.2 The inner_loop then starts increasing the value of7 quantizerStepSize until the desired bitrate is achieved : for the particular set of scalefacs chosen by outer_loop.     : (2) The main_data reservoir is being misused for something: as the conflict between where the last maindata block area4 ends and the new one starts has something to do with0 the maindata end parameter in the header block.   / (3) When scalefactors are actually transmitted, 7 (ie scalefac_compress not 0)  allowance for there space 5  may not be done properly causing the interation_loop 6 software to allocate non integer number of bytes which! the bitformatter does not like.     3 (4) part2_3_length is probably being used properly.         > I observed that the function part2_length() in the file loop.c> which computes the number of bits to encode the scale factors,) has an  error for the default case. There 4 are 21 scale factor bands not 24 scale factor bands.$ The corrected lines are shown below.  ?    600              if ( (gr == 0) || (si->scfsi[ch][0] == 0) ) ,    601                  bits += (6 * slen1);    602  ?    603              if ( (gr == 0) || (si->scfsi[ch][1] == 0) ) M    604                  /* bits += (6 * slen1);  This is wrong SS 19-12-96 */ ,    605                  bits += (5 * slen1);    606  ?    607              if ( (gr == 0) || (si->scfsi[ch][2] == 0) ) M    608                  /* bits += (6 * slen1);  This is wrong SS 19-12-96 */ ,    609                  bits += (5 * slen2);    610  ?    611              if ( (gr == 0) || (si->scfsi[ch][3] == 0) ) M    612                  /* bits += (6 * slen1);  This is wrong SS 19-12-96 */ ,    613                  bits += (5 * slen2);    G Miraculously, after placing these changes two problems were eliminated. D The bitstream formatter stopped sending its warning messages and theH decoder was able to decode the file without error messages. Incredible !    D The iteration_loop code was still not working very well as a result B the scalefactors were still not properly used. A simple fix is to > change the return value from quantanf_init to something lower.  E In loop.c, changing lines 307-308 provided a more reasonable starting G value for the optimization resulting in the usuage of the scalefactors, # but the encoder runs even slower.       ;    299          sfm = exp( sum1 / 576.0 ) / (sum2 / 576.0); 5    300          tp = nint( system_const * log(sfm) ); $    301          if ( tp < minlimit )"    302              tp = minlimit;    303  #ifdef DEBUG?    304          printf(" quantanf = %d (quantanf_init)\n",tp );     305  #endif
    306      } (    307  /*    return(tp); SS 19-12-96 */    308        return(tp-60.0);	    309  }     G The optimization procedure described in the standard is computationally 8 slow and this is the main bottle neck in the encoder. MyI code for speeding up the process was not implemented in this distribution * despite the comments in the documentation.  > I have re-implemented the binary search procedure into loop.c,? however, I am not too sure whether it runs faster. I shall need ; to do more testing. It is probably running more accurately.   ? I observed that ResvFrameEnd() in reservoir.c adds and includes A stuffingBits into gi->part2_3_length. I have not changed the code 3 to fix this problem since it is more major surgery.    = It is quite difficult to find things in the loop.c sources. I C have edited it to improve its appearance and make all the functions  stand out more clearly.       > There is an unresolved problem with the outer_loop/inner_loop = algorithm in loop.c. Though the code is in agreement with the D specification in the normative section of the 11172-3 ITU standard, ? it does not seem to operate properly all the time in particular A when the desired bit rate is low. Essentially, amp_scalefac_bandsiD function raises the scale factors in order to lower the quantization> noise in particular scale factor bands, but when inner_loop is8 called to bring back the bit rate to the specified valueE all of this work is undone. Frequently when the algorithm terminates,y= the noise in the particular scalefac bands was not reduced bya; much or even increased and more noise was introduced in theeC other scalefac bands due to the additional overhead of transmittingo8 the scalefactors. As a result this code does not seem to? accomplish much in improving the overall quality of the encodedr signal.   C It is left as a research topic to find a more efficient algorithm.  ; (I have left some debugging code enclosed by #ifdef PERFORMi4 in loop.c in order to investigate this problem.)        c   Seymour Shlien Communications Research Centre Ottawa, Ontario, Canadac K2H 8S2n   voice (613) 998-2551    e-mail seymour.shlien@crc.doc.ca