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: what is the 'LAME.3.99.5' used for at the end of encoded data (Read 7693 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

what is the 'LAME.3.99.5' used for at the end of encoded data

I have noticed that at the end of some frames encoded using the lame API, the bytes 'LAME3.99.5' is inserted in the data stream, then there are what appears to be fill data. Sometimes the fill data is a sequence of 0xaa bytes and other times it is a sequence of 0x55 bytes.

Q1: what is the significance of the 'LAME3.99.5' in the encoded data?  can I assume that it is a sort of end-of-encoded-data marker and that everything following it can be removed?

Q2: what is the difference between 0xaa and 0x55 fill bytes? 

Q3: if the fill bit is set in the MP3 header and there are these fill bytes at the end of the encoded data, can I remove them without violating the standard?
Q4: if so, is there an alignment requirement?  that is, the frame has to be an even number of bytes, or multiple of 4 bytes, etc. ??

Thanks,

-Andres

what is the 'LAME.3.99.5' used for at the end of encoded data

Reply #1 –
Don't you think that before starting to work with mp3 streams, you should get familiarized, at least, with what an MP3 stream is?

MP3 is build up of multiple individual packets called frames. Each frame has a header, some data, and then it might contain "ancillary data". The packets can only be of a reduced group of sizes, which in the end determine the valid CBR bitrates ( 64kbps, 128, 192, 320, etc..)

http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm  <- See the part where it mentions How to calculate frame length


As for the text "LAME3.99" and the padding bytes, you cannot remove them. Said that, you can alter them in whichever way you want. As said above, in a frame there is the header, the data, and the ancillary data. The ancillary data can be data of future frames, or simply be unused bytes.
When LAME writes there its name and padding bytes, it simply didn't find anything useful to fill them with, but the packet HAS to be of a fixed size.

what is the 'LAME.3.99.5' used for at the end of encoded data

Reply #2 –
Quote from: [JAZ] on

Don't you think that before starting to work with mp3 streams, you should get familiarized, at least, with what an MP3 stream is?


You are absolutely right. Please forgive me if I ask stupid or newbe questions.  I am trying to come up to speed on mp3 as fast as I can, but I am struggling.  I am reading all I can find about it and asking questions here where you guys are the experts, but it is taking some time for all of this to sink into me.  MP3 is apparently very different from H.263/H.264/H.265 video encoding/streaming of which I am more familiar and experienced.

Quote
MP3 is build up of multiple individual packets called frames. Each frame has a header, some data, and then it might contain "ancillary data".

This I understand

Quote
The packets can only be of a reduced group of sizes, which in the end determine the valid CBR bitrates ( 64kbps, 128, 192, 320, etc..)
http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm  <- See the part where it mentions How to calculate frame length
As for the text "LAME3.99" and the padding bytes, you cannot remove them. Said that, you can alter them in whichever way you want. As said above, in a frame there is the header, the data, and the ancillary data. The ancillary data can be data of future frames, or simply be unused bytes.
When LAME writes there its name and padding bytes, it simply didn't find anything useful to fill them with, but the packet HAS to be of a fixed size.

This part I did not understand well.  Thank you for the reference.  I thought that CBR constrained the *encoder* on what it would compress to or the data stream it would produce. I did not think that the *decoder* was expecting only fixed size frames.

-Andres