Question to someone who knows LAME source code, Strange reordering happens in count1 values Options

[Istrebitel]

Greetings!

I am toying with LAME source code to do some MDCT coefficients manipulation. I noticed something very strange. Count1 bits are shuffled around between input and output.

I am using CBR part of LAME at 320kbits.
In module quantize.c in function CBR_iteration_loop after iteration_finish_one I output to console a number of last values from MDCT coefficients (exactly - from #406 to #566)
In decoding algorithm (stnadart ISO decoder) once again i output those values.

For example:
Values during input:
3 2 2 0 1 1 1 0 4 0 3 2 0 0 1 1 0 0 0 0 1 0 0 0 (zeroes)
Values during output:
3 2 2 0 1 1 1 0 4 0 3 2 1 1 0 0 0 0 0 0 0 0 0 1 (zeroes)

So, from my POV, Count1 values are in the wrong order.

Moreover:
On input side, bigvalues = 210, count1 = 2, rzero = 74
On output side, bigvalues = 209, count1 = 3, rzero = 73

Maybe on input side something happens with granule's MDCT valeus after iteration_finish_one(gfc, gr, ch);
Or maybe something else happens somewhere i dont know?

Thanks for any help in advance!

[Istrebitel]

PS: I think i found the problem source. In the ISO decoder, huffman.c, there is such place

/* v, w, x and y are reversed in the bitstream.
switch them around to make test bistream work. */
//{int i=*v; *v=*y; *y=i; i=*w; *w=*x; *x=i;} //MI */

The line is (was) commented. I noticed that when using 8hz encoder (which is closely based on ISO default encoder), this line is required, otherwise count1 are in wrong order. So i uncommented this line.
Now, it seems that for LAME, it should stay commented.
Why so?

[hlloyge]

Maybe because lame threw away all ISO code? Just guessing...

[Istrebitel]

Well, i checked with Audacity, it produces the same wave file as default ISO decoder with the code commented.
So it seems that ISO base encoder code was corrupted in some way and ordered count1 values in wrong order, and 8hz inherited those flaws...