On Fri, 2008-10-03 at 13:50 -0700, Clayton Otey wrote:
> I've (re)written a library called sbsms (on sourceforge) which does
> high quality time stretching and pitch scaling. I'll be working on
> adding a "Time Scale" effect to augment the features of "Change Tempo"
> and "Change Pitch" with higher quality (but slower) and sliding time
> stretches/pitch scales. Any comments/suggestions? Would such a patch
> likely make it into the next release?
In principal it would be interesting to have an alternative to
soundtouch available in audacity, because we know there are some cases
when it doesn't work well. However there are some issues with the code
on sourceforge as it stands:
* Practical. You don't seem to have any build system in place for
Windows, which is where a large proportion of our user base is. In order
to integrate anything into Audacity, we would need to be able to compile
sbsms with Microsoft's Visual Studio Express tools, which can be a
problem if your code contains many C99 features (they still haven't
managed to implement it, 10 years on).
The most recent release tarball is also a bit flaky. It doesn't unpack
to a directory, thus filling wherever you unpack it to with the innards
of the project, rather than creating a single directory for the library.
There are also a lot of files included that don't need to be included
(starting with the entire contents of the autom4ate.cache directory and
aclocal.m4).
* Licensing. The fact that your code is under the GPL means that there
shouldn't be a problem with using it in audacity, which is released
under the GPL v2. However there is a complicating factor. The GPL v2 is
ambiguous about whether a GPL v2 application can load plug-ins at
runtime which do not have a GPL-compatible license (because they are
shared libraries, and the GPL treats all libraries as equal, regardless
of whether they are required or optional at build time or run time).
Audacity supports loading plug-ins at runtime via the LADSPA plug-in
interface, including (potentially) ones with licenses that aren't GPL
compatible. This means that it would be possible for users to link
audacity against commercial libraries simply by adding them to their
plug-ins directory. Our view is that this isn't a problem, it doesn't go
against the spirit of the GPL, and it is in the end up to the individual
user what they put in their plug-ins directory (we only supply
GPL-compatible plug-ins). However Erik de Castro Lopo, the author of
libsamplerate, takes a different view, believing that providing a
plug-in facility for plug-ins with incompatible licenses breaks the GPL
v2. Thus we don't use libsamplerate in audacity unless loading of
GPL-incompatible plug-ins is disabled.
The upshot of all this is that in order to distribute Audacity for
Windows or OS X with sbsms built in we would have to find an alternative
to libsamplerate for the sample rate conversions. In audacity itself we
use libresample, which provides a similar interface and signal quality,
but is slower. This is developed by the audacity team and so does not
pose a licensing issue. So the simplest way to get round this issue is
to modify sbsms to use either resampling library (chosen at compile
time), so that libresample can be used to build audacity releases.
Sorry for a long and mostly critical email, but I'd prefer to flag up
issues now rather than you put a lot of time into a patch which then
gets stalled at this end because of library issues (this is already the
case for one GSoC project, we don't want another).
Richard
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel
