> 
> To all,
> 
> I'm not sure how to use this mailing list but I just
> got a message which was addressed to
> [EMAIL PROTECTED]
> so I hope that's the correct place to send.
> 
> Anyway, the point of this note is that I've been
> discussing with Jean Nicolle, (the author of MP3TRIM),
> how to eliminate space at the end of MP3s, here is an
> extract from one of the messages I received:
> 
> >>
> I checked the mp3 that you sent me and I found a lot
> of empty frames with this message inside:
> 'LAME3.80 (alpha 1)'
> After looking, I found an MP3 encoder named LAME:
> http://www.sulaco.org/mp3/
> 
> I'm not sure about the purpose of these empty frames,
> but they add 0.18 at the beginning and 3.16s of
> silence at the end of the sample track that you sent
> me!
> 
> Maybe by switching to a non-alpha version of LAME, you
> might be able to get rid of them.
> Anyway I've attached a beta version of mp3Trim that
> should allow you to fix manually your files. I
> improved the empty-frame detection to work on LAME
> frames.
> I'll probably leave that code in for the next releases
> of mp3Trim/PRO.
> 
> Let me know if that works.
> Jean
> >>
> 
> I did point out that the silence was in the wav file
> and was not added by LAME but that still leaves the
> question of why was the text in the empty frames to
> begin with?  Also the patched version worked with some
> of my files but not with others, probably encoded with
> another version. Does anyone know why this text is put
> into empty, (silent), frames and, if there is a
> reason, then will there always be some generic text
> that can be searched for?
> 
> Regards,
> Abe Corrie
> 

That text is in the ancillary data.  Some encoders fill the
ancillary data with 0's, some use 1's, and LAME happens to
use the version string.  

A reasonable approach would be to parse the frame headers and just
check if part2_3_length was zero for all the granules.  But some
encoders (not LAME) like to pad frames by putting 1's in the huffman
data (which decode to 0).  So mp3trim really should decode the huffman
data and check if all the 'ix' values are 0.  The fact that mp3trim is
confused by ancillary data shows that it is not using either of
these methods, and is probably using something even more simple minded?

Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to