ibsh / libkeyfinder Goto Github PK

Could you tag a new 2.2.2 release for CMake support?

Hi

From http://www.ibrahimshaath.co.uk/keyfinder/

2015-05-30: I've taken KeyFinder 2 offline as it contains a common crash caused by some library code.

Does this crash affect libKeyFinder 2.1 or just the Mac OS GUI app that uses libKeyFinder?

Thanks.

I can do some research to see what configuration will be required, but I think you will have to create an API token for travis and enable the hook in the repo, @ibsh.

Looking at travis-ci/travis-ci#577 for inspiration.

Following my previous message, I've been working on an endpoint for C# and .NET in general. It is almost finished, it is 32/64 bit compatible out of the box and also provides (in another package) a simple helper that detects the key of a song from a filename with many audio formats supported as it uses BASS.NET. Also I do use the 'streamed' version of your library so that memory usage stays low.

Here is a screenshot of what it will look like:

I will upload the whole sources for them as well as an example on GitHub when I'm done.

Is it okay for you that I publish this package to Nuget ?

Thanks :D

Hello,

I've made a fork of your project which provides C-style exports so the library can be used from other languages, it features the 'streamed' detection so the memory usage stays low.

https://github.com/aybe/libKeyFinder

I will also publish the C# wrapper I wrote for it, shortly.

Many thanks for such great library !

Best regards

I tried to compile version 2.2.1 on Arch Linux and during the make command, I ran into these errors:

g++ -c -pipe -std=c++11 -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -std=gnu++11 -Wall -W -fPIC -DLIBKEYFINDER_LIBRARY -I. -isystem /usr/local/include -I/usr/lib/qt/mkspecs/linux-g++ -o fftadapter.o fftadapter.cpp
fftadapter.cpp: In constructor ‘KeyFinder::FftAdapter::FftAdapter(unsigned int)’:
fftadapter.cpp:43:5: error: ‘memset’ was not declared in this scope
     memset(priv->outputComplex, 0, sizeof(fftw_complex) * frameSize);
     ^~~~~~
fftadapter.cpp:43:5: note: suggested alternative: ‘wmemset’
     memset(priv->outputComplex, 0, sizeof(fftw_complex) * frameSize);
     ^~~~~~
     wmemset
make: *** [Makefile:546: fftadapter.o] Error 1

I tried changing the variables with /usr/local/ at the beginning of the Makefile to /usr/ and I encountered error finding math.h:

g++ -c -pipe -std=c++11 -O2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -std=gnu++11 -Wall -W -fPIC -DLIBKEYFINDER_LIBRARY -I. -isystem /usr/include -I/usr/lib/qt/mkspecs/linux-g++ -o fftadapter.o fftadapter.cpp
In file included from constants.h:25:0,
                 from fftadapter.h:25,
                 from fftadapter.cpp:22:
/usr/include/c++/7.2.1/cmath:45:15: fatal error: math.h: No such file or directory
 #include_next <math.h>
               ^~~~~~~~
compilation terminated.
make: *** [Makefile:546: fftadapter.o] Error 1

How can this be achieved? As far as I can tell this code can only be used from within a c++ application, right?
A wrapper around this lib offering a simple cross platform api would be great.
Usage example could be:
./libkeyfinder -f test.mp3

Outputs:
"C Major"

Sorry but I am not really into c coding and couldn't figure it out myself how to do this. The osx gui client offers something like this from the command line but how can this be ported to debian, ubuntu, windows or whatever?

Running ./gradlew test outputs too much information. We don't need to see which tests passed on the console just those that failed. Also a bunch of stracktraces are being spat out for some reason.

Note: I'm building on Windows, which I know is unsupported, but I'm pretty sure this is a generic bug that probably just didn't make itself apparent in OSX because of the undefined nature of the result.

In AudioData::downsample (audiodata.cpp), if shortcut=true, std::advance is called to move the readAt iterator forward by 'factor'. This works fine normally, but it can (and does) attempt to advance past the end of the readAt iterator range when being called from KeyFinder::finalChromagram while flushing the remainder buffer when the buffer has remaining samples less than the downsample factor it attempts to advance by.

It's entirely possible I'm just doing something wrong to cause the problem since I've only been playing with the code for a couple hours, but I can't see how! I quick tested by removing the shortcut lines altogether and the code works fine that way

I tested it on Alpine and Centos:

FFTW Alpine: fftw-3.3.5
FFTW Centos: fftw-3.3.3

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tests is a Catch v1.0 b53 host application.
Run with -? for options

-------------------------------------------------------------------------------
AudioDataTest/DownsamplerResamplesNonintegralRelationship
-------------------------------------------------------------------------------
audiodatatest.cpp:295
...............................................................................

audiodatatest.cpp:313: FAILED:
  REQUIRE( (1000.0) <= (a.getSample(2)) + 0.0000001 )
with expansion:
  1000.0 <= 1.9200001

-------------------------------------------------------------------------------
FftAdapterTest/ForwardAndBackward
-------------------------------------------------------------------------------
fftadaptertest.cpp:24
...............................................................................

fftadaptertest.cpp:59: FAILED:
  REQUIRE( (5) > (out) )
with expansion:
  5 > 480.24512f

-------------------------------------------------------------------------------
LowPassFilterTest/DefaultFilterMatchesFisherCoefficients
-------------------------------------------------------------------------------
lowpassfiltertest.cpp:194
...............................................................................

lowpassfiltertest.cpp:225: FAILED:
  REQUIRE( (myCoeffs->at(i)) <= (myCoeffs->at(160 - i)) + 0.0000001 )
with expansion:
  0.0 <= -0.0022978864

===============================================================================
test cases:      65 |      62 passed | 3 failed
assertions: 1694952 | 1694949 passed | 3 failed

We are about to add libKeyFinder in mixxx as alternative key detection algorithm.
Would it be possible to re-license libKeyFinder under LGPL 3 so it can be used in non GPL3 software as well ?

Hello,

I've been trying to build the project under Windows and while it builds and works, it is extremely slow compared to your application 'is_KeyFinder'.

Since my C++ knowledge is quite limited it's been a lot of trial and error, I've used QT 5.3.1 with the Visual C++ compiler as well as Visual Studio 2013 but it remains slow; I couldn't figure out how to use MinGW as well as finding pre-compiled Boost binaries for it ... I can't really tell whether this is what's causing the slowness.

I have used the first sample code that you shown on the README.

Is it possible that you provide unmangled exports in KeyFinder0.dll so it can be easily consumed by other languages such as C# ?

Thank you.

Best regards

Hello,

I have started working on publishing the 2.0 branch for a DLL with C-style exports as well as the assembly for .NET.

I've seen that you've made the following changes to KeyFinder::keyOfChromaVector:

https://github.com/ibsh/libKeyFinder/blob/2.0/keyfinder.cpp#L104

Currently I've just copied what you did in here:

https://github.com/ibsh/libKeyFinder/blob/2.0/keyfinder.cpp#L32

Can you explain (what are / should be) these parameters ?

Thank you!

Could you release v2.2.1 (commit fc3c31a) so I can bump the version in alpine linux?

Hello can someone comment on the advantages of 2.1?

Is it more accurate? More efficient?

Essentially, should I upgrade from 0.11?

Thanks!

Hi @ibsh

I am using keyfinder HEAD since almost a year. Now I'd like to create a package for my distro, policy dictates that we use an official release, but I don't want to go back to 2.1. Can you release HEAD as 2.2? I haven't noticed problems.

Jean-Louis