Split acoustid_compare.c into PostgreSQL + non-PostgreSQL portions

[genotrance]

I'm leveraging the match_fingerprintsX() algorithms in my project and have to currently comment out the PostgreSQL specific code in order to build. It would be much better to split out the code into two chunks such that you can continue to build your project per usual while simultaneously allowing projects like mine to simply checkout your code and only include the non-PostgreSQL content to do the comparison.

I can submit a pull request if you are interested.

As an aside, my project autodup is to find duplicate files and I've been able to leverage fpcalc (standalone binary) along with the code in this repo to compare audio files successfully.

[lalinsky]

The reason why I never made a standalone library for matching audio fingerprint is that I was never happy with any matching function. I have been working on many prototypes in Python over the last years, had some good results, but never finished any of them.

Here is the latest approach that I'm mostly happy with:

https://github.com/acoustid/notebooks/blob/master/fingerprint-matching.ipynb

And one of the most recent versions I have implemented in C++ is this:

https://github.com/acoustid/chromaprint/blob/master/src/fingerprint_matcher.cpp

On the other hand, if you are fine with the matching this C code does, feel free to create the pull request.

[genotrance]

Thanks for the info. Is the C++ version an implementation of the approach documented in the iPython notebook?

I'll try to get the C++ version working within Nim.

[lalinsky]

More or less, but note that the code does not give a yes/no answer to whether two fingerprints are the same. You get a list of matching segments with scores and need to make a decision based on that. The last missing piece is to learn a decision tree or something like that to take the matching segments and make the yes/no decision.

[genotrance]

In that case, it might be better to rely on the C version for the near term. Once you have the missing piece, I can move over to using this instead.

Now I'm on the fence on whether I should submit a pull for this enhancement. If this missing piece isn't coming out anytime soon, I can work on it. If not, I'd rather wait it out. Please let me know how it looks from your end.

[lalinsky]

I have no real plans to work on this in the near future. So if you are fine with the C version, I'd suggest to use that.