altugkarakurt / morty Goto Github PK

The only feature of Essentia that we are using is peak detection. I found a peak detection code translated from MATLAB to Python, that only depends on NumPy. So, if we migrate to this implementation, we can get rid of our dependence to Essentia and upgrade from Python2.7 to Python 3.

This snippet works for both 2.7 and 3, so we can open a new branch, replace Essentia with this code and run a few of the reported experiments to see if it affects our accuracy. If everything is fine, we can migrate the master branch and upgrade the code to 3.

Here is the source code: https://gist.github.com/sixtenbe/1178136
Here is a review of this code snippet: https://blog.ytotech.com/2015/11/01/findpeaks-in-python/

Varied Parameters:
cent_ss:                     7.5, 15, 25, 50, 100
smooth_factor:           7.5, 10, 15, 20, 50
metric:                         pcd/pd
chunk_size:                 30, 60, 90, 120
method:                      bozkurt/chordia
distance_method:       manhattan, euclidean, L3, bhattacharyya, cross-correlation, intersection
what to estimate:        makam/tonic/joint
K of KNN:                    1, ..., ?10
(for chordia) Chunk Overlap: %25, %50 %75

Fixed Parameters:
rank:        10 for joint and mode estimation, 1 for tonic
ref_freq:   440

They are currently broken and the explanations are incomplete.

After Pitch Class Distribution is separated from Pitch Distribition, we should override the indexing so that we can do circular indexing

In the dataset to be published we need to supply the metadata of the recordings too. Each recording entry will have:

• recording name (slugified; code is in pycompmusic)
• recording mbid
• list of performers (performer name, performer mbid, vocal/performed instrument)
• composition (work name, work mbid, composer name, composer mbid, lyricist name, lyricist mbid)
• makam, form, usul
• era of recording (early 20th century, mid 20th century, 90s till now)
• tonic frequency

We have to manually confirm the metadata to some extend. We will also gather the statistics from these metadata.

Add none-sliced training and estimation to ChordiaEstimation.

Tonic histogram of Evaluator.py is buggy. When we are reporting the tonic errors, we calculate the difference between the annotated tonic and the estimated one and report this as the tonic error for each recording. Then, we decided to create a histogram of these errors as a histogram (of either [-600,600) or [0,1200) cents I can't remember) and it's faulty. There was a problem with the number of expected bins and returned values of numpy.histogram() and so on.

It is not really important but since we are not "recognizing" the tonic but "identifying" it, we should rename the repository to ModeTonicEstimation, which would encompass these two meanings

We need to implement our estimation method, that is baically chunked ChordiaEstimation and KNN. Check older versions of ChordiaEstimation for reference

• Distribution of tonic estimation errors; the mean and standard deviation. This will be done for each distance method along with makam estimation precisions, see (Gedik & Bozkurt). These results are for comparing the distance methods.
• Makam confusion matrix for the chosen optimal parameters.
• Comparison of the system's performance for individual estimations vs. joint estimation.
• Comparison of the performances for different segments of the input for both Chordia and Bozkurt. (in Bozkurt this means training and testing from some time-interval, e.g. 0-120 seconds, in the recording)

• A sample toy dataset will be prepared from Dunya API
• kNN implementation for parametrized k
• Run of a single trial
• The smoothing parameter in KDE will be studied
• The problem with pitch track extraction will be examined
• Scripts to be written: test, training, 10-fold, evaluation

When training data for a mode is much bigger than others this mode might dominate others. Add a parameter in chordia estimation to allow random resampling such that all the classes are represented by n number of samples, where n is the number of samples in the least represented mode.

At some point in the future, we should create an abstract parent class for pitch distribution and pitch class distribution, and carry the bulk of the definitions/methods there. PD and PCD should call the parent class and only implement specific methods, e.g. shifting.

This is part of a more extensive task to catalog, describe and implement the makam features. However, the distribution implementations should stay in morty (as the feature is not makam specific).

the description part is obscure as it doesn't properly explain the task, the mehods and the purpose. We have to rewrite it. Best is to write the SMC paper and reuse the material from there.

In Bozkurt, it is better to separate the estimation into three methods (tonic_estimate, mode_estimate joint_estimate) so it is easier to call and maintain.

• We need to prove the fact that tonics always appear on peaks with the parameters:
  smooth_factor = 15
  step_size = 15
• While reporting the mbid of the decisive nearest neighbors, we should include the timing information of the corresponding chunk. Currently, there is only mbid.
• There is a problem with the tonic histograms of Bozkurt tests.
• ? We might include computation time in Bozkurt tests, as well?

Sometime in the future, we should create a file called morty/config/default_params.cfg and have the default parameters for the different cultures read from there.

• Makam
• Hindustani
• Carnatic

Note that cfg file has a special format, which configparser module take care of the parsing. We should also find an easy way to call these default parameters.

• Refactor I/O to make it simpler (exmpale BozkurtEstimation)
• Rewrite the so called "spagetti" parts in the estimation function

Right now, the Essentia module PeakDetection returns any tiny peak it encounters. We should limit this as it makes the runtime significantly slower and possibly degrades the performance, especially in PDs.

The module offers us two parameters:

• maxPeaks (integer ∈ [1, ∞), default = 100) : the maximum number of returned peaks
• threshold (real ∈ (-∞, ∞), default = -1e+06) : peaks below this given threshold are not output

Assigning maxPeaks to < 10, 20 would be plausible. Also it might be good to copy the values and max normalize the before applying peak detection so that we can fix the "threshold" as a ratio to the max value (provided that PeakDetection does not to any re-normalization).

Once the refactor is done, create an installer so that people can install the package.

Now we are one the verge of completing the test dataset. We need tonic annotations for each recording. We will fetch the existing ones from the MTG/otmm_tonic_dataset@e5352c7. For the remaining ones we will ask @hsercanatli to run his tonic identification method.

In Chordia, it is better to separate the estimation into three methods (tonic_estimate, mode_estimate joint_estimate) so it is easier to call and maintain.

https://github.com/sankalpg/Library_PythonNew/blob/master/melodyProcessing/phaseSpaceEmbedding.py

Bozkurt and Chordia claasses now accept file/list of files inputs. These are not tested adequately. Make sure that they are bug free.

Hi,

I'm trying to test the package. After the install, I get this error :

>>> import morty.extras.foldgenerator
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "morty/extras/foldgenerator.py", line 3, in <module>
    from fileoperations.fileoperations import get_filenames_in_dir
ImportError: No module named fileoperations.fileoperations
>>>