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?