Re: fix for the winemp3 module
Hi, Well, I'm not so familiar with detailed licencing stuff, sorry for not noticing. However, I've worked alot on mp3 codec a few years ago to make my own assembly codec (sorry, not x86) and after comparing many different sources, all I can say is that there aren't so many ways to decode the stream datas, so in the end all sources looks very similar. Also note that I haven't simply copied code from Mplayer's source, I've adapted it to current code. But I guess I'm being too naive saying this regarding to licence stuff. And the code which has most changed in my patch (about linbits decoding) is not something made by MPlayer's team as there was exactly the same method used a few years before in the old AMP 0.7.1 source (I'm not sure about exact version but it was around that one). Anyway if you think that my patch would lead to licence issues, then it's ok to drop it, don't worry. Regards, Denis. --- Eric Pouech <[EMAIL PROTECTED]> wrote: > Mike McCormack wrote: > > > > > Deun wrote: > > > >> Changelog by Denis Huguet ([EMAIL PROTECTED]) > >> > >> * 2006/10/17 : > >> Major diff between winemp3's layer3.c file and the one > from > >> MPlayer-1.0pre7try2/mp3lib/layer3.c for fixing decoding > >> glitches found out when opening mp3 file with GoldWave > 4.21 > >> with wine-0.9.22 (same with 0.9.23) > > > > > > Hi Denis, > > > > That's a big change. It would be nicer to submit it piece > by piece, > > fix by fix, clarifying which bug you are fixing and to get > rid of the > > extraneous #if 0's and C++ comments. > > > > That would make regression analysis easier in case the > patch > > introduces a bug. > > > > thanks, > > > > Mike > > > > > > > > > also, mplayer is GPL:ed, so you cannot use their work in wine > (which is > LGPL) > so the patch has to be made from the code of the original > library > (mpglib), which is LGPL > A+ > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: fix for the winemp3 module
I thought at first you just diff:ed the file against mplayer's code however, as mplayer's uses the old mpglib code, one could also ask mplayer's team to release the diffs they made to mpglib as LGPL (which they have to...) They don't have to (although it would certainly be kind of them to do so, particularly in this case). Section 3 of the LGPL states: "3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. "Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy." --Daniel Remenak
Re: fix for the winemp3 module
Deun wrote: Hi, Well, I'm not so familiar with detailed licencing stuff, sorry for not noticing. However, I've worked alot on mp3 codec a few years ago to make my own assembly codec (sorry, not x86) and after comparing many different sources, all I can say is that there aren't so many ways to decode the stream datas, so in the end all sources looks very similar. Also note that I haven't simply copied code from Mplayer's source, I've adapted it to current code. But I guess I'm being too naive saying this regarding to licence stuff. And the code which has most changed in my patch (about linbits decoding) is not something made by MPlayer's team as there was exactly the same method used a few years before in the old AMP 0.7.1 source (I'm not sure about exact version but it was around that one). Anyway if you think that my patch would lead to licence issues, then it's ok to drop it, don't worry. I thought at first you just diff:ed the file against mplayer's code however, as mplayer's uses the old mpglib code, one could also ask mplayer's team to release the diffs they made to mpglib as LGPL (which they have to...) the bad side of this is that mpglib is no longer maintained, so we can't expect fixes from that lib (the only LGPL mpg3 decoding lib I know of) updates to mpglib now appear in mpg123 a player (LGPL), but with lots of changes since the original code (and no longer a library on its own) anyway, the fixes seem to be needed... that's Alexandre's final call A+
Re: fix for the winemp3 module
Mike McCormack wrote: Deun wrote: Changelog by Denis Huguet ([EMAIL PROTECTED]) * 2006/10/17 : Major diff between winemp3's layer3.c file and the one from MPlayer-1.0pre7try2/mp3lib/layer3.c for fixing decoding glitches found out when opening mp3 file with GoldWave 4.21 with wine-0.9.22 (same with 0.9.23) Hi Denis, That's a big change. It would be nicer to submit it piece by piece, fix by fix, clarifying which bug you are fixing and to get rid of the extraneous #if 0's and C++ comments. That would make regression analysis easier in case the patch introduces a bug. thanks, Mike also, mplayer is GPL:ed, so you cannot use their work in wine (which is LGPL) so the patch has to be made from the code of the original library (mpglib), which is LGPL A+
Re: fix for the winemp3 module
Deun wrote: Changelog by Denis Huguet ([EMAIL PROTECTED]) * 2006/10/17 : Major diff between winemp3's layer3.c file and the one from MPlayer-1.0pre7try2/mp3lib/layer3.c for fixing decoding glitches found out when opening mp3 file with GoldWave 4.21 with wine-0.9.22 (same with 0.9.23) Hi Denis, That's a big change. It would be nicer to submit it piece by piece, fix by fix, clarifying which bug you are fixing and to get rid of the extraneous #if 0's and C++ comments. That would make regression analysis easier in case the patch introduces a bug. thanks, Mike