dejavu ========== Audio fingerprinting and recognition algorithm implemented in Python, see the explanation here: [How it works](http://willdrevo.com/fingerprinting-and-audio-recognition-with-python.html) Dejavu can memorize audio by listening to it once and fingerprinting it. Then by playing a song and recording microphone input, Dejavu attempts to match the audio against the fingerprints held in the database, returning the song being played. ## Depedencies: I've only tested this on Unix systems. * [`pyaudio`](http://people.csail.mit.edu/hubert/pyaudio/) for grabbing audio from microphone * [`ffmpeg`](https://github.com/FFmpeg/FFmpeg) for converting audio files to .wav format * [`pydub`](http://pydub.com/), a Python `ffmpeg` wrapper * [`numpy`](http://www.numpy.org/) for taking the FFT of audio signals * [`scipy`](http://www.scipy.org/), used in peak finding algorithms * [`MySQLdb`](http://mysql-python.sourceforge.net/MySQLdb.html) for interfacing with MySQL databases For installing `ffmpeg` on Mac OS X, I highly recommend [this post](http://jungels.net/articles/ffmpeg-howto.html). ## Setup First, install the above dependencies. Second, you'll need to create a MySQL database where Dejavu can store fingerprints. For example, on your local setup: $ mysql -u root -p Enter password: ********** mysql> CREATE DATABASE IF NOT EXISTS dejavu; Next, create a configuration file. Let's call it `dejavu.cnf`: [connection] username: root password: database: hostname: 127.0.0.1 Now you're ready to start fingerprinting your audio collection! ## Fingerprinting Let's say we want to fingerprint all of July 2013's VA US Top 40 hits. Start by loading the configuration file and creating a Dejavu object. ```python >>> from dejavu.control import Dejavu >>> from ConfigParser import ConfigParser >>> config = ConfigParser() >>> config.read("dejavu.cnf") >>> dejavu = Dejavu(config) ``` Next, give the `fingerprint()` command four arguments: * input directory to look for audio files * output directory to place .wav files (for computing fingerprints) * audio extensions to look for in the input directory * number of processes ```python >>> dejavu.fingerprint("va_us_top_40/mp3", "va_us_top_40/wav", [".mp3"], 3) ``` For a large amount of files, this will take a while. However, Dejavu is robust enough you can kill and restart without affecting progress: Dejavu remembers which songs it fingerprinted and converted and which it didn't, and so won't repeat itself. You'll have a lot of fingerprints once it completes a large folder of mp3s: ```python >>> print dejavu.fingerprinter.db.get_num_fingerprints() 5442376 ``` Also, any subsequent calls to `fingerprint()` will fingerprint and add those songs to the database as well. It's meant to simulate a system where as new songs are released, they are fingerprinted and added to the database seemlessly without stopping the system. ## Recognizing There are two ways to recognize audio using Dejavu. You can use Dejavu interactively through the terminal. Assuming you've already instantiated a Dejavu object, you can match audio through your computer's microphone: ```python >>> from dejavu.recognize import Recognizer >>> recognizer = Recognizer(dejavu.fingerprinter, config) >>> song = recognizer.listen() >>> print song { 'song_id': 16, 'match_time': 9.62813687324524, 'song_name': '18 - Love Somebody - Maroon 5', 'confidence': 21, 'record_time': 10 } ``` Or by reading .wav files via scripting functions: ```python from dejavu.recognize import Recognizer recognizer = Recognizer(dejavu.fingerprinter, config) song = recognizer.read("va_us_top_40/wav/07 - Mirrors - Justin Timberlake.wav") ``` ## How does it work? The algorithm works off a fingerprint based system, much like: * [Shazam](http://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf) * [MusicRetrieval](http://www.cs.cmu.edu/~yke/musicretrieval/) * [Chromaprint](https://oxygene.sk/2011/01/how-does-chromaprint-work/) The "fingerprints" are locality sensitve hashes that are computed from the spectrogram of the audio. This is done by taking the FFT of the signal over overlapping windows of the song and identifying peaks. A very robust peak finding algorithm is needed, otherwise you'll have a terrible signal to noise ratio. Here I've taken the spectrogram over the first few seconds of "Blurred Lines". The spectrogram is a 2D plot and shows amplitude as a function of time (a particular window, actually) and frequency, binned logrithmically, just as the human ear percieves it. In the plot below you can see where local maxima occur in the amplitude space: ![Spectrogram](plots/spectrogram_peaks.png) Finding these local maxima is a combination of a high pass filter (a threshold in amplitude space) and some image processing techniques to find maxima. A concept of a "neighboorhood" is needed - a local maxima with only its directly adjacent pixels is a poor peak - one that will not survive the noise of coming through speakers and through a microphone. If we zoom in even closer, we can begin to imagine how to bin and discretize these peaks. Finding the peaks itself is the most computationally intensive part, but it's not the end. Peaks are combined using their discrete time and frequency bins to create a unique hash for that particular moment in the song - creating a fingerprint. ![Spectgram zoomed](plots/spectrogram_zoomed.png) For a more detailed look at the making of Dejavu, see my blog post [here](http://willdrevo.com/fingerprinting-and-audio-recognition-with-python.html). ## How well it works To truly get the benefit of an audio fingerprinting system, it can't take a long time to fingerprint. It's a bad user experience, and furthermore, a user may only decide to try to match the song with only a few precious seconds of audio left before the radio station goes to a commercial break. To test Dejavu's speed and accuracy, I fingerprinted a list of 45 songs from the US VA Top 40 from July 2013 (I know, their counting is off somewhere). I tested in three ways: 1. Reading from disk the raw mp3 -> wav data, and 1. Playing the song over the speakers with Dejavu listening on the laptop microphone. 1. Compressed streamed music played on my iPhone Below are the results. ### 1. Reading from Disk Reading from disk was an overwhelming 100% recall - no mistakes were made over the 45 songs I fingerprinted. Since Dejavu gets all of the samples from the song (without noise), it would be nasty surprise if reading the same file from disk didn't work every time! ### 2. Audio over laptop microphone Here I wrote a script to randomly chose `n` seconds of audio from the original mp3 file to play and have Dejavu listen over the microphone. To be fair I only allowed segments of audio that were more than 10 seconds from the starting/ending of the track to avoid listening to silence. Additionally my friend was even talking and I was humming along a bit during the whole process, just to throw in some noise. Here are the results for different values of listening time (`n`): ![Matching time](plots/accuracy.png) This is pretty rad. For the percentages: Number of Seconds | Number Correct | Percentage Accuracy ----|----|---- 1 | 27 / 45 | 60.0% 2 | 43 / 45 | 95.6% 3 | 44 / 45 | 97.8% 4 | 44 / 45 | 97.8% 5 | 45 / 45 | 100.0% 6 | 45 / 45 | 100.0% Even with only a single second, randomly chosen from anywhere in the song, Dejavu is getting 60%! One extra second to 2 seconds get us to around 96%, while getting perfect only took 5 seconds or more. Honestly when I was testing this myself, I found Dejavu beat me - listening to only 1-2 seconds of a song out of context to identify is pretty hard. I had even been listening to these same songs for two days straight while debugging... In conclusion, Dejavu works amazingly well, even with next to nothing to work with. ### 3. Compressed streamed music played on my iPhone Just to try it out, I tried playing music from my Spotify account (160 kbit/s compressed) through my iPhone's speakers with Dejavu again listening on my MacBook mic. I saw no degredation in performance; 1-2 seconds was enough to recognize any of the songs. ## Performance ### Speed On my MacBook Pro, matching was done at 3x listening speed with a small constant overhead. To test, I tried different recording times and plotted the recording time plus the time to match. Since the speed is mostly invariant of the particular song and more dependent on the length of the spectrogram created, I tested on a single song, "Get Lucky" by Daft Punk: ![Matching time](plots/matching_time.png) As you can see, the relationship is quite linear. The line you see is a least-squares linear regression fit to the data, with the corresponding line equation: 1.364757 * record_time - 0.034373 = time_to_match Notice of course since the matching itself is single threaded, the matching time includes the recording time. This makes sense with the 3x speed in purely matching, as: 1 (recording) + 1/3 (matching) = 4/3 ~= 1.364757 if we disregard the miniscule constant term. The overhead of peak finding is the bottleneck - I experimented with mutlithreading and realtime matching, and alas, it wasn't meant to be in Python. An equivalent Java or C/C++ implementation would most likely have little trouble keeping up, applying FFT and peakfinding in realtime. An important caveat is of course, the round trip time (RTT) for making matches. Since my MySQL instance was local, I didn't have to deal with the latency penalty of transfering fingerprint matches over the air. This would add RTT to the constant term in the overall calculation, but would not effect the matching process. ### Storage For the 45 songs I fingerprinted, the database used 377 MB of space for 5.4 million fingerprints. In comparison, the disk usage is given below: Audio Information Type | Storage in MB ----|---- mp3 | 339 wav | 1885 fingerprints | 377 There's a pretty direct trade-off between the necessary record time and the amount of storage needed. Adjusting the amplitude threshold for peaks and the fan value for fingerprinting will add more fingerprints and bolster the accuracy at the expense of more space.