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: Lame part2_3_length (Read 3699 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame part2_3_length

Hi everybody.

Beforehand sorry for my bad english.

My question about lame source code.

There is struct : gr_info.
This struct has field : part2_3_length.

When data converted to mp3   function outer_loop called.

Quote
The outer iteration loop controls the masking conditions 
of all scalefactorbands. It computes the best scalefac and         
global gain.


In this function  exist so called inner_loop.

Quote
inner_loop starts with the initial quantization step computed above
  and slowly increases until the bits < huff_bits.


This inner_loop set part2_3_length.

Question :  when and where reverse action placed.
Where we compute part2_3_length when decode mp3.

For example, if  I manually set part2_3_length = 1, while encoding.
Where I can get this value when decoding.

Best regards …

Lame part2_3_length

Reply #1
I don't understand !!!
Dos't anybody from lame developer can't answer for my question ?

Lame part2_3_length

Reply #2
Question :  when and where reverse action placed.
Where we compute part2_3_length when decode mp3.

For example, if  I manually set part2_3_length = 1, while encoding.
Where I can get this value when decoding.

Are you trying to understand how to decode an mp3 file? If so, you should better look at the sources of a decoder, such as MAD.

Lame part2_3_length

Reply #3
ragod, part2_3_length is part of the side info block following the frame headers. It tells you how many bits are used per granule per frame for scalefactors and "huffman bits" (spectral data). I'm not sure whether this value is needed for decoding at all but it may help you checking the stream for consistency or partly recover synchronization after a bit error within the main data section.

Sebastian

Lame part2_3_length

Reply #4
@ragod
look at http://www.mp3-tech.org into the programmer's section. Under "Technical audio papers" you'll find some good documents to start with. I would suggest "MPEG Layer 3 Bitstream Syntax and Decoding".

Lame part2_3_length

Reply #5
Quote
Are you trying to understand how to decode an mp3 file? If so, you should better look at the sources of a decoder, such as MAD.


I don't know exactly how to decode an mp3 file.
But i see this at mp3Stego.
I explain my question.
I have to hide sicret message in mp3 data.
Mp3Stego do this work.

http://www.petitcolas.net/fabien/steganogr...tego/index.html

Quote
The hiding process takes place at the heart of the Layer III encoding process namely in the inner_loop. The inner loop quantizes the input data and increases the quantiser step size until the quantized data can be coded with the available number of bits. Another loop checks that the distortions introduced by the quantization do not exceed the threshold defined by the psycho acoustic model. The part2_3_length variable contains the number of main_data bits used for scalefactors and Huffman code data in the MP3 bit stream. We encode the bits as its parity by changing the end loop condition of the inner loop. Only randomly chosen part2_3_length values are modified


So, sicret bits hides in part2_3_length.
If part2_3_length % 2 = 0, then sic_bit = 0, else sic_bit = 1.

When we decode mp3, there is function III_hufman_decode
which compute part2_3_length, and we can extract sic_bit from this value.

My question, does some analogy for III_hufman_decode functon in Lame, where computes part2_3_length.

 

Lame part2_3_length

Reply #6
Unfortunately, I don't understand what you are asking for.
Please be more specific and/or tell us what it is that you are trying to do.