Team Status Report 1

The biggest risk of our project is the matching algorithm performing very poorly. As elaborated further in the next point, existing papers have shown that query by humming, a similar project, has poor performance. We will have a very limited library of songs that we will match to. Our contingency plan for this is to add a data visualization aspect to the project to show the work that the matching algorithm has done, even if it cannot actually match it to a song. For example, it can display highlighted portions of the melody that it found to be a match or close match.

We might not do dynamic processing on a flexible library anymore. ​Some papers indicate that preprocessing with the helpful use of MIDI file information (a broken down record of pitches and rhythms for each instrument in a piece) is widely used and much simpler. The cost here means that the focus of our project is to either analyze and process mp3 files or to do better data representation and search algorithms.

The cost here is mitigated because our learning will be maximal — we can try out innovations to the existing algorithms since there isn’t much to lose.

Realizing the potential lack of accuracy with the project, we decided to add the visualization component to the project, so that users can at least see the inner workings of our algorithms.

Our schedule is mostly the same, but we have updated our Gantt chart below with the changes highlighted. After further evaluation, machine learning may not be needed so we have generalized ML-related tasks to matching algorithm, and we have also added in the data visualization to the task list.