Hallo David ! I want to contribute some code to the talkbox scikit and have some questions. - First, is this scikit also for audio signal processing / audio (music) feature extraction, or mainly for speech only ? - Second, I have implemented some (random) code for audio signal processing which IMHO would be nice to have in a scikit: * Implementation of a Generalized Cross Correlation (GCC) with various pre-whitening filters. (after "The Generalized Correlation Method for Estimation of Time Delay" by Charles Knapp and Clifford Carter, programmed with looking at the matlab GCC implementation by Davide Renzi) this function is used for robustly determine the time delay between two real signals * Equivalent Rectangular Bandwidth Filter Coefficients for biquad IIR Filters. (implemented after "An Efficient Implementation of the Patterson-Holdsworth Auditory Filter Bank" by Malcolm Slaney) * Filter coefficients for a bank of Gammatone filters. (implemented after "An Efficient Implementation of the Patterson-Holdsworth Auditory Filter Bank" by Malcolm Slaney) Implementation also with multiple biquad filters, to avoid numerical unstabilities. * Common filter parameters for audio biquad IIR filters (after "Cookbook formulae for audio EQ biquad filter coefficients", http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt) * Conversion of linear IIR filter parameters to a minimum phase filter with the same amplitude response. * MFCC feature extraction (but I have seen that you already have implemented mfccs...) * I plan to implement more audio/music feature extraction methods in near future (chroma features, beat features, beat-synchronous features ...) - OK, would this be suited for talkbox ? If yes, are there any guidlines how to contribute (I will adapt the code to your scikit style, writing more tests and docs) - I mean, should I just send you the code by mail ? - In which categories should I put all these ? So I propose all the filter parameter calculations in talkbox/fbanks/, feature extraction methods of course into talkbox/features/ and the generalized cross correlation maybe into talkbox/tools/correlations.py, or maybe in a seperate file ... ? - And last but not least, is this the right mailing list for such discussions ;) ? Or are there any special lists for scikits ? OK, thanks for any feedback ! LG Georg
Hi Georg On Sat, Feb 28, 2009 at 9:50 PM, Georg Holzmann <grh@mur.at> wrote:
Hallo David !
I want to contribute some code to the talkbox scikit and have some questions.
Great.
- First, is this scikit also for audio signal processing / audio (music) feature extraction, or mainly for speech only ?
No, no, music is definitely welcomed. Actually, I only do speech because it pays my bill :) And a talkox is mainly used for music, after all.
- Second, I have implemented some (random) code for audio signal processing which IMHO would be nice to have in a scikit:
* Implementation of a Generalized Cross Correlation (GCC) with various pre-whitening filters. (after "The Generalized Correlation Method for Estimation of Time Delay" by Charles Knapp and Clifford Carter, programmed with looking at the matlab GCC implementation by Davide Renzi) this function is used for robustly determine the time delay between two real signals
* Equivalent Rectangular Bandwidth Filter Coefficients for biquad IIR Filters. (implemented after "An Efficient Implementation of the Patterson-Holdsworth Auditory Filter Bank" by Malcolm Slaney)
* Filter coefficients for a bank of Gammatone filters. (implemented after "An Efficient Implementation of the Patterson-Holdsworth Auditory Filter Bank" by Malcolm Slaney) Implementation also with multiple biquad filters, to avoid numerical unstabilities.
* Common filter parameters for audio biquad IIR filters (after "Cookbook formulae for audio EQ biquad filter coefficients", http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt)
* Conversion of linear IIR filter parameters to a minimum phase filter with the same amplitude response.
* MFCC feature extraction (but I have seen that you already have implemented mfccs...)
* I plan to implement more audio/music feature extraction methods in near future (chroma features, beat features, beat-synchronous features ...)
All this sounds great. I don't have much time to work on talkbox at the moment, so I won't be able to review in detail your code. I know more or less what I want to see in the scikits (all the above fits it), but I don't know yet how to organize. There are only two big requirements: - I do want a pure python implementation for everything (with optional C/Cython). - It should be under the BSD. I hope that at least some of it will be included in scipy at some point.
- In which categories should I put all these ? So I propose all the filter parameter calculations in talkbox/fbanks/, feature extraction methods of course into talkbox/features/ and the generalized cross correlation maybe into talkbox/tools/correlations.py, or maybe in a seperate file ... ?
The organization is quite messy ATM, I have not thought too much about it. The difference between features and fbanks is not clear, for example. The good news is that I may well be the only user of talkbox for now, so if you have a better suggestion, we can break things,
- And last but not least, is this the right mailing list for such discussions ;) ? Or are there any special lists for scikits
No special scikits ML, no, I think it is the right place, David
- Second, I have implemented some (random) code for audio signal processing which IMHO would be nice to have in a scikit:
* Implementation of a Generalized Cross Correlation (GCC) with various pre-whitening filters. (after "The Generalized Correlation Method for Estimation of Time Delay" by Charles Knapp and Clifford Carter, programmed with looking at the matlab GCC implementation by Davide Renzi) this function is used for robustly determine the time delay between two real signals
There are only two big requirements: - I do want a pure python implementation for everything (with optional C/Cython). - It should be under the BSD. I hope that at least some of it will be included in scipy at some point.
matlab GCC implementation by Davide Renzi is GPL so depending how it is implemented, this might be a problem Josef
Hallo!
matlab GCC implementation by Davide Renzi is GPL
so depending how it is implemented, this might be a problem
Hm, I mean this is no direct copy of his implementation - I just tried to use the same interface. (however, the implementation is of course somehow similar ...) But I don't think that this should be a problem ... LG Georg
Georg Holzmann wrote:
(however, the implementation is of course somehow similar ...)
But I don't think that this should be a problem ...
I think it does. IANAL, but at least morally, I would be pretty pissed to release a GPL code and seeing a BSD code with same interface and "similar" implementation afterwards. I think you should check with the original developer - my experience is that at least in academia, people who release things under the GPL do not mind releasing under the BSD (they chose GPL by default). This is of course not always the case, though, David
Hallo!
I think it does. IANAL, but at least morally, I would be pretty pissed to release a GPL code and seeing a BSD code with same interface and "similar" implementation afterwards.
hm, I can of course change the interface (and don't mention the author of the code, just the author of the paper) - but that sounds somehow silly to me ...
I think you should check with the original developer - my experience is that at least in academia, people who release things under the GPL do not mind releasing under the BSD (they chose GPL by default). This is of course not always the case, though,
OK - I will. But is it enough if I write him a mail if that is ok and he says yes ? Or must this be in a more formal way ... LG Georg
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Georg Holzmann wrote:
hm, I can of course change the interface (and don't mention the author of the code, just the author of the paper) - but that sounds somehow silly to me ...
Again, IANAL, but I don't think it changes anything at this point (changing the interface or not). GPL says that any derivative work that you distribute must be GPL itself. Something with the same API and "somewhat" similar may well qualify as derivative work. This is annoying, but we have to be careful with those 'rules' - that's the only reason why we cannot use things like the gsl, or R code, even though those codebases are potentially very useful to us (and ours to them, maybe).
OK - I will. But is it enough if I write him a mail if that is ok and he says yes ?
From a "moral" POV, it is enough for me - I have done exactly this in
the past. Since the code is open source, I think asking for permission is a kind of "minimal decency". cheers, David
David Cournapeau wrote:
Georg Holzmann wrote:
hm, I can of course change the interface (and don't mention the author of the code, just the author of the paper) - but that sounds somehow silly to me ...
Again, IANAL, but I don't think it changes anything at this point (changing the interface or not). GPL says that any derivative work that you distribute must be GPL itself. Something with the same API and "somewhat" similar may well qualify as derivative work.
This is annoying, but we have to be careful with those 'rules' - that's the only reason why we cannot use things like the gsl, or R code, even though those codebases are potentially very useful to us (and ours to them, maybe).
OK - I will. But is it enough if I write him a mail if that is ok and he says yes ?
From a "moral" POV, it is enough for me - I have done exactly this in the past. Since the code is open source, I think asking for permission is a kind of "minimal decency".
cheers,
David _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
Hi, Ideally you should have a provided a clean room implementation. In any case you have to be very careful here if you have actually viewed the code licensed under the GPL because in part it may imply acceptance of the license (EULA conditions). But I agree that it far better to ask for permission and see what happens. You might even be able to create a better product. You might find the various resources provide by Software Freedom Law Center at http://www.softwarefreedom.org/resources/ 'A Practical Guide to GPL Compliance' http://www.softwarefreedom.org/resources/2008/compliance-guide.html 'Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers' http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html Bruce
Hallo!
You might find the various resources provide by Software Freedom Law Center at http://www.softwarefreedom.org/resources/
'A Practical Guide to GPL Compliance' http://www.softwarefreedom.org/resources/2008/compliance-guide.html 'Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers' http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
Thanks for the links ! LG Georg
On 3-Mar-09, at 1:13 PM, David Cournapeau wrote:
Georg Holzmann wrote:
(however, the implementation is of course somehow similar ...)
But I don't think that this should be a problem ...
I think it does. IANAL, but at least morally, I would be pretty pissed to release a GPL code and seeing a BSD code with same interface and "similar" implementation afterwards.
I guess it depends on how he means "interface", i.e. most of scipy.spatial.distance designed to have an almost identical interface to the matlab functions with the same name, although under the hood everything is completely different. David
On Wed, Mar 4, 2009 at 8:16 AM, David Warde-Farley <dwf@cs.toronto.edu> wrote:
On 3-Mar-09, at 1:13 PM, David Cournapeau wrote:
Georg Holzmann wrote:
(however, the implementation is of course somehow similar ...)
But I don't think that this should be a problem ...
I think it does. IANAL, but at least morally, I would be pretty pissed to release a GPL code and seeing a BSD code with same interface and "similar" implementation afterwards.
I guess it depends on how he means "interface", i.e. most of scipy.spatial.distance designed to have an almost identical interface to the matlab functions with the same name, although under the hood everything is completely different.
having the same interface is almost always OK - but if you looked at the implementation, you are almost guaranteed to be "tainted". According to Georg, both API and the implementation is somewhat similar. And now there is public proof that he did look at the GPL implementation for "inspiration". I would not bet this cannot be considered as derivative work. Thinking another way: say the original code is matlab code from mathworks, and we have an implementation which looks like their (same variables, same structure, public record we took a look at matlab implementation). Would you feel confident if mathworks brings you to court ? I wouldn't. In this case, since the original code is GPL, I would think there is little legal risk. Really, asking the original author is just easier :) David
Hallo!
No, no, music is definitely welcomed. Actually, I only do speech because it pays my bill :) And a talkox is mainly used for music, after all.
OK, thats fine ;)
There are only two big requirements: - I do want a pure python implementation for everything (with optional C/Cython). - It should be under the BSD. I hope that at least some of it will be included in scipy at some point.
Yes I know - no problems !
The organization is quite messy ATM, I have not thought too much about it. The difference between features and fbanks is not clear, for example. The good news is that I may well be the only user of talkbox for now, so if you have a better suggestion, we can break things,
OK, so I will put all the filter parameter stuff into fbanks ... LG Georg
On Sat, Feb 28, 2009 at 1:50 PM, Georg Holzmann <grh@mur.at> wrote:
- Second, I have implemented some (random) code for audio signal processing which IMHO would be nice to have in a scikit:
- In which categories should I put all these ? So I propose all the filter parameter calculations in talkbox/fbanks/, feature extraction methods of course into talkbox/features/ and the generalized cross correlation maybe into talkbox/tools/correlations.py, or maybe in a seperate file ... ?
Just my opinion, but from the names and descriptions of these, I think several could easily be argued to belong with signal processing functionality in scipy.signal, as they do not appear to be limited to sound/speech applications.
Georg
-- Tom Grydeland <Tom.Grydeland@(gmail.com)>
Hallo!
Just my opinion, but from the names and descriptions of these, I think several could easily be argued to belong with signal processing functionality in scipy.signal, as they do not appear to be limited to sound/speech applications.
Yes, maybe ... However, maybe it is a good first step to put them into talkbox. Then people can try it and if they think it is useful for scipy, they can move it there ... LG Georg
Georg Holzmann wrote:
Hallo!
Just my opinion, but from the names and descriptions of these, I think several could easily be argued to belong with signal processing functionality in scipy.signal, as they do not appear to be limited to sound/speech applications.
Yes, maybe ... However, maybe it is a good first step to put them into talkbox. Then people can try it and if they think it is useful for scipy, they can move it there ...
Yes, that's exactly the point (and the only rationale for BSD code - using GPL would have been better to use fftw and co). Also, scipy.signal is already kind of messy and would need some code cleaning (there is a lot of old code which would benefit to be updated with recent numpy facilities, such as array iterators). I would prefer making it better before adding more code. Finally, being in scikits means the code can change as much as the author want, there is much less constraints compared to being in scipy. cheers, David
participants (7)
-
Bruce Southey -
David Cournapeau -
David Cournapeau -
David Warde-Farley -
Georg Holzmann -
josef.pktd＠gmail.com -
Tom Grydeland