LAME MP3 file trailers

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

LAME MP3 file trailers

Reinier Bakels
Hello,
I found that MP3 files created by LAME code (running under Audacity) contain a trailer which contains the word LAME, at varying displacements from the end of the file. But I did not find any information on this trailer. Yes, I am aware that there LAME information too in the first MP3 frame (after the ID3 meta-data, if any) which closely resembles Xing data for VBR files. But I did not manage to calculate the address of the trailer from this information.
Eventually, my purpose is to find the address of the last actual MP3 frame (n order to verify the integrity of MP3 files).
Thanks in advance!
Reinier Bakels
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: LAME MP3 file trailers

Reinier Bakels
> The text LAME is not only used to identify the encoder but also as the
> content used when padding is needed. Instead of adding random data or
> zeroes,  it > adds that text.
> As such, it can be at any place (depending on the padding needed)

Thanks for the quick reply. But then the question why LAME pads at all.

Normally MP3 files end with an ID3V1 tag and/or an APE tag, or none of the
two. Preceding these trailing tags usually is the last MP3 frame (starting
with eleven '1' bits). The size of MP3 follows from the information in its
(4 byte) header. In fixed bit rate files, the size ofall the frames is the
same, +/- 1 depending on padding.

The text "LAME3.99.3" is typically close to the end of the file, followed by
a series of hexadecimal 0xAA characters, or hexadecimal 0x55 (ASCII 'U')
characters. After these characters, there often appears to follow another,
shorter MP3 frame (starting with eleven '1' bits).

Again, my purpose is to check the integrity of MP3 files. With my present
knowledge, I cannot do that for MP3 files written by LAME. Please help!

reinier


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: LAME MP3 file trailers

Reinier Bakels
In reply to this post by Reinier Bakels
> The text LAME is not only used to identify the encoder but also as the
> content used when padding is needed. Instead of adding random data or
> zeroes,  it > adds that text.
> As such, it can be at any place (depending on the padding needed)

I did some further investigations. Indeed the characters 'LAME' appear
numerous times in a MP3 file created by LAME.
It appears that if I use the values contained in the 'Info'/'LAME' structure
in the first frame (notably the net file size), I get consistent results
*IF* I assume that there may be extra  bytes at the end without meaning,
where the number of extra bytes = the actual file size the size of any ID3
meta-information in the beginning of the file.
Sometimes the extra bytes are binary zero, sometimes they start like a
regular MP3 frame, but they are much shorter.

IN SUM MY QUESTION IS: Is it true indeed that LAME may add some meaningsless
bytes at the end? (typically less than 200).

Remember my objective was to check file integrity - then extra bytes at the
end are confusing.

Sorry, perhaps I was too early with my previous response ...

reinier


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: LAME MP3 file trailers

Josep Maria Antolin
I don't know the internals enough to answer that, but there are a couple of
things that you should remember:

First, the Xing/LAME header has some info about the file. With VBR files,
the Xing original format is maintained for compatibility, and then adds
data that corresponds to LAME. With CBR files, it directly has a LAME
header. This data includes gapless information (i.e. how much the decoder
has to cut at the beginning and at the end to ensure the decoded audio has
the same length than the input) and other somewhat useful settings.

Also, I am not sure if you're testing VBR files, in which the end frame can
perfectly be smaller than the previous frames, just because most of the
time it will be encoding silence or near-silence.

Another thing that might happen is that it is using a short block, since a
short block is... ehem... shorter (in time duration).

Back in the days, there used to be a couple of programs that checked the
integrity of files. They checked for correct layer format, undecodeable
chunks, and incomplete chunks.
Since each chunk is of one of the 16 possible types, its size in bytes is
predetermined. The only thing that VBR does is allowing different types
during the stream (and so, different sizes which make the bitrate
fluctuate).

Also, I am not sure now if audacity adds tagging to the file, and if that
tagging is made by lame, or by Audacity. Maybe you should also test with
the lame commandline to verify you get the same result.


2014-09-11 11:32 GMT+02:00 Reinier Bakels <[hidden email]>:

> The text LAME is not only used to identify the encoder but also as the
>> content used when padding is needed. Instead of adding random data or
>> zeroes,  it > adds that text.
>> As such, it can be at any place (depending on the padding needed)
>>
>
> I did some further investigations. Indeed the characters 'LAME' appear
> numerous times in a MP3 file created by LAME.
> It appears that if I use the values contained in the 'Info'/'LAME'
> structure in the first frame (notably the net file size), I get consistent
> results *IF* I assume that there may be extra  bytes at the end without
> meaning, where the number of extra bytes = the actual file size the size of
> any ID3 meta-information in the beginning of the file.
> Sometimes the extra bytes are binary zero, sometimes they start like a
> regular MP3 frame, but they are much shorter.
>
> IN SUM MY QUESTION IS: Is it true indeed that LAME may add some
> meaningsless bytes at the end? (typically less than 200).
>
> Remember my objective was to check file integrity - then extra bytes at
> the end are confusing.
>
> Sorry, perhaps I was too early with my previous response ...
>
> reinier
>
>


--
_ _ /~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-\
o o | Josep Mª [JAZ]                 |
 º  | Messenger: [hidden email] |
`-´ | Gtalk: [hidden email]       |
    \-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~/
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: LAME MP3 file trailers

Reinier Bakels
Thanks for the quick reply.
Actually I am testing fixed bit rate files. So the apparent short frame at
the end is probably not meant to be a frame at all. Furthermore, such a
short frame only appears occasionally. On other occasions, I found different
paddings, like all-zero.
The Xing/Info header appears to provide the needed information *if* the
assumption is right that there may be some insignificant rubbish at the end.
I have no indication that Audacity adds anything but I may enquire.
reinier

----- Original Message -----
From: Josep Maria Antolin
To: Reinier Bakels
Cc: lame
Sent: Thursday, September 11, 2014 11:56 AM
Subject: Re: [Lame-dev] LAME MP3 file trailers


I don't know the internals enough to answer that, but there are a couple of
things that you should remember:


First, the Xing/LAME header has some info about the file. With VBR files,
the Xing original format is maintained for compatibility, and then adds data
that corresponds to LAME. With CBR files, it directly has a LAME header.
This data includes gapless information (i.e. how much the decoder has to cut
at the beginning and at the end to ensure the decoded audio has the same
length than the input) and other somewhat useful settings.


Also, I am not sure if you're testing VBR files, in which the end frame can
perfectly be smaller than the previous frames, just because most of the time
it will be encoding silence or near-silence.


Another thing that might happen is that it is using a short block, since a
short block is... ehem... shorter (in time duration).


Back in the days, there used to be a couple of programs that checked the
integrity of files. They checked for correct layer format, undecodeable
chunks, and incomplete chunks.

Since each chunk is of one of the 16 possible types, its size in bytes is
predetermined. The only thing that VBR does is allowing different types
during the stream (and so, different sizes which make the bitrate
fluctuate).



Also, I am not sure now if audacity adds tagging to the file, and if that
tagging is made by lame, or by Audacity. Maybe you should also test with the
lame commandline to verify you get the same result.





2014-09-11 11:32 GMT+02:00 Reinier Bakels <[hidden email]>:

The text LAME is not only used to identify the encoder but also as the
content used when padding is needed. Instead of adding random data or
zeroes,  it > adds that text.
As such, it can be at any place (depending on the padding needed)


I did some further investigations. Indeed the characters 'LAME' appear
numerous times in a MP3 file created by LAME.
It appears that if I use the values contained in the 'Info'/'LAME' structure
in the first frame (notably the net file size), I get consistent results
*IF* I assume that there may be extra  bytes at the end without meaning,
where the number of extra bytes = the actual file size the size of any ID3
meta-information in the beginning of the file.
Sometimes the extra bytes are binary zero, sometimes they start like a
regular MP3 frame, but they are much shorter.

IN SUM MY QUESTION IS: Is it true indeed that LAME may add some meaningsless
bytes at the end? (typically less than 200).

Remember my objective was to check file integrity - then extra bytes at the
end are confusing.

Sorry, perhaps I was too early with my previous response ...

reinier





--
_ _ /~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-\
o o | Josep Mª [JAZ]                 |
 º  | Messenger: [hidden email] |
`-´ | Gtalk: [hidden email]       |
    \-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~/


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev