Can this algorithm load the historical features into memory first, so that the matching speed is improved, but I don't know how to modify your basic code
Opened this issue · 7 comments
Can this algorithm load the historical features into memory first, so that the matching speed is improved, but I don't know how to modify your basic code
It does that.
My idea is to extract the hash, time (also the so-called eigenvalues) from the historical audio, and then load the eigenvalues into the memory. Users can match in the memory through wav and MP3 through match, and the search speed of tens of millions of songs will be improved.
I wouldn't call the peaks "eigenvalues" (although sinusoids are the eigenfunctions of LTI systems so .. maybe?) but otherwise your description seems to cover what audfprint currently does.
Hello, but, adding 100,000 songs to the library (most songs are 2 to 3 minutes long), I simulate a song of the user to match the matching speed is very slow, how to tune it, and get the result within 4 seconds? , or results in a shorter time
For example, in this case, I use three songs to load into the database, and then use one song to match, the result is 4.3 seconds, this speed is too slow, how to optimize this logic, I originally wrote a version myself , that is, use your program to get the time and hash, then write to mysql, load the memory when searching for match, and then use the dichotomy algorithm to search for the same hash to get the song id
There is another question, hello, is the algorithm of match a simhash idea?
There is another question, hello, is the algorithm of match a simhash idea?
Hello, I don't understand something about the match logic in the audfprint part, or what the specific algorithm logic is. I want to rewrite it into the Java version of the match logic.