antlarr / bard Goto Github PK

I would like to try things out but I didn't succeed to compile the code properly.

Here is what I installed:

apt-get install libboost-python-dev

Then I ran:

python3 setup.py build

And I ended up with:

running build
running build_py
warning: build_py: byte-compiling is disabled, skipping.

running build_ext
building 'bard_ext' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -fdebug-prefix-map=/build/python3.5-MLq5fN/python3.5-3.5.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DMAJOR_VERSION=1 -DMINOR_VERSION=0 -D_GLIBCXX_PARALLEL -I/usr/include/boost -I/usr/include/python3.5m -c bard/bard_ext.cpp -o build/temp.linux-x86_64-3.5/bard/bard_ext.o -std=gnu++17 -fopenmp -Ofast -march=native -mtune=native -funroll-loops
cc1plus: warning: command line option _-Wstrict-prototypes_ is valid for C/ObjC but not for C++
bard/bard_ext.cpp: In lambda function:
bard/bard_ext.cpp:133:20: error: expected unqualified-id before _[_ token
             auto & [itSongID, itFingerprint] = itSong;
                    ^
bard/bard_ext.cpp:133:20: error: expected initializer before _[_ token
bard/bard_ext.cpp:134:18: error: expected unqualified-id before _[_ token
             auto [offset, similarity] = compareChromaprintFingerprintsAndOffset(itFingerprint, v, cancelThreshold);
                  ^
bard/bard_ext.cpp:135:17: error: _similarity_ was not declared in this scope
             if (similarity > cancelThreshold)
                 ^~~~~~~~~~
bard/bard_ext.cpp:138:57: error: _itSongID_ was not declared in this scope
                 result.append(boost::python::make_tuple(itSongID, offset, similarity));
                                                         ^~~~~~~~
bard/bard_ext.cpp:138:67: error: _offset_ was not declared in this scope
                 result.append(boost::python::make_tuple(itSongID, offset, similarity));
                                                                   ^~~~~~
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

I'm running on Debian on WSL

When importing my music, the addSong function triggered an exception when importing some Ogg Vorbis files with unicode characters:

  File "/usr/lib/python3.6/site-packages/bard-0.1.0-py3.6-linux-x86_64.egg/bard/musicdatabase.py", line 199, in addSong
    print(values[0][3:])
UnicodeEncodeError: 'ascii' codec can't encode character '\xa5' in position 35: ordinal not in range(128)

Please update the code to either ignore the non-ascii unicode chars or implement all strings in database as unicode strings.
( yourstring.encode('ascii', 'ignore').decode('ascii') )

See also:
https://docs.python.org/3.6/howto/unicode.html#python-s-unicode-support

in 52bce48 , std::vector<std::pair<int,std::vector<int>>> was introduced.

However, as far as I know, you can use vector::emplace_back more effectively.

--- current
+++ propose
- m_fingerprints.emplace_back(std::make_pair(songID, v));
+ m_fingerprints.emplace_back(songID, std::move(v));

• construct std::pair on new element append for readability(performance will be same due to RVO)
• move vector to avoid copy

Hi

I would be interested to to try this music manager but I can't get information about it's usage, features etc. without reading the code.

• How does it compare to something like Beets?
• How do do you perform a common task like importing, editing music?
• Is it focused on songs or on albums?

Would love to see some information in the wiki or on readthedocs.io or similar.

Cheers

config['immutableDatabase']
this line of code will lead to key error. otherwise if config file has this item, it will be alwarys immutable

Hi, I've stumbled upon your blog post and skimmed the code a little. If I'm not mistaken, you've been optimizing the comparison between two fingerprints. In practice, however, you'll be comparing on the order of N^2 pairs of fingerprints, not just two, which still grows proportionally to the square of the number of songs (10 times more songs will take 100 time longer).

So I propose another approach, in the form of a a memory-time-complexity trade-off:

• for each song, extract the fingerprint and add it into a data structure that supports fuzzy searching
• for each song, compute its fingerprint and look up matches in the data structure built previously

Choosing and implementing a data structure is the hard part, of course. One that might work is a Levenshtein automaton. These have the advantage of naturally supporting insertions and deletions, so you wouldn't have to insert 200 fingerprints for each song. I never tried to implement one, but this post gives a nice introduction.

One limitation, however, is that the way these are usually built, they allow insertions both at the ends and in the middle. For fingerprint comparisons you'd probably want to allow insertions and deletions only at the ends, and only changes in the middle. But you'd probably have to implement it yourself in that case. An alternative is to build a DFA that only allows substitutions, and also insert the shifted fingerprints into it.

Anyway, I don't know if you'll ever get to try it, but it might be worth keeping in mind.

EDIT: After thinking a little more about it, you'd want this to accept large edit distances (you mention a 55% match in the blog post). That would probably blow up the size of the automaton, so this approach might not work for you.