Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Question to someone who knows LAME source code (Read 2679 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Question to someone who knows LAME source code

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!

Question to someone who knows LAME source code

Reply #1
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?

Question to someone who knows LAME source code

Reply #2
Maybe because lame threw away all ISO code? Just guessing...
Error 404; signature server not available.

Question to someone who knows LAME source code

Reply #3
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...