# Using Structural and Semantic Information to Identify Software Components

Cezar Sas  Bernoulli Institute
University of Groningen
Groningen, Netherlands
<EMAIL_ADDRESS>Andrea Capiluppi  Bernoulli Institute
University of Groningen
Groningen, Netherlands
<EMAIL_ADDRESS>
###### Abstract

Component Based Software Engineering (CBSE) seeks to promote the reuse of
software by using existing software modules into the development process.
However, the availability of such a reusable component is not immediate and is
costly and time consuming. As an alternative, the extraction from pre-existing
OO software can be considered.

In this work, we evaluate two community detection algorithms for the task of
software components identification. Considering ‘components’ as ‘communities’,
the aim is to evaluate how independent, yet cohesive, the components are when
extracted by structurally informed algorithms.

We analyze 412 Java systems and evaluate the cohesion of the extracted
communities using four document representation techniques. The evaluation aims
to find which algorithm extracts the most semantically cohesive, yet separated
communities.

The results show a good performance in both algorithms, however, each has its
own strengths. Leiden extracts less cohesive, but better separated, and better
clustered components that depend more on similar ones. Infomap, on the other
side, creates more cohesive, slightly overlapping clusters that are less
likely to depend on other semantically similar components.

###### Index Terms:

Components Identification, Community Detection, Components Semantic Analysis

##  I Introduction

CBSE is an alternative to Object-Oriented (OO) development that aims to make
it easier to develop easily reusable and understandable software by using
components [1]. In order to become useful, CBSE has to produce a repository
containing enough components, so that developers do not have to rewrite them
from scratch[2, 3].

An alternative to pre-developed and designed components is to extract them
from pre-existing software. As an example of this approach, [4] proposed an
architecture recovery approach called ROMANTIC, helped by human experts.
Similarly, using particle swarm optimization, [5] proposed a method that uses
a meta-heuristic search-based clustering. Frequent usage patterns propelled
instead the search heuristics in [6].

Other papers, although not necessarily focusing on component reuse, provided
algorithms for component extraction: [7, 8] proposed a metric called MQ to
measures edge density of graphs, to help in the module selection. The use of
graph clustering was often used for the same purpose in later publications [9,
10].

The aim of this paper is to evaluate how well-formed the components are when
they are automatically extracted by community-detection algorithms [11]. Based
on the extracted ‘communities as modules’, we aim to test the semantic
cohesiveness of those communities (of features) in the context of the overall
software system. As a case study, we use a curated population of 700 Java
projects111Awesome Java is a GiHub project that aggregates several hundreds of
curated Java projects, available at https://github.com/akullpp/awesome-java.
After removing empty projects, tutorials, links to websites, or giving issues
when analyzing, we obtained a sample of 412 Java projects.

The two objectives of this paper are  (i) to evaluate the effectiveness of
extracting structure-informed modules from a software system, and  (ii) to
detect whether the extracted modules are semantically cohesive.  In order to
assess the first objective, we used two community detection algorithms,
Infomap [12] and Leiden [13]. The second objective is assessed in two ways:
firstly, we evaluated whether there is a low cohesion between different
modules (e.g., semantic separation); secondly, we checked whether the
identified modules are semantically cohesive per-se. The source code to
replicate our analysis has been made publicly
available222https://github.com/SasCezar/ComponentSemantics/tree/SANER-ERA.

##  II Preliminaries

In the following section, we introduce the three steps in this work: how we
extracted the structural dependencies (II-A), how we detected the software
modules as ‘communities’ (II-B) and how we assessed the cohesiveness of the
modules (II-C). Figure 1 presents a visual representation of our pipeline.

###  II-A Structural Dependencies

The first step of our approach is the extraction of the dependency graph for
each project in our sample. Using the Arcan [14] tool, we obtained the nodes
and the edges describing the dependencies between classes, where the edge
weight is the number of uses [15] of one class in the other. Arcan parses the
abstract syntax tree, extracted with Spoon[16], of the project source files,
and it looks for any reference to classes, variables, and methods and saves
that information in a graph. For example, in the antlr4 project, we have a
dependency between org.antlr.v4.automata.ParserATNFactory.java and
org.antlr.v4.tool.LexerGrammar.java as the former imports the latter.

Figure 1: Analysis pipeline. Given a project source code, we extract (a) a
vector representation for each file, and (b) the dependency graph. The
dependency graph is used as input to the community extraction algorithm. The
embeddings and the identified communities are aligned to evaluate the
algorithm.

###  II-B Community Detection via Graph Clustering

The second step of our approach uses the relationships identified by the
structural dependencies as input for the Community Detection (CD) algorithms.
CD (or graph clustering) approaches have been used for various tasks in the
software engineering domain besides component identification. Examples include
aiding the transition from monolithic applications to microservices
architectures [17], architecture reconstruction [18], and refactoring of
software packages [19].

In this step we compare two different types of CD algorithms, Infomap and
Leiden: both are popular and effective clustering tools that have been
deployed in different domains.

#### Infomap [12]

is an algorithm based on random walks and Huffman coding [20]. They frame the
partitioning of the graph into communities as a code optimization problem. To
find an efficient code, Infomap looks for a partition that minimizes the
expected description length of a random walk in the graph. In the resulting
partition, a community is made of a group of nodes among which information
flows quickly and easily.

#### Leiden [13]

is an improvement of Louvain [21], with Leiden guaranteeing well connected
communities. Both maximise the community modularity by isolating modules with
the most dense internal connections (i.e., higher structural cohesion) and the
least amount of connections between outside nodes (i.e., lowest structural
coupling). Leiden starts by assigning different communities to each vertex.
Then, it merges the nodes iteratively, based on the gain in modularity (if
there is no gain, the node remains in its current community). The procedure
stops when, moving a node into another community, there is no further gain in
the modularity.

###  II-C Semantic Cohesion from Source Code

The third step of our approach is based on the extraction of representations
of project’s source code. We used three popular document representation
techniques: TF-IDF, BERT, and fastText.

#### TF-IDF

is a measure that reflects the importance of a word in a document based on a
collection of documents. It is the ratio between the number of times the word
appears in the document and the amount of information that word provides. TF-
IDF does not capture the position in the text, semantics, co-occurrences in
different documents, meaning that the created representations are only useful
as lexical level features. However, unlike BERT and fastText, its vocabulary
adapts to the collection.

#### BERT [22]

is a state-of-the-art neural language model for learning dense vector
representation of words (embeddings). It makes use of the Transformer [23],
and learns contextual relations between words in a text. BERT representations
are contextual, meaning that word’s representation is based on the other words
in the sentence (context). In this paper we used the Hugging Face’s bert-base-
uncased pre-trained model [24]. Although this pre-trained model has a
vocabulary optimized for natural text, it also adopts a subword segmentation
technique called WordPiece [25] (e.g. playing becomes play $+$ #ing) that aids
with out-of-vocabulary words. While this provides additional bits of
information, some technical words are nevertheless poorly tokenized (e.g.
servlet becomes ser \+ #v \+ #let).

#### fastText [26]

is a neural embedding model that uses subword information to create word
embeddings. fastText words are split into n-grams, each having its own
embedding. The word embedding is an aggregation of the embeddings of all
n-grams that the word is made of. In contrast to BERT’s WordPiece subword
segmentation, fastText’s n-grams have the advantage that technical words are
less affected by a segmentation learned from non-technical corpora, due to the
smaller size subword information.

##  III Dataset

Our dataset is made by 412 Java projects. Each project has two distinct parts:
the structural information from the dependency graph and community detection
algorithms, and the semantic information extracted using Natural Language
Processing (NLP) techniques.

###  III-A Dependency Graph and Communities

We extract the dependency graphs using Arcan, and with the previously defined
community detection algorithm extract their communities. After extracting the
communities, we perform some pre-processing before carrying out our analysis.
The structural pre-processing includes the removal of the communities with
less than 4 nodes. This choice is driven by the fact that small sized
communities skew the result given their high cohesion, usually close to 1,
which will advantage algorithms that identify many small modules.

After the removal of the smaller communities we obtain the results in Figure 2
which summarises the distribution of the number and size of identified
components. Infomap has fewer communities, while their size is larger with
more outliers. Leiden extracts a larger number of smaller communities, and it
has fewer outliers.

Figure 2: Distribution of the number (left) and size (right) of the identified
communities.

###  III-B Document Embeddings

The extraction of features representing the documents is performed on two
conceptual levels, package- and class-names, and source code. We create four
different representation:

#### Embeddings from package- and class-names

The first feature extraction uses BERT to perform an embedding of the cleaned
text of the package and class name. The cleaning consists of splitting the
package name by dot; next, we remove the first two elements of the list as
they represent the organization that developed the software. The final step is
to split the camel case strings into words and remove any Java keyword. For
example org.antlr.v4.tool.LexerGrammar becomes “v4 tool lexer grammar”.

#### BERT embeddings from source code

The second feature extraction method also uses BERT; in this case, we perform
the embedding on the set of identifiers extracted from the source code file.
For the extraction of the identifiers contained in the source code, we used
the tree-sitter parser generator tool333https://github.com/tree-sitter/tree-
sitter. It makes easy to get the identifiers, without keywords, from the
annotated concrete syntax tree created using a grammar for Java code. We clean
the identifiers as before, and remove common Java terms that do not add much
semantically (e.g., ‘main’, ‘println’, etc).

#### fastText embeddings from source code

The third document representation solution focuses on the identifiers again,
but it uses fastText as the embedding model. For our experiments we use the
wiki.en pre-trained model.

#### TF-IDF bag of words from source code

The last feature extraction method uses TF-IDF for the creation of the
document embedding. To reduce the vocabulary, and normalize words, we use the
lemma of the identifiers as our tokens. Furthermore, for each of the analysed
systems, we limit the vocabulary size to the top $1,000$ terms (the mean
vocabulary size in our dataset is around $1,200$ tokens).

##  IV Experiments and Metrics

Below we describe the metrics that were used to evaluate Infomap and Leiden in
terms of semantic cohesion of components and separation between different
components.

###  IV-A Semantic Cohesion

We first evaluate the internal semantic cohesion of the components using the
cosine similarity. This should indicate how cohesive are the components found
by the CD algorithm.

The pairwise similarity is evaluated between all the vectors describing the
nodes in the community and then averaged. Then, for each project, we average
the internal similarities of all communities. Formally, we compute it as
follows:

$coh=\frac{1}{N}\sum_{k}^{N}\left(\frac{2}{|C_{k}|\cdot(|C_{k}|-1)}\sum_{i,j\land
i<j}^{|C_{k}|}sim(\textbf{x}_{k,i},\textbf{x}_{k,j})\right)$

where $N$ is the number of communities, $|C_{k}|$ is the cardinality of
community $k$ (with at least 4 nodes), $sim$ is the cosine similarity measure,
and $\textbf{x}_{k,i}$ is the $i$-th node of community $k$.

###  IV-B Semantic Separation

The extracted components should have low semantic similarity between each
other. This is measured by the cosine similarity between the representing
vectors of each community. Since each component is composed of many nodes,
each with its own embedding, the community vector is obtained aggregating in a
single vector all the information using the mean function. More formally:

$sep=\frac{2}{N\cdot(N-1)}\sum_{i,j\land
i<j}^{N}sim(\textbf{c}_{i},\textbf{c}_{j})$

where $\textbf{c}_{i}$ is the representation of the $i$-th community:

$\textbf{c}_{i}=\frac{1}{|C_{i}|}\sum_{j}^{|C_{i}|}\textbf{x}_{i,j}$

###  IV-C Silhouette

The average similarity scores above do not give a global idea of how well the
nodes are grouped together semantically. We can get a combined measure of both
the internal cohesion and external separation by using the Silhouette
coefficient[27]. This is a measure of how similar an object is to its own
cluster (cohesion), as compared to other clusters (separation). It uses the
information from the nodes to get an average quality score. For our
experiments we use the cosine distance.

###  IV-D Correlation Between Dependencies and Similarity

The final analysis measures the correlation between the number of dependencies
connecting the components and their semantic similarity.

We would like this score to be slightly negative, since having similar
components with a high dependency between each other might indicate  (i) that
the algorithm splits a component into two, or  (ii) that there are different
components that perform different parts of the same tasks.

For this experiment, we measured the number of edges between each community in
a pairwise fashion. We consider the edges as undirected and use the total
amount of dependencies between communities. Using the previously defined
features, we measured the semantic similarity between components. We used the
mean of the embeddings of each vector as the component representation. The
resulting representations are used to compute the pairwise similarities. We
compute the correlation of the two variables using Pearson’s $r$.

##  V Results and Discussion

The results of our analysis are presented in Table I. They are aggregated,
showing how many times either Infomap or Leiden is better than the other on
the specific metric.

We can notice that Infomap has in general a higher cohesion across all
features, while Leiden has a better separation between components. However,
the ‘Cohesion $>$ Separation (%)’, which measures the number of times (and the
percentage) the cohesion is higher than the separation in a project, shows
that although Leiden has better results when using TF-IDF, Infomap performs
better on the other three methods. Figure 3 shows the distribution of the
differences.

TABLE I: Aggregated results: numbers represent the # of projects in the sample. Bold highlights the better algorithm. | BERT | TF-IDF | fastText
---|---|---|---
Metric | Package | Document
|  Leiden |  Infomap |  Leiden |  Infomap |  Leiden |  Infomap |  Leiden |  Infomap
Cohesion |  $183$ |  229 |  $172$ |  240 |  $170$ |  240 |  $177$ |  235
Separation |  223 |  $189$ |  208 |  $204$ |  292 |  $190$ |  217 |  $195$
Silhouette |  256 |  $156$ |  251 |  $161$ |  323 |  $89$ |  234 |  $178$
Dep-Sim Corr |  $86$ |  326 |  $98$ |  314 |  $90$ |  322 |  $104$ |  308
Cohesion $>$ Separation (%) |  $85\;(20\%)$ |  140 (33%) |  $35\;(8\%)$ |  105 (25%) |  247 (60%) |  $222\;(53\%)$ |  $48\;(11\%)$ |  120 (29%)
Figure 3: Distribution of the difference between cohesion and separation
scores. Leiden is less scattered, however, it also has more negative scores.

Leiden shows better scores using the Silhouette metric: this result is
actually due to the fact that Infomap communities are larger in size, but
sparser in terms of semantic. This is reflected by nodes clustered in one
large component, but that are semantically closer to other components (see
Figure 4).

(a)

(b)

Figure 4: avro’s TF-IDF features reduced to two dimensions. The spatial
position of the node represents its semantic, the color (and label) the
component it belongs to. Leiden’s communities 2, 5, and 0 are scattered, while
the others are more cohesive. In Infomap community 0 spans the entire semantic
space, while communities 3, 1, and 2 are cohesive.

Lastly, we have the results of the correlation between the similarity of the
identified modules, and their dependency. In this experiment, Leiden is the
better algorithm in around $75\%$ of the cases. However, this score can be
influenced by having few very large communities and many smaller ones.

While the communities extracted by Infomap can become too large, this could be
fixed by running a multi-level extraction: the algorithm could be semi-
automatically forced to optimize its first partitioning by running over the
individual communities again. However, this will cause the opposite issue on
smaller graphs: this has to be further investigated in order to find the best
policy given the project size.

A threat to our methodology is the removal of the small communities. While the
choice might seem arbitrary, it also has to be considered that, beside skewing
the results, components with less than 4 nodes are unlikely to be of much
interest in large projects. Furthermore, the averaged representations and
similarities, and the small differences between the internal and external
similarity scores, give only a preliminary idea of what the algorithms really
identify. Lastly, the analyses are dependant on the chosen representation
technique: however, this threat is reduced by having four different
representation.

##  VI Conclusion and Future Work

In this work we compared two different community detection algorithms (Infomap
and Leiden) for identifying software components. We evaluated the algorithms
by using four different representation methods. The results show that Leiden
extracts more components with fewer nodes. Its components are less cohesive,
yet better separated, and their nodes are better clustered, but the components
depend more on similar ones. Infomap, on the other hand, creates fewer but
bigger components that are more cohesive, with slightly overlapping clusters
and are less likely to depend more on semantically similar components.

As future work, we plan to qualitatively evaluate each of the extracted
components individually, and to assess possible automatic refinements to the
content of the components based on their semantics. Furthermore, components
should be assigned a topic to make them easily understandable and accessible.
Lastly, we plan to evaluate other algorithms that use both the structural and
semantic information to assess if they achieve better results and consistency
across the different metrics.

## References

  * [1] G. Booch, _Software Component with ADA_. Benjamin-Cummings Publishing Co., Inc., 1987.
  * [2] N. Md Jubair Basha and S. A. Moiz, “Component based software development: A state of art,” in _IEEE-International Conference On Advances In Engineering, Science And Management (ICAESM -2012)_ , 2012, pp. 599–604.
  * [3] R. Holmes, _Pragmatic software reuse_. Citeseer, 2008.
  * [4] S. Chardigny, A. Seriai, M. Oussalah, and D. Tamzalit, “Extraction of component-based architecture from object-oriented systems,” in _Seventh Working IEEE/IFIP Conference on Software Architecture_ , 2008.
  * [5] A. Rathee and J. K. Chhabra, “Mining reusable software components from object-oriented source code using discrete pso and modeling them as java beans,” _Information Systems Frontiers_ , pp. 1–19, 2019.
  * [6] ——, “Improving cohesion of a software system by performing usage pattern based clustering,” _Procedia Computer Science_ , vol. 125, pp. 740 – 746, 2018.
  * [7] S. Mancoridis, B. S. Mitchell, C. Rorres, Y. Chen, and E. R. Gansner, “Using automatic clustering to produce high-level system organizations of source code,” in _Proceedings. 6th International Workshop on Program Comprehension. IWPC’98 (Cat. No.98TB100242)_ , 1998, pp. 45–52.
  * [8] Y. Chiricota, F. Jourdan, and G. Melancon, “Software components capture using graph clustering,” in _11th IEEE International Workshop on Program Comprehension, 2003._ , 2003, pp. 217–226.
  * [9] Jong Kook Lee, Seung Jae Jung, Soo Dong Kim, Woo Hyun Jang, and Dong Han Ham, “Component identification method with coupling and cohesion,” in _Proceedings Eighth Asia-Pacific Software Engineering Conference_ , 2001, pp. 79–86.
  * [10] S. Allier, H. A. Sahraoui, and S. Sadou, “Identifying components in object-oriented programs using dynamic analysis and clustering,” in _Proceedings of the 2009 Conference of the Center for Advanced Studies on Collaborative Research_ , ser. CASCON ’09, USA, 2009, p. 136–148.
  * [11] A. Lancichinetti and S. Fortunato, “Community detection algorithms: a comparative analysis,” _Physical review E_ , vol. 80, no. 5, 2009.
  * [12] M. Rosvall and C. T. Bergstrom, “Maps of random walks on complex networks reveal community structure,” _Proceedings of the National Academy of Sciences_ , vol. 105, no. 4, pp. 1118–1123, 2008.
  * [13] V. A. Traag, L. Waltman, and N. J. van Eck, “From louvain to leiden: guaranteeing well-connected communities,” _Scientific reports_ , vol. 9, no. 1, pp. 1–12, 2019.
  * [14] F. A. Fontana, I. Pigazzini, R. Roveda, D. Tamburri, M. Zanoni, and E. Di Nitto, “Arcan: A tool for architectural smells detection,” in _2017 IEEE International Conference on Software Architecture Workshops (ICSAW)_. IEEE, 2017, pp. 282–285.
  * [15] L. Pruijt, C. Köppe, J. M. van der Werf, and S. Brinkkemper, “The accuracy of dependency analysis in static architecture compliance checking,” _Software: practice and Experience_ , vol. 47, no. 2, pp. 273–309, 2017.
  * [16] R. Pawlak, M. Monperrus, N. Petitprez, C. Noguera, and L. Seinturier, “Spoon: A Library for Implementing Analyses and Transformations of Java Source Code,” _Software: Practice and Experience_ , 2015.
  * [17] G. Mazlami, J. Cito, and P. Leitner, “Extraction of microservices from monolithic software architectures,” in _2017 IEEE International Conference on Web Services (ICWS)_ , 2017, pp. 524–531.
  * [18] I. Şora, G. Glodean, and M. Gligor, “Software architecture reconstruction: An approach based on combining graph clustering and partitioning,” in _2010 International Joint Conference on Computational Cybernetics and Technical Informatics_. IEEE, 2010, pp. 259–264.
  * [19] W.-F. Pan, B. Jiang, and B. Li, “Refactoring software packages via community detection in complex software networks,” _International Journal of Automation and Computing_ , vol. 10, no. 2, 2013.
  * [20] D. A. Huffman, “A method for the construction of minimum-redundancy codes,” _Proceedings of the IRE_ , vol. 40, no. 9, pp. 1098–1101, 1952.
  * [21] V. D. Blondel, J.-L. Guillaume, R. Lambiotte, and E. Lefebvre, “Fast unfolding of communities in large networks,” _Journal of Statistical Mechanics: Theory and Experiment_ , vol. 2008, no. 10, oct 2008.
  * [22] J. Devlin, M.-W. Chang, K. Lee, and K. Toutanova, “BERT: Pre-training of deep bidirectional transformers for language understanding,” in _Proceedings of the 2019 Conference of the North American Chapter of the ACL: HLT, Volume 1_. Minneapolis, Minnesota: Association for Computational Linguistics, Jun. 2019, pp. 4171–4186.
  * [23] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention is all you need,” in _Advances in Neural Information Processing Systems, 2017, 4-9 December 2017, Long Beach, CA, USA_ , 2017, pp. 5998–6008.
  * [24] T. Wolf, L. Debut, V. Sanh, J. Chaumond, C. Delangue, A. Moi, P. Cistac, T. Rault, R. Louf, M. Funtowicz, J. Davison, S. Shleifer, P. von Platen, C. Ma, Y. Jernite, J. Plu, C. Xu, T. L. Scao, S. Gugger, M. Drame, Q. Lhoest, and A. M. Rush, “Huggingface’s transformers: State-of-the-art natural language processing,” _ArXiv_ , vol. abs/1910.03771, 2019.
  * [25] Y. Wu, M. Schuster, Z. Chen, Q. V. Le, M. Norouzi, W. Macherey, M. Krikun, Y. Cao, Q. Gao, K. Macherey, J. Klingner, A. Shah, M. Johnson, X. Liu, L. Kaiser, S. Gouws, Y. Kato, T. Kudo, H. Kazawa, K. Stevens, G. Kurian, N. Patil, W. Wang, C. Young, J. Smith, J. Riesa, A. Rudnick, O. Vinyals, G. Corrado, M. Hughes, and J. Dean, “Google’s neural machine translation system: Bridging the gap between human and machine translation,” _ArXiv_ , vol. abs/1609.08144, 2016.
  * [26] P. Bojanowski, E. Grave, A. Joulin, and T. Mikolov, “Enriching word vectors with subword information,” _Transactions of the Association for Computational Linguistics_ , vol. 5, pp. 135–146, 2017.
  * [27] P. J. Rousseeuw, “Silhouettes: A graphical aid to the interpretation and validation of cluster analysis,” _Journal of Computational and Applied Mathematics_ , vol. 20, pp. 53 – 65, 1987.


# FiloBass: A Dataset and Corpus Based Study of Jazz Basslines

###### Abstract

We present FiloBass: a novel corpus of music scores and annotations which
focuses on the important but often overlooked role of the double bass in jazz
accompaniment. Inspired by recent work that sheds light on the role of the
soloist, we offer a collection of 48 manually verified transcriptions of
professional jazz bassists, comprising over 50,000 note events, which are
based on the backing tracks used in the FiloSax dataset. For each recording we
provide audio stems, scores, performance-aligned MIDI and associated metadata
for beats, downbeats, chord symbols and markers for musical form.

We then use FiloBass to enrich our understanding of jazz bass lines, by
conducting a corpus-based musical analysis with a contrastive study of
existing instructional methods. Together with the original FiloSax dataset,
our work represents a significant step toward a fully annotated performance
dataset for a jazz quartet setting. By illuminating the critical role of the
bass in jazz, this work contributes to a more nuanced and comprehensive
understanding of the genre.

Figure 1: Flow diagram describing the main stages of the proposed method.

##  1 Introduction

The role of the double bass (also known as the string bass or upright bass) in
jazz is nearly ubiquitous as a time keeper, outliner of harmony and as an
occasional soloist. A key function is to play “walking bass”, where the
harmony of the song is outlined by playing chord tones on strong beats and
linking them with arpeggio, scale or chromatic movements on the remaining
beats in the bar. This style has emerged as a way to provide a rhythmic and
harmonic foundation to support a soloist. We believe that the harmonic
techniques that performers use to outline chord changes could provide
important information for enhanced understanding of jazz from an MIR
perspective, e.g. for generative models. Due to the relatively simple rhythmic
vocabulary, this style lends itself to algorithmic approaches which reduce the
problem to beatwise pitch predictions, as discussed in Section 2. However, we
recognize that this is a simplified view of bass performance, as bass lines
also contain rhythmic subtleties and other nuances which serve to increase the
interest and texture of the music over time.

The FiloSax dataset[1] addressed a need for high quality annotations[2] to
enable downstream tasks like automatic music transcription, score layout and
performance analysis. Building on this, we address the need for similarly high
quality data relating to the double bass as used in jazz, by turning our
attention to the backing tracks used to create that dataset. The backing
tracks are taken from the Aebersold series111http://jazzbooks.com/jazz/JBIO
and include performances by professional musicians.

Given the high quality of the bass playing on these tracks, we provide fine-
grained annotations to allow for detailed stylistic and harmonic analysis. We
believe that this represents the first large scale dataset to include detailed
performance timing for jazz bass, which in turn should allow for more
realistic generative modelling applications and better results for automatic
transcription models. The transcriptions have been carried out using a semi-
automatic pipeline which we describe in Section 3. Each note was checked
manually and additionally proof-read by a professional jazz bassist. We also
publish the extracted audio stems together with the transcriptions using the
SoundSlice platform222https://www.soundslice.com/ to allow for easy browsing
and evaluation333https://aim-qmul.github.io/FiloBass/. Audio, MIDI and
MusicXML artefacts along with the code to produce our analysis are available
to download via the same site.

##  2 Related work

Despite the important role of bass in the jazz genre, study of this subject
has often relied on fully manual transcriptions which are extremely labour
intensive to produce (see [3] for an example). To address the need for data on
a larger scale, important work was led by Abeßer et al. into automatic
transcription of bass lines in a jazz context[4, 5, 6]. One of the motivations
for their work was the idea that accurate bass transcriptions may be used to
derive information about the harmony of a song, which in turn could aid with
the task of automatic chord estimation. This resulted in 41 automatic bass
transcriptions (with manual verification) as part of the Weimar Jazz
Dataset[7] (WJD). These are beat-wise pitch transcriptions, meaning that they
are only a partial annotation of the performance, omitting information about
rhythmic details, which may limit the use of this dataset in some downstream
tasks such as performance analysis or generative modelling. Recent releases of
the WJD dataset have included a further 415 fully automatic transcriptions of
the bass notes for each beat.

The RWC-Jazz database[8] (a subset of the widely cited RWC dataset) provides
audio and aligned MIDI annotations for 5 pieces, which have multiple
recordings across a number of different instrument groupings which include
bass. Bass is included on 37 recorded tracks which total around 3 hours of
audio, however the audio is synthesised from samples of isolated notes and is
mixed rather than provided as individual audio stems. This allows for accurate
alignment at the expense of some realism in terms of articulation and dynamic
range.

Formal research into walking bass has also focused on rule-based generation
for modelling bass performances[9]. By incorporating rules described in
instructional materials for learning jazz bass, the authors were able to
construct a hidden Markov model (HMM) which produced musically relevant
results according to subjective listening tests. The authors mention a lack of
training data for this task and also note that they were unable to model
anything beyond beat-wise pitch estimation.

Outside of the jazz genre, Araz [10] describes a pipeline for transcribing
bass lines from electronic music. This approach relies on source separation to
extract a bass stem before transcribing it to quantised MIDI. This approach
assumes that the music is recorded at a fixed tempo, which is usually the case
for electronic genres however this is not usually the case for jazz
performances. The MedleyDB[11] dataset provides a large corpus of multitrack
audio recordings. Of these, 71 have been and annotated and resynthesised using
the process described in [12] to produce the MDB-bass-synth dataset. This
dataset is primarily aimed at training and evaluating framewise pitch
estimation (f0) methods. We also note the IDMT-SMT-Bass dataset[13] which
provides individual recordings of each note on an electric bass with a variety
of playing techniques. This may be a good basis for a synthetic dataset to
approach similar tasks. A summary of the available datasets is shown in Table
1.

Name | Annotation Method | Audio sources | Sync. level | Track count | Duration (s) | Note count | Additional Metadata | Scores
---|---|---|---|---|---|---|---|---
WJD Bass | Automated + Manual | Audio mix | Beat | 41 | 1851 | 5000 | Downbeat, Chord | No
WJD v2.2 | Automated | Audio mix | Beat | 456 | 49010 | 122540 | Downbeat, Chord | No
MDB-bass-synth | Automated | Audio mix, Audio stems | Frame | 71 | 14393 | N/A | None | No
RWC-Jazz | Manual | Audio mix | Note | 37 | 10878 | 19183 | Downbeat, Chord | No
IDMT-SMT-Bass | N/A | Individual notes | N/A |  | 12960 | 4300 | None | No
FiloBass (ours) | Automated + Manual | Audio mix, Bass stem | Note | 48 | 17880 | 53646 | Downbeat, Chord | Yes

Table 1: Comparison of existing bass datasets

##  3 Methodology

We now describe the process used to create the dataset which is summarised in
Figure 1. We would like to emphasise that the work was carried out by the main
author, a semi-professional bassist, and later checked and verified by another
professional jazz bassist. Despite the use of automatic methods, every note
was checked manually at least twice as a result. While this process was
expensive in terms of time spent, the resulting increase in accuracy will
provide a solid foundation for future methods.

###  3.1 Audio Recordings

All of the 48 backing tracks in this dataset are recorded in a standard format
using professional jazz musicians. Details of the performers are shown in
Table 2. They feature a jazz trio (piano, bass and drums) with bass panned to
the left, drums panned centrally and piano panned to the right. This allows
for convenient separation of bass and drums by using a single channel of
audio. We are able to further isolate this single channel to obtain a bass
stem using the Demucs source separation tool[14]. The producers of these
tracks (Aebersold) have a catalogue of over 1300 tracks recorded in a similar
fashion, which means that this approach could be applied to additional tracks
in the future.

Name | Track count | Note count | Born
---|---|---|---
Christian Doky | 1 | 1401 | 1969
Dennis Irwin | 1 | 1321 | 1951
John Goldsby | 3 | 2564 | 1958
Lynn Seaton | 1 | 1278 | 1957
Michael Moore | 1 | 753 | 1945
Ray Drummond | 2 | 2181 | 1946
Ron Carter | 5 | 5885 | 1937
Rufus Reid | 14 | 15280 | 1944
Steve Gilmore | 10 | 12323 | 1943
Todd Coolman | 3 | 3952 | 1954
Tyrone Wheeler | 6 | 5474 |  1965
Wayne Dockery | 1 | 1050 | 1941

Table 2: Details for each bassist in the dataset

###  3.2 Transcription

For the initial transcription of performance MIDI, we opted to use the
commercial program Melodyne444https://www.celemony.com/en/melodyne/what-is-
melodyne, specifically their “Melodic” detection algorithm. This is more
typically used for editing vocal performances, however the pitch tracking and
note segmentation proved to be broadly accurate for the separated bass stems.
The program also offers a convenient interface to edit onsets and pitches
manually in cases where the automatic analysis was judged to be incorrect.
Each of the 48 scores were loaded into Melodyne and manually corrected where
necessary.

To produce a score from the performance MIDI we employed a multi-step process.
The first step was to import the existing downbeat annotations from the
FiloSax dataset into Melodyne. We then used the “Make tempo constant” feature
of Melodyne to produce a new file in which variations in the tempo were
removed and the note positions rescaled accordingly. For those without access
to Melodyne, we note that a similar result could be achieved using the
adjust_times function from the PrettyMIDI library[15].

From this constant tempo version, we export a MIDI file from Melodyne and then
import this into MuseScore 3555https://musescore.org/en using their MIDI
import procedure. This was found to work better when the tempo was made
constant first. This yields a score representation, however the variations in
timing can produce non-idiomatic representations in the score which need to be
corrected. This was done by exporting MusicXML and performing the final
corrections using the SoundSlice platform, which allowed the transcription to
be edited with reference to the synchronized audio from the original bass
stem. Chord annotations are then copied from the FiloSax metadata and all 48
scores were checked by a professional jazz bassist to ensure accuracy and
readability.

Finally, we used the alignment method proposed by Nakamura et al. [16] to
realign the final score representation to the original MIDI performance data.
This step is necessary to obtain a 1-to-1 correspondence in note annotations
between score and performance MIDI. However, after working with these
annotations we found that the timing information in the performance MIDI
produced by Melodyne was not of sufficiently high quality. This resulted in
issues when evaluating automatic transcription methods (see 5). To improve the
alignment quality further, we align the MIDI to the model activations of a
pre-trained guitar transcription model following the work of Maman and
Bermano[17]. The realigned MIDI outputs are included in the final dataset.

###  3.3 Repeated Passages

During the construction of the original FiloSax dataset, one of the objectives
was to capture a consistent amount of saxophone data for each track. Since the
original backing tracks varied in length, the authors edited the original
backing tracks to repeat certain sections (usually complete choruses) in order
to meet their criteria. This impacts the production of this dataset in that
some passages are repeated exactly, however they were transcribed by treating
them as a complete performance. This may lead to slight variations in how the
rhythmic figures are notated which may be an issue for certain downstream
tasks, for example introducing a bias in generative models. We recognise this
and will provide instructions on how to remove the repeated sections if
desired. Otherwise we provide transcriptions for each track in its entirety to
allow for easy alignment with the existing FiloSax data.

###  3.4 Double Stops, Grace Notes and Ghost Notes

The source material used for this dataset is predominantly monophonic in
nature, however the performers do make use of double stops (polyphony) in some
places. We have transcribed these in the score and alignments but we also
provide a monophonic version of the dataset with a view to ease of use in
downstream tasks. The use of effects such as grace notes (extremely short
notes) or ghost notes (where the string is partially or fully dampened to
produce a percussive sound) is prevalent throughout the dataset and these can
be viewed as an important aspect of the style. A guiding principle for
producing the score representation is that they are readable by a sufficiently
experienced bassist. With this in mind, we have notated ghost notes where
these can be clearly heard on the recording however in cases where these
effects were judged to be subtle or fleeting we have omitted them. We
understand that this approach could be seen as subjective but we did so to
prioritise the goal of making a readable and idiomatic score output over a
completely consistent yet less readable score.

###  3.5 “Common Practice” versus Real Performance

The backing tracks used to create this dataset were originally conceived as
practice aids for instrumental soloists. As such, the performances on these
tracks could be viewed as a sort of “common practice” of jazz accompaniment.
The performers focus on outlining chord changes and rhythms clearly to allow
the soloist to focus on their role. This aspect of the data makes it a
valuable example for studying how these accompaniments are constructed.
However, they may not be entirely representative of performances from live or
studio recordings, as musicians may be more inclined to take musical risks in
those settings. For this reason, the figures that we derive in our later
analysis might not be fully representative of live or studio performance. A
comparison is a potential area for exploration in future work.

###  3.6 Dataset Contents and Distribution

The final dataset comprises 48 tracks with contents as follows: Melodyne
project files, audio mixes, isolated bass stems (from source separation
software), performance-aligned MIDI with velocity information, and music
scores in MusicXML format. We also include metadata which was compiled as part
of the FiloSax dataset which includes timings for chords, sections, beats and
downbeats.

As discussed in [1], the backing tracks themselves are subject to copyright
restrictions so we are unable to release these. However, we provide
instructions on how to obtain the files from the original provider. All other
assets (including the source-separated stems) will be made freely available to
researchers.

##  4 Analysis

We now present a corpus analysis of the data in which we demonstrate the
potential for insights on a musical level. As a starting point, we seek to
answer some queries about the harmonic and rhythmic functions of a typical
walking bass line as represented in the data. A number of commercial jazz bass
methods from different authors are summarised in [3] which we will refer to
where appropriate. All analyses which follow were derived from the dataset by
converting note-level information to a Pandas[18] dataframe using the Music21
Python library[19]. The queries used to perform the analysis will be released
alongside the dataset.

###  4.1 Chord Degrees Used in Bass Line Construction

As jazz performance is a cultural practice, a strict set of rules for bass
line construction has not been established. However, given the size of the
proposed dataset we can start to provide a quantitative analysis of the
choices made by performers during their improvisations.

Concerning the question of which chord degrees are favoured by the player, we
analyse the function of each note in the dataset as it relates to the chord
being played underneath it. In Figure 2 we see that bassists will favour the
root note of the chord when constructing walking bass lines, as these are used
in 32.7% of all notes played. This is rather basic from a musical perspective,
but we can now point to data that bolsters existing empirical observations.
When we examine the note played at each new chord change event, we see from
Figure 2 that the use of chord roots is even more prevalent, with the
proportion rising to 67.9% of the total. This reflects the role of the bass in
outlining the harmony of the song.

###  4.2 Use of Rhythmic Fills versus Quarter Note Pulse

In his educational method book, bassist Ron Carter [20] describes the process
of adding rhythmic interest, or “fills”, to a line. However, he cautions the
student “not to overdo” their use before advising that: “personal tastes and
judgement will govern this area of your playing”. We can make an attempt to
quantify this more precisely by examining what percentage of measures in the
dataset contain a simple set of 4 quarter notes, and which deviate from this.
We find that 62.81% of measures are indeed 4 quarter notes. While this is not
a substitute for developing good taste, knowing this percentage might help in
guiding a more analytical player.

Figure 2: Global distribution of chord degrees

###  4.3 Deriving Common Patterns

Pattern |  Count |  % of total
---|---|---
| 360 |  4.6%
| 195 |  2.5%
| 113 |  1.43%
| 113 |  1.43%
| 111 |  1.41%
Table 3: The five most common chord degree n-grams for 7898 chord instances
lasting 4 or more beats. Examples are notated in C major for illustration.

The annotations in this dataset also allow us to examine sequences of chord
degrees that are commonly used in bass line construction. Over the 6400 chord
symbols annotated, 3900 distinct patterns of chord degrees over chords are
played. The 5 most common patterns for a chord lasting 4 beats are shown in
Table 3. From these we can see a preference towards using tones from major and
minor triads (i.e. 1, $\flat$3, 3 and 5). Given that the root movements in
jazz are often perfect 4ths apart, we see that a number of the patterns
approach the 4th via tones or semitones (i.e. from $\flat$3, 3, $\flat$5 or
5). This analysis of patterns only considers the chord degree, however a more
detailed examination of patterns including sequential ideas and motifs is a
subject of future work.

###  4.4 Semitone and V-to-I Approaches

In “Creating Jazz Basslines”, author Jim Stinnet emphasises the use of
semitone approaches. This is where target notes which fall on strong beats or
chord changes are preceded by a note which is a semitone above or below the
target (described in [3]). In this dataset we observe that this is indeed
common, with ascending and descending semitones being the most often used
intervals overall as shown in Figure 3. For notes which land on chord changes,
semitone approaches are even more prevalent. We summarise the most common
intervals to approach chord changes (target tones) in Table 4.4.

In the “Walking Bassics” by Fuqua, Zisman, and Sher (described in [3]), the
authors advocate the use of V to I movements for students however our data
suggests that this is relatively uncommon in practice (9.66% ascending a
perfect fourth and 4.30% descending). This is an interesting example of an
idea that seems intuitive in theory (V to I is a strong bass movement for
walking bass) but is not reflected in practice.

Approach |  Interval to target |  Count |  % of total
---|---|---|---
D $\searrow$ C |  $-1$ |  4318 |  26.75
B $\nearrow$ C |  $+1$ |  3384 |  20.97
B $\nearrow$ C |  $+2$ |  1921 |  11.90
G $\nearrow$ C |  $+5$ |  1560 |  9.66
C $\rightarrow$ C |  $0$ |  1172 |  7.26
G $\searrow$ C |  $-7$ |  694 |  4.30
D $\searrow$ C |  $-2$ |  656 |  4.06

Table 4: The most common intervals used to approach a chord change (totalling
16141 events). For illustration all approaches are shown relative to a target
tone of C.

###  4.5 Step, Leap or Staying Put?

As we have seen in Section 4.1, in the majority of cases the performer will
aim to play root notes when a new chord arrives but this leaves the question
of how these root notes are typically connected together into a musically
pleasing line. From the data, we can examine whether performers tend to use
step-wise motion (tones and semitones), larger intervalic leaps (minor thirds
or greater) or whether they choose to repeat a note. Looking at Figure 3 we
see that there is a slight preference toward using step-wise motion (the
largest group at 47.5%). Viewing the interval distribution plot we can also
see that intervalic leaps are slightly more likely when the line is ascending
especially for the interval of 5 semitones which corresponds to a perfect
fourth.

Figure 3: Distribution of intervals, grouped as step-wise movements (2
semitones or less), leaps (3 or more semitones) or repeats (no change from the
preceding note).

###  4.6 Melodic Contour

The performer has a number of parameters available when improvising a bass
line, one of which is the direction of the line. Sigi Busch (summarised in
[3]) refers to the idea of “voice leading” within a bass line to link
important chord tones while maintaining a direction, but none of the other
methods summarised in [3] advise on how to choose directions or when to change
them. Referring to the data now, we can see in Figure 4 that a high number of
changes in direction is preferred, with the mean length of a sequence before a
change falling at 2.46 notes. Intriguingly, the distribution of sequence
lengths exhibits a power law. This phenomenon has been observed in several
cases when analysing symbolic music corpora[21] but to our knowledge this is
the first evidence in relation to walking bass lines.

Figure 4: Sequence length (number of intervals) of lines maintaining a
constant direction.

##  5 Automatic Transcription Baseline

Using the accurate alignment data we have collected, we provide initial
results for automatic note transcription — a bass line baseline. An exhaustive
appraisal of transcription accuracy is beyond the scope of this work but we
hope these results will encourage the use of this dataset in related future
work.

We use the mir_eval [22] library to calculate precision, recall, F-measure and
overlap scores. A default threshold of 50ms was used and only onset timings
were considered. This is due to the difficulty of assessing offsets, as
described in [23]. Three methods are examined for this task; the “Basic Pitch”
package described in [23], the “CREPE Notes” method proposed in [24] and the
commercial software Melodyne using the “Melodic” algorithm. The results from
Melodyne were not manually corrected for this evaluation. Results for all
methods are shown in Table 5. We see from these results that the proprietary
commercial software outperforms the best research solutions for this dataset,
however a significant amount of work is required to correct the remaining
errors. During this work we also appreciated the Melodyne UI for note editing
during our manual correction process. We note that similar projects in future
may benefit from open source tools that allow a more streamlined note
correction workflow.

| CREPE Notes | Basic Pitch | Melodyne
---|---|---|---
Rno | $74.11\pm 12.09$ | $81.28\pm 6.26$ | $79.52\pm 14.77$
Pno | $71.81\pm 13.33$ | $51.40\pm 6.28$ | $78.48\pm 15.41$
Fno | $72.89\pm 12.68$ | $62.73\pm 5.55$ | $78.95\pm 15.02$
O | $78.77\pm 2.68$ | $65.24\pm 4.51$ | $87.94\pm 3.91$
Table 5: Automatic note transcription results for FiloBass, showing mean
scores and standard deviation for Recall, Precision, F-measure and Overlap.
Only onsets were evaluated and a timing tolerance of 50ms was used.

##  6 Discussion and Future Work

In collating a dataset and performing a corpus analysis with reference to jazz
bass methods, we hope to have provided useful insights into the role of the
bass in jazz. The analysis provided here is not exhaustive however, and we
hope that future research can reveal more about the mental model that
performers use when constructing their bass accompaniment. In particular we
hope to examine the role of timing, dynamics and use of sequential ideas in
further work. We are also interested in pairing the FiloBass data with the
FiloSax data for further analysis. The relationships between bass line and
melody in a jazz setting could be explored further, with a view to developing
more realistic generative models for both bass lines and solos.

We believe that the dataset has a wide number of potential uses beyond
musicological analysis. Recent work on automatic music transcription (AMT) has
highlighted that performance can be improved as more data is made available[2]
and this dataset can help to address this need.

An additional task which we hope to address in future is that of automatic
chord estimation (ACE). Following the hypothesis of Abeßer et al. [4], we
believe that this data could be used to train a system to estimate chords from
the bass line directly. Chord estimation is a particularly challenging task in
the jazz setting due to the rich harmonic vocabulary so novel approaches here
may be welcome.

The scores which were produced as part of this data should also be valuable to
researchers, as they provide a potential source of training data and
evaluation for monophonic score processing tasks. In particular, they will be
useful for rhythmic parsing (quantisation), automatic score layout and related
sub-tasks such as spelling of accidentals.

##  7 Conclusions

We present FiloBass: a new dataset for jazz bass lines. Making use of the
detailed annotation data, we are able to demonstrate a quantitative approach
to reinforce traditional musicological analysis of the role of the bass in
jazz performance.

Through examination of this dataset we demonstrate that a number of rules put
forward in jazz bass method books are supported by larger scale data. These
can be summarised as follows: the root note of the chord is usually played on
the first beat of a new chord; this root is approached via a semitone step
where possible; the rhythm comprises a quarter note pulse most of the time; a
balance is maintained between ascending and descending contours. We are aware
though, that any analytical project of this sort cannot be truly comprehensive
and can only offer a guide to the performer. The musical context and the taste
and experience of the musician will determine when to follow the “default”
most likely path and when to choose a different route.

##  8 Acknowledgements

The first author is a research student at the UKRI Centre for Doctoral
Training in Artificial Intelligence and Music, supported by UK Research and
Innovation [grant number EP/S022694/1].

## References

  * [1] D. Foster and S. Dixon, “Filosax: A dataset of annotated jazz saxophone recordings,” in _Proceedings of the 22nd International Society for Music Information Retrieval Conference_ , Online, 2021, pp. 205–212.
  * [2] J. Gardner, I. Simon, E. Manilow, C. Hawthorne, and J. H. Engel, “MT3: multi-task multitrack music transcription,” in _Tenth International Conference on Learning Representations (ICLR)_ , 2022.
  * [3] H. Pinheiro, “Jazz bass method books versus actual performance: The case study of Charlie Haden,” Master’s thesis, University of Louisville, 2018. [Online]. Available: https://ir.library.louisville.edu/etd/2939
  * [4] J. Abeßer, S. Balke, K. Frieler, M. Pfleiderer, and M. Müller, “Deep learning for jazz walking bass transcription,” in _AES International Conference on Semantic Audio_. Audio Engineering Society, 2017.
  * [5] J. Abeßer and S. Balke, “Improving bass saliency estimation using label propagation and transfer learning,” in _Proceedings of the 18th International Society for Music Information Retrieval Conference_ , Paris, France, 2018, pp. 306–312.
  * [6] J. Abeßer and M. Müller, “Jazz bass transcription using a U-Net architecture,” _Special Issue on Machine Learning Applied to Music/Audio Signal Processing, Electronics_ , vol. 10, no. 6, Jan. 2021.
  * [7] K. Frieler, F. Höger, M. Pfleiderer, and S. Dixon, “Two web applications for exploring melodic patterns in jazz solos,” in _Proceedings of the 18th International Society for Music Information Retrieval Conference_ , Paris, France, 2018, pp. 777–783.
  * [8] M. Goto, “Development of the RWC Music Database,” in _Proceedings of the 18th International Congress on Acoustics (ICA)_ , vol. 1, 2004, pp. 553–556.
  * [9] A. Shiga and T. Kitahara, “Generating walking bass lines with HMM,” in _Perception, Representations, Image, Sound, Music CMMR_. Springer International Publishing, 2021, pp. 248–256.
  * [10] O. Araz, “Automatic bassline transcription for electronic music,” in _Late Breaking Demo at the 22nd International Society for Music Information Retrieval Conference_ , 2021. [Online]. Available: https://archives.ismir.net/ismir2021/latebreaking/000016.pdf
  * [11] R. M. Bittner, J. Salamon, M. Tierney, M. Mauch, C. Cannam, and J. P. Bello, “MedleyDB: A multitrack dataset for annotation-intensive MIR research,” in _Proceedings of the 15th International Society for Music Information Retrieval Conference_ , Taipei, Taiwan, 2014, pp. 155–160.
  * [12] J. Salamon, R. M. Bittner, J. Bonada, J. J. Bosch, E. Gómez, and J. P. Bello, “An analysis/synthesis framework for automatic F0 annotation of multitrack datasets,” in _Proceedings of the 18th International Society for Music Information Retrieval Conference_ , Suzhou, China, 2017, pp. 71–78.
  * [13] J. Abeßer, H. Lukashevich, and G. Schuller, “Feature-based extraction of plucking and expression styles of the electric bass guitar,” in _2010 IEEE International Conference on Acoustics, Speech and Signal Processing_ , Mar. 2010, pp. 2290–2293.
  * [14] S. Rouard, F. Massa, and A. Défossez, “Hybrid transformers for music source separation,” Nov. 2022, arXiv:2211.08553 [cs, eess]. [Online]. Available: http://arxiv.org/abs/2211.08553
  * [15] C. Raffel and D. P. W. Ellis, “Intuitive analysis, creation and manipulation of MIDI data with pretty_midi,” in _Late Breaking Demo at the 22nd International Society for Music Information Retrieval Conference_ , 2014. [Online]. Available: https://ismir2014.ismir.net/LBD/LBD29.pdf
  * [16] E. Nakamura, K. Yoshii, and H. Katayose, “Performance error detection and post-processing for fast and accurate symbolic music alignment,” in _Proceedings of the 18th International Society for Music Information Retrieval Conference_ , Suzhou, China, 2017, pp. 347–353.
  * [17] B. Maman and A. H. Bermano, “Unaligned supervision for automatic music transcription in the wild,” in _International Conference on Machine Learning_ , vol. 162. ICML, 2022, pp. 14 918–14 934.
  * [18] W. McKinney _et al._ , “Data structures for statistical computing in Python,” in _Proceedings of the 9th Python in Science Conference_ , vol. 445. Austin, TX, 2010, pp. 51–56.
  * [19] M. S. Cuthbert and C. Ariza, “Music21: A toolkit for computer-aided musicology and symbolic music data,” in _Proceedings of the 11th International Society for Music Information Retrieval Conference_ , Utrecht, Netherlands, 2010, pp. 637–642.
  * [20] R. Carter, _Building Jazz Bass Lines_ , ser. Bass Builders. Hal Leonard, 1998.
  * [21] D. Rafailidis and Y. Manolopoulos, “The power of music: Searching for power-laws in symbolic musical data,” in _12th Panhellenic Conference on Informatics_ , Jan. 2008.
  * [22] C. Raffel, B. McFee, E. J. Humphrey, J. Salamon, O. Nieto, D. Liang, and D. P. W. Ellis, “A transparent implementation of common MIR metrics,” in _15th International Society for Music Information Retrieval Conference_ , 2014.
  * [23] R. M. Bittner, J. J. Bosch, D. Rubinstein, G. Meseguer-Brocal, and S. Ewert, “A lightweight instrument-agnostic model for polyphonic note transcription and multipitch estimation,” in _2022 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP)_ , 2022, pp. 781–785.
  * [24] X. Riley and S. Dixon, “CREPE Notes: A new method for segmenting pitch contours into discrete notes,” in _Proceedings of the 20th Sound and Music Computing Conference_ , Stockholm, Sweden, 2023, pp. 1–5.