# Efficient Retrieval of Music Recordings Using Graph-Based Index Structures
## 4 Experiments
### Feature Computation  
In this section, we report on the runtimes for the various steps involved in the feature computation. This computation procedure has to be performed in the offline stage (for the whole database) and online stage (for the query). In contrast to the document-based analysis of the retrieval quality (evaluating a ranked list of documents), we now use an item-based evaluation (runtime to process a database item). To compute our measurements, we first load 20 s of an audio file (using librosa.load). In general, our audio files are longer, but for our runtime experiments, we only use a 20-second segment, corresponding to the length of a shingle. Then, we compute the spectral features [33] (with librosa.iirt). Next, we compute the CENS features [34] (using librosa.feature.chroma_cens). This step concludes the feature computation if no dimensionality reduction is applied. An additional step is performed in the embedding-based retrieval approaches (PCA-based embedding using sklearn.decomposition.PCA or DNN-based embedding as described in [9]).  
Table 4 shows the time measurements. The loading of the audio segment only takes 44.8 ms. The next step is the spectral feature computation, which needs more than a second (1171.5 ms). The time required for the CENS computation is not significant (0.9 ms). In the table, we list the times to embed the shingle for some selected dimensionalities. In general, the PCA-based embedding is faster than 0.1 ms, and the DNN-based embedding does not take more than 2 ms.  
\begin{table}
\begin{tabular}{c c c c c c} \hline
**Reduction** & \(K\) & **Search** & **P@1** & **P@3** & \(\mathbf{P_{R}}\) \\ \hline — & 240 & Full Search & 1.0000 & 0.9965 & 0.9434 \\  & & HNSW & 1.0000 & 0.9965 & 0.9434 \\ \hline \multirow{4}{*}{PCA} & \multirow{2}{*}{30} & Full Search & 1.0000 & 0.9910 & 0.9130 \\  & & HNSW & 1.0000 & 0.9910 & 0.9130 \\ \cline{2-6}  & & Full Search & 1.0000 & 0.9679 & 0.8294 \\ \cline{2-6}  & & HNSW & 1.0000 & 0.9678 & 0.8294 \\ \cline{2-6}  & & Full Search & 1.0000 & 0.8937 & 0.7350 \\ \cline{2-6}  & & HNSW & 1.0000 & 0.8937 & 0.7350 \\ \hline \multirow{4}{*}{DNN} & \multirow{2}{*}{30} & Full Search & 1.0000 & 0.9868 & 0.9344 \\  & & HNSW & 1.0000 & 0.9869 & 0.9345 \\ \cline{1-1} \cline{2-6}  & & Full Search & 1.0000 & 0.9757 & 0.8989 \\ \cline{1-1} \cline{2-6}  & & HNSW & 1.0000 & 0.9756 & 0.8989 \\ \cline{1-1} \cline{2-6}  & & Full Search & 1.0000 & 0.9236 & 0.8333 \\ \cline{1-1} \cline{2-6}  & & HNSW & 1.0000 & 0.9237 & 0.8333 \\ \hline \end{tabular}
\end{table}
Table 3: Retrieval quality for various reduction approaches and search strategies using the dataset \(\mathbb{D}_{\text{sm}}\). Note that the evaluation measures for the KD search approach are identical to the full search approach.  
The numbers of the table show that the major bottleneck of the feature computation is the spectral transform. Compared to this, the times of the other steps are not significant. The runtime for the query feature transform is not our focus in this paper. Obviously, it only scales linearly with the query length, which is usually short (i.e., no scalability issue). The runtime for computing the database documents' features is also not critical because it can be computed offline. A possible future research direction could be to compute embeddings from spectral representations that are less expensive to compute, e.g., using the short-time Fourier transform (STFT) with the FFT. Having the same window and hop length settings as the spectral transform used, computing the magnitude STFT for the 20-s audio snippet only takes 19.2 ms on average. However, using the STFT-based features may go along with a decrease of feature quality, which may affect the retrieval results.