BTW, in case anyone is interested: this patch is permanatly located here:
http://hackor.com/misc/no_grafiti_frames_lame.diff
I will try to keep it up to date with CVS.
Wow! I did not think something like this would be so controversial. In
the words of Rodney King, "Can't we all just get along?". ;-)
adios,
-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 jeremy brand:
> Date: Thu, 27 Sep 2001 00:48:21 +0200 (WEDT)
> From: jeremy brand <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [MP3 ENCODER] clean frames in ancillary data with patch
>
> 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/ /
>
--
MP3 ENCODER mailing list archive is at:
http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
