Re: 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 <[email protected]>:

> 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: [email protected] |
`-´ | Gtalk: [email protected]       |
    \-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~/
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lame-dev