Hello
I am not sure. I'll default to the lame experts on this. Actually, even
if my patch doesn't get it (which I guess it won't) could someone inform
me of the best _filler_. I figured it didn't matter, because if you can
put LAME x.xx (alpha) in there, then I figured anything could go in there.
-Jeremy
--
/ Jeremy Brand, B.S. \ Sr. Software Engineer /
/ phone://39-34-853-23988 \ mailto:[EMAIL PROTECTED] /
/ http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html /
/ "LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992 /
/ Get your own Free, Private email at http://www.smackdown.com/ /
On Thu, 27 Sep 2001, the following spilled from the mind of engdev:
> Jeremy,
>
> Is the choice of 0xff best? Could there be some confusion with the sync?
>
> Perhaps a better choice would be 0x55 ?
>
>
> jeremy brand wrote:
>
> > Hello,
> >
> > Background:
> >
> > The idea behind this patch is to keep LAME from putting LAME name and
> > versions into each frame of the mp3. I know that it is nice to have LAME
> > information in frames for debugging and testing, but sometimes there is a
> > want to have _clean_ (so to speak) mp3s. I have consulted with other
> > collegues that use LAME and one of the repetitive comments about LAME is
> > 'do you like that they put their name and version in each frame of the
> > mp3'? Truthfully, I don't. Besides, soon, I will be building a complete
> > (as near as) studio archive of mp3s out of about 250 CD and I do not want
> > software name and versions in my mp3s. This patch is handy for me, maybe
> > it will be handy for others.
> >
> > Implementation:
> >
> > The default functionality of LAME _has_ _not_ _changed_. Functionality is
> > only changed when the new flag '--no-grafiti-frames' is added. When this
> > flag is added, the LAME name and version _are_ _not_ added into the
> > ancillary data in each frame. Insead, only 0xff's are used. There is
> > absolutely no difference in size of file, or sound or any other functional
> > part of the mp3.
> >
> > Now, I dug this up in the ChangeLog.
> >
> > ----
> > 2000-11-01 17:56 markt
> > * libmp3lame/: bitstream.c, bitstream.h, util.h:
> >
> > restored bitstream.c to original.
> > drain_into_ancillary_data was written the way it is
> > on purpose. dont change it without checking with me first
> > ----
> >
> > I am modifying that function, but I _have_ _not_ changed the functionality
> > of drain_into_ancillary_data, but only changed from adding 'LAME version'
> > into the frame to only adding 0xff's. This simply makes it nicer for
> > people who want to have an un-tainted (so to speak) archive. It just
> > makes it more flexible for those people who want _clean_ frames. Nothing
> > more, nothing less.
> >
> > So, now, I'm officially asking to change drain_into_ancillary_data. Feel
> > free to apply the patch and note that I have (hopefully) not missed
> > anything.
> >
> > Thank you,
> > Jeremy
> >
> > Credit for the patch goes to Josh Samuelson <[EMAIL PROTECTED]> who
> > found and modified drain_into_ancillary_data initially to only fill with
> > 0xff's. Credit for adding the option, command line flag, struct change,
> > and the rest go to Jeremy Brand <[EMAIL PROTECTED]>. I'm only mentioning
> > this in hopes that the patch gets included in CVS and that credit goes
> > where credit is due.
> >
> > --
> > / Jeremy Brand, B.S. \ Sr. Software Engineer /
> > / phone://39-34-853-23988 \ mailto:[EMAIL PROTECTED] /
> > / http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html /
> > / "LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992 /
> > / Get your own Free, Private email at http://www.smackdown.com/ /
> >
> > ------------------------------------------------------------------------
> > Name: no_grafiti_frames.diff
> > no_grafiti_frames.diff Type: Plain Text (TEXT/PLAIN)
> > Encoding: BASE64
>
> --
> MP3 ENCODER mailing list archive is at:
> http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
>
--
MP3 ENCODER mailing list archive is at:
http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
