Re: [MP3 ENCODER] clean frames in ancillary data with patch
On 6 Okt, Artemis3 wrote: LAME is LGPL'ed, not GPL'ed. Ops, sorry, in http://www.mp3dev.org/mp3 says GPLed.. I guess this creates confusion :) (most of my other comments still apply anyway). See lame-dir/LICENSE. Bye, Alexander. -- 0 and 1. Now what could be so hard about that? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
Margaret Clark wrote: I find this attitude stupid. Here you guys are... using an ILLEGAL product (or did you pay the legally required licensing fees?), LAME is not illegal. As others have pointed out, LAME is modified ISO code, which was freely available at first, but later FHG began enforcing its patents. Now all the original code has been replaced, and violates no patents. Do not forget most countries don't recognise software patents as valid and legally enforceable. then bitching, because someone wants to remove the branding. I don't get it. Sounds like thieves complaining they got robbed. Your eloquence is charming :-) Personally, I regard open source developers in higher esteem than most corporate entities, who solely exist for money, money and more money. Moreover, your accusation that we are 'thieves' is quite ironic when you read on... BTW, no, I prefer the branding in the files, as it makes knowing what encoder used easier to detect when downloading from file sharing services. ^^ Unless you are working for the RIAA, I don't believe you're innocent of the same. Best regards Jason ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
Hi Alexander! On Thu, 04 Oct 2001, Alexander Leidinger wrote: On 3 Okt, Brent Geery wrote: I just want to clarify some facts. there is nothing illegal about the whole LAME project. FhG put out ISO sources as a guideline, which can be modified legally. I'm not talking about the source, nor the project. You can use source. I was referring to the binaries, that are required to do anything useful. Those that use the binaries ARE THIEVES (including (Note: I'm not a lawyer) The binaries aren't illegal. The distribution of the binaries without a license is illegal. And you aren't a thief if you _use_ the binary, but you violate some intellectual propperty laws if you _distribute_ the binary. Over the last few years some very educated people have chosen to dedicate their valuable time into this project so YOU can make decent sounding mp3's now, thanks to their effords. I TOTALLY value there effort. LAME is amazing (same for MAME.) In fact, I want to make sure their rights are protected. This includes insuring that source is not hijacked by some control freaks, but instead remains within the letter and spirit of the GLP licensing terms. LAME is LGPL'ed, not GPL'ed. Ops, sorry, in http://www.mp3dev.org/mp3 says GPLed.. I guess this creates confusion :) (most of my other comments still apply anyway). But because LAME is licensed to the LGPL, they can legally use LAME if they use the DLL or some kind of plugin for which they provide the source. And even if GPL allowed some way for the company to license the use of LAME, just who would get that money? You? The original programmer? See, LAME is not owned by anyone, so there is nobody to pay. It is perfectly legal to get money even for GPLed software. Look at suse or redhat, they sell GPLed software. The spirit of the GPL isn't about preventing the sale of software. It is the users decission if he want's to spend money for GPLed software. All agreeded :) -- $B!V$3$N%;!%i!%`!%s$,7n$K$+$o$C$F!#!#!#!!$*$7$*$-$h!*!W(B $B!!7nLn$$5$.!#1#9#9#2!#(B $B!!!VH~/=w@o;N%;!%i!%`!%s!W(B Home page:http://www.geocities.com/tokyo/6905 Anime radio: http://www.live365.com/stations/124148 Jpop/Jrock radio: http://www.live365.com/stations/228551 perl -le '$_=6110374086;2064208213:90307;55;tr[0-][ LEOR!AUBGNSTY];print' ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
Hi Ross! On Fri, 05 Oct 2001, Ross Levis wrote: jeremy brand wrote: It is quite offensive when people on this list all guess my intentions for writing such a patch. Nobody has got it right yet, even after I told this list my intentions in some of the first few emails on this thread. It seems very convenient to forget the facts, doesn't it! I'm sure I've read all the messages on this thread but I am still to learn the logical reason to remove the text from frame padding. As mentioned before, the text doesn't decrease quality or add any length to the file. The only use it has is to attempt to hide the fact that an MP3 was created by LAME. I would like to hear what advantage this has to anyone other than criminals. There is no logical reason. He implies its an aestethical (cosmetic) reason. Side effect: will make LGPL violations easier. Recommended course of action: Ignore. -- $B!V$3$N%;!%i!%`!%s$,7n$K$+$o$C$F!#!#!#!!$*$7$*$-$h!*!W(B $B!!7nLn$$5$.!#1#9#9#2!#(B $B!!!VH~/=w@o;N%;!%i!%`!%s!W(B Home page:http://www.geocities.com/tokyo/6905 Anime radio: http://www.live365.com/stations/124148 Jpop/Jrock radio: http://www.live365.com/stations/228551 perl -le '$_=6110374086;2064208213:90307;55;tr[0-][ LEOR!AUBGNSTY];print' ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
btw Margaret: you're the first woman I see here since ... ever? I'd always imagined 'first contact' different :)) It really comes as no surprise to me that the first female poster here has to be a moron. :) Yes, I'm a sexist. 8) -Youri ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
On Wed, 3 Oct 2001 01:26:59 +0200, Roel VdB [EMAIL PROTECTED] wrote: MC I find this attitude stupid. Here you guys are... using an ILLEGAL MC product (or did you pay the legally required licensing fees?), then MC bitching, because someone wants to remove the branding. I don't get MC it. Sounds like thieves complaining they got robbed. ?? have a little respect please. there is nothing illegal about the whole LAME project. FhG put out ISO sources as a guideline, which can be modified legally. I'm not talking about the source, nor the project. You can use source. I was referring to the binaries, that are required to do anything useful. Those that use the binaries ARE THIEVES (including myself.) Go ahead and justify and rationalize it all you want, but go ask FhG if you owe a licensing fee to them. LAME started out, and still is an educational project to learn about and improve upon audio compression. Sure, I know. And MAME is also an educational project to learn how arcade machines work. ;) Over the last few years some very educated people have chosen to dedicate their valuable time into this project so YOU can make decent sounding mp3's now, thanks to their effords. I TOTALLY value there effort. LAME is amazing (same for MAME.) In fact, I want to make sure their rights are protected. This includes insuring that source is not hijacked by some control freaks, but instead remains within the letter and spirit of the GLP licensing terms. Even more so, you should realise that since this year the complete ISO source distribution is replaced by superior code made by the people involved in this project. I know. The binaries and their output, are still in violation of patents, however. Stupid is that some people want to make $$ on the back of the hard work of open source developers and completely PERVERSE imo is that some don't even have the least bit of curtosy or politeness to aknowledge this work. Understood, but lets stick to the real world here. These companies are not only violating the terms of the GLP, but (much more importantly) they are also violating several patents (just by using the LAME source.) Giving credit to LAME is as much as saying sue me. Now, assuming they pay the licensing fees to FhG, they still would not legally be able to use LAME, because of the GLP license. And even if GPL allowed some way for the company to license the use of LAME, just who would get that money? You? The original programmer? See, LAME is not owned by anyone, so there is nobody to pay. Maybe these companies are just cheap pirates, or maybe they are doing the best to give their customers the best quality, and handling the situation in the only way they see practical. I find it appalling and offensive to see a person here shamelessly post a patch which can only be used to try and HIDE the origin of the high quality mp3 files. Why? You don't own it. Nor does ANYONE on it. Not the users, not the programmers, NOONE. That is the blessing, and the curse, of GPL and other public domain-like software. It attracts lots of people that are willing to give of their time freely, but you can't later change their mind and try are re-control the software. -- BRENT - The Usenet typo king. :) Fast Times At Ridgemont High Info http://www.FastTimesAtRidgemontHigh.org Voted #87 - American Film Institute's Top 100 Funniest American Films ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
On Tue, 2 Oct 2001, the following spilled from the mind of Gabriel Bouvigne: I will certainly sound harsh to you but I'd even suggest this extreme thing: Adding a restriction to the Lame licence stating that it's forbidden to make any change to libmp3lame that would prevent it from adding the LAME string into padding. Hi Gabriel, Wow, that does sound extreme. :-) I wonder why this is such a big issue anyway? Good thing that my patch is prior to any such license! ;-) Changing the license would make it no longer be LGPL and also might be met by restrictions at Opensource.org and therefore might not even qualify as opensource software anymore if that change were made. Speaking of which; the --no-graffiti-frames patch is still here: http://hackor.com/misc/no_graffiti_frames_2001_10_01-01.diff :) BTW (off topic), I was told that 0xff was not a good padding to the frames, but instead repititions of 0 1 0 1 were better. Fraunhofer encoded mp3s have the _filler_ as 0xff, and since as that is the case, how is that wrong? I guess 0 1 0 1 etc is better, but how can 0xff be wrong if Fraunhofer does it? I just though I would mention that since my original patch filled with 0xff, that is the reason why I chose 0xff, because Fraunhofer did. 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/ / -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
RE: [MP3 ENCODER] clean frames in ancillary data with patch
Margaret Clark wrote: I find this attitude stupid. Here you guys are... using an ILLEGAL product (or did you pay the legally required licensing fees?), then bitching, because someone wants to remove the branding. I don't get it. Sounds like thieves complaining they got robbed. AFAIK it is legal to use the MP3 source for personal use. FHG actually provide the original source (that LAME started with) for free download. Most of these guys have spent years working on this project perfecting the encoder for no financial gain and AFAIC they should be allowed the satisfaction that their encoder is being used in particular software. IMO if someone wants an encoder without the LAME string padding then they should download the FHG source and spend years perfecting it themselves. Ross. ___ Mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
- Original Message - From: Margaret Clark [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 03, 2001 12:12 AM Subject: Re: [MP3 ENCODER] clean frames in ancillary data with patch I find this attitude stupid. Here you guys are... using an ILLEGAL product (or did you pay the legally required licensing fees?), then bitching, because someone wants to remove the branding. I don't get it. Sounds like thieves complaining they got robbed. That seems way over the top and misinformed. LAME isn't illegal, nor are their any required license fees. ___ Mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] clean frames in ancillary data with patch
On Fri, 28 Sep 2001, the following spilled from the mind of Rob Leslie: jeremy brand wrote: BTW, in case anyone is interested: this patch is permanatly located here: http://hackor.com/misc/no_grafiti_frames_lame.diff You might want to correct the spelling of graffiti. Rob, *haha* Good point! Thanks. :-) 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/ / -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
Re: [MP3 ENCODER] clean frames in ancillary data with patch
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.diffType: 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/
Re: [MP3 ENCODER] clean frames in ancillary data with patch
jeremy brand wrote: BTW, in case anyone is interested: this patch is permanatly located here: http://hackor.com/misc/no_grafiti_frames_lame.diff You might want to correct the spelling of graffiti. -- Rob Leslie [EMAIL PROTECTED] -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
Re: [MP3 ENCODER] clean frames in ancillary data with patch
haha j The idea behind this patch is to keep LAME from putting LAME j name and versions into each frame of the mp3. I know that it j is nice to have LAME information in frames for debugging and j testing, but sometimes there is a want to have _clean_ (so to j speak) mp3s. Your patch will be used by (L)GPL-piracy vendor and they will love you. --- Takehiro TOMINAGA // may the source be with you! And no reason for us to make their lives easier - I think the pirates should at least be required to wade through the mp3encoder archives and apply the patch by hand. Mark -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
Re: [MP3 ENCODER] clean frames in ancillary data with patch
Am Freitag, 28. September 2001 00:56 schrieben Sie: haha j The idea behind this patch is to keep LAME from putting LAME j name and versions into each frame of the mp3. I know that it j is nice to have LAME information in frames for debugging and j testing, but sometimes there is a want to have _clean_ (so to j speak) mp3s. Your patch will be used by (L)GPL-piracy vendor and they will love you. --- Takehiro TOMINAGA // may the source be with you! And no reason for us to make their lives easier - I think the pirates should at least be required to wade through the mp3encoder archives and apply the patch by hand. Mark I second this! Jeremy Brand wrote: 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 Having the name inside the ancillary data section of some frames is not primarily for debugging. I don't know why it should disturb anyone, those bits used for the version string are wasted bits anyway. If you find LAME quality OK for encoding, why do you fear someone else might find out you used it? 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. That's funny! Jeremy, don't you think we would know how to disable writing that info into the freespace, if we wanted to? Sorry Jeremy Brand and Josh Samuelson, you wasted your time, that patch will not make it into the mainline. Ciao Robert -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
