Re: LAME MP3 file trailers

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 <[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