Content-based Filtering System for Music Data
Kazuhiro Iwahama Yoshinori Hijikata and Shogo Nishida
Graduate School of Engineering Science, Osaka University
1-3 Machikaneyama, Toyonaka Osaka 560-8531, JAPAN
iwahama@nishilab.sys.es.osaka-u.ac.jp
Abstract
Recommender systems, which recommend appropriate
information to users from enormous amount of information,
are becoming popular. There are two methods to realize rec-
ommender systems. One is content-based filtering, and the
other is collaborative filtering. Many systems using the for-
mer method deal with text data, and few systems deal with
music data. This paper proposes a content-based filtering
system that targets music data in MIDI format. First, we
analyze characteristics of feature parameters about music
data in MIDI format. Then we propose a filtering method
based on the above feature parameters. Finally, we build a
prototype system with standard technology of the Internet.
1 Introduction
With the development of the Internet, the quantity of in-
formation is explosively increasing. In this situation, users
need to acquire appropriate information from the huge net-
work of information. On the other hands, information
providers need to provide appropriate information depend-
ing on customers. Providing customers with appropriate in-
formation is expected as one of the functions in CRM (Cus-
tomer Relationship Management)[12], which is emphasized
in e-business[1] recently.
In the early days of the Internet, most of the data were
text because the bandwidth was limited. However recently,
the major portal sites such as amazon.com and Yahoo! are
beginning to distribute music data like MP3 and RealPlayer.
Therefore, we think that the above-mentioned needs for the
users and the information providers will increase.
Recommender systems have been studied to support the
users to acquire information[9][7]. Recommender systems
provide users with appropriate information that meet their
preferences or interests from enormous amount of informa-
tion. There are two methods for realizing recommender sys-
tems. One is content-based filtering, and the other is collab-
orative filtering. Many systems using the former method
Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
deal with text data, and few systems deal with music data.
We construct a content-based filtering system for mu-
sic data. The target data of our system are not written in
MP3 or RealPlayer which record audio wave but are writ-
ten in MIDI data which record note data. We aim to vali-
date how effectively content-based filtering works for music
data. The music data used in our system are popular mu-
sic because popular music is most distributed in the market.
The filtering method is as follows. The system extracts fea-
ture parameters from both of music data that the user has
already rated in questionnaire and target music data for rec-
ommendation. The system compares both the feature pa-
rameters by using classification algorithm (Concretely, we
use a decision tree). Then, the system recommends mu-
sic data that the user will like. The system will reduce the
users’ burden in acquiring music data.
The paper is organized as follow. Section 2 describes
the approach of our research and Section 3 reviews related
works. Section 4 explains feature parameters used in our fil-
tering system. Section 5 explains our filtering method based
on the above feature parameters. Finally, in Section 6, we
offer some summaries and future works.
2 Outline of Research
Section 2.1 presents the overview of our filtering
method. Section 2.2 explains the procedure of our research
to construct the filtering system.
2.1 Overview of Our Filtering System
We use MIDI data as music data. Compared with data
of audio wave, MIDI data allow us to easily extract many
features about music because MIDI data are note data. Al-
though, MIDI data are used in our system, the system can
recommend not only MIDI data but also MP3 or RealPlayer
data. Because if the system can specify the name of the mu-
sic data, the system can recommend MP3 or RealPlayer data
corresponding to the name.

Figure 1. Overview of Our Filtering System
Figure 1 shows the overview of our filtering system.
The user rates several music data from the viewpoint that
whether the user prefers them or not. The system extracts
feature parameters from the rated music data. Feature pa-
rameters consist of attribute and attribute value and repre-
sent the characteristics of music data. The system builds
a user profile, which represents the user’s preference about
music, based on the extracted feature parameters. The sys-
tem extracts feature parameters from target music data and
compares those feature parameters with the user profile.
From the result of the comparison, the system selects music
data that the user will like, and recommends the music data.
2.2 Procedure of Research
The procedure of our research is as follows.
• Step 1: Survey of MIDI data of popular music and de-
cision of feature parameters for our filtering system.
Firstly, we enumerate feature parameters that are gen-
erally major in music or that are used in existing music
information retrieval systems. Then, we implement a
program that extracts those feature parameters. We see
the distribution of those feature parameters by using
many real MIDI data. Finally, we select the feature
parameters which have wide dispersion as feature pa-
rameters for our filtering system.
• Step 2: Proposal of a filtering method that uses the
feature parameters selected in Step 1.
We design a user profile and a content model, and de-
vise a comparison method between the user profile and
the content model.
• Step 3: Implementation of the filtering system.
To aim to apply our system to real commercial sites,
we implement the system in Java and Java servlet,
which are standard technologies of the Internet.
Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
• Step 4: Evaluation of the filtering system.
We evaluate the system by precision (the percentage
of the user’s favorite music data out of the music data
recommended by the system) and recall (the percent-
age of the music data recommended by the system out
of the user’s favorite music data).
3 Related Work
A study on a recommender system for music data is done
by Uitdenbogerd and Schyndel[11]. It explains that factors
such as tempo, rhythm and tonality affect music preference.
It also explains that content-based filtering and collabora-
tive filtering are applicable to recommender systems for mu-
sic data. This study presents only a few factors which af-
fects success of music recommender systems, but does not
devise a practical filtering method and does not develop a
recommender system. We survey on feature parameters of
music data, devise a content-based filtering method, and im-
plement a music recommender system.
Chen[2] and Kurose[6] implemented recommender sys-
tems for music data. These systems recommend music data
by using a content-based filtering. Their filtering meth-
ods are as follows. Their methods express feature param-
eters as factors in a vector and select recommended music
data based on the distance of their vectors. Therefore, their
methods cannot select recommended data by focusing on
each feature parameter. Our system uses a decision tree that
focuses on each feature parameter and selects music data
using a threshold to the feature parameter. Our research
presents a content-based filtering method with the ability of
fine-grained classification.
4 Feature Parameters for Our Filtering Sys-
tem
This section surveys feature parameters of music data in
MIDI format and decides which feature parameters to use
in our filtering system. Firstly, we enumerate feature pa-
rameters that are generally major in music or that are used
in existing music recommender systems and existing mu-
sic information retrieval systems, and see the distribution of
those feature parameters by using real MIDI data. Then, we
select the feature parameters which have wide dispersion as
feature parameters for our filtering system.
4.1 Form of Feature Parameters
Before surveying feature parameters of music data, we
need to decide which form of feature parameters we should
survey. Feature parameters of music data can be expressed
 in both of the pairs of attribute and attribute value and time-
series patterns. In music information retrieval systems, their
purpose is to output music data that matches a search query
given by a user. Therefore their feature parameters are not
only the pairs of attribute and attribute value but also time-
series patterns. For example, in the case that a user inputs
a hum by using a microphone, the system expresses the
phrase input by the user in the form of time-series pattern
and outputs music data which have the same pattern. How-
ever, information filtering systems select music data that
matches a user profile. The system must estimate which
kinds of music the user generally prefers from the set of the
user’s favorite songs. In order to estimate these tastes in mu-
sic, the system needs the feature parameters which express
not the features of local part of music but the features of the
whole music. Therefore, this section surveys music data by
focusing on feature parameters which are represented in the
form of the pairs of attribute and attribute value.
There are two kinds of feature parameters in the form
of the pairs of attribute and attribute value. One of them is
extracted in every channel (CH) and the other is common
for all CH. Our system extracts feature parameters in entire
music, melody CH, chord CH, base CH and drum CH. This
is because our research targets pop music, which mainly
consists of the above four parts.
4.2 Candidates of Feature Parameters
From feature parameters used in existing music infor-
mation retrieval systems, we select tempo, tonality, rhythm,
tone, meter, pitch, the difference of pith and the differ-
ence of duration as candidates of feature parameters. They
are used by many researchers such as Chen[2], Kurose[6],
Ikezoe[4], Satou[10], Kumamoto[5] and Clausen[3]. Note
that the average of pitch is calculated from the pitches be-
tween a note and its next note and that the average of du-
ration is calculated from the durations between a note and
its next note. There are some feature parameters that are not
used in the existing music information retrieval systems, but
that are likely to express features of music data. From such
feature parameters, we select the number of changing tonal-
ity, the percentage of chord type and key. This is because
they can be extracted from many music data with ease and
they do not depend on writers’ ability to create MIDI data
(Writers with high technique can create MIDI data adding
various effects. Our research uses features which are seen in
any music data created by not only expert writers but also
amateur writers). Table 1 shows the candidates of feature
parameters used in our filtering system.
Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
Table 1. Candidates of Feature Parameters
the whole music 1. meter, 2. tonality
3. the number of changing tonality
4. average tempo, 5. rhythm
6. the percentage of major chord
7. the percentage of minor chord
8. the percentage of sus4 chord
9. key
each CH 10. tone, 11. average pitch
12. average difference of pitch
13. average duration
14. average difference of duration
4.3 Extraction of Feature Parameters
In Table1, Feature parameters 1 to 4 and Feature param-
eters 10 to 12 are written explicitly in MIDI data. Feature
parameters 13 and 14 are extracted by using note on event,
note off event and delta time between the two events. Fea-
ture parameter 5 is extracted by the method that Ikezoe[4]
uses. The extraction of Feature parameters 6 to 9 requires
the estimation of the chord. The chord type is estimated
in each half measure (The chord of popular music mainly
changes in less than a half measure). Our estimation method
of the chord type is as follows. Firstly, all notes in a half
measure are collected and a root note is calculated from col-
lected notes. After that, the chord type is estimated by the
relationship between the root note and the other notes. A
key is estimated based on root notes.
4.4 Estimation of CH
In order to acquire feature parameters in each CH, the
system has to estimate each CH. Drum CH, base CH and
chord CH are estimated easily with nearly 100% accuracy.
However, it is not easy to estimate melody CH with high ac-
curacy. Therefore, we survey features of melody CH. From
the result of survey, we estimate melody CH by using the
average difference of pitch, the number of notes performed
at the same time and CH number (See the detail in the ap-
pendix). We conducted an experiment by using other 50
MIDI data to see whether or not melody CH is correctly es-
timated. As a result, this method estimates melody CH with
94% accuracy.
4.5 Decision of Feature Parameters
30 MIDI data validate how effectively feature parame-
ters explained in Section 4.2 classify music data. Figure 2
shows the results of dispersion of the feature parameters.
 Figure 2. Dispersion of Feature Parameters
The dispersion is calculated by dividing the standard devia-
tions of the feature parameters by their averages. In Figure
2, ”diff.” means that there is difference and ”no diff.” means
that there is no difference. ”N/A” means that the feature
parameter cannot be extracted.
We decide which feature parameters to use in our filter-
ing system from the results. First we selected meter and
tonality from the candidates of feature parameters, because
these two feature parameters have been traditionally used to
classify music data. Then, we eliminated feature parameters
which have hairbreadth dispersion. Such parameters are the
number of tonality changes, tone (only in chord CH, base
CH and drum CH) and average pitch. The reason why we
eliminated these parameters is that increasing the dimen-
sion of feature parameters is not wise for filtering music
data. Thus, the increase of the dimension of feature param-
eters requires a huge amount of data for generating filtering
rules. Table 2 shows feature parameters that we decided to
use in our filtering system.
5 Filtering Method and Prototype System
This section proposes our filtering method. Firstly, Sec-
tion 5.1 explains a classification algorithm used in our filter-
ing method. Section 5.2 designs a user profile and a content
model. Finally, in Section 5.3, we present the architecture
of our prototype system.
5.1 Classification Algorithm
Generally, there are two types in classification algo-
rithms. One type expresses feature parameters as factors
in a vector and classifies data based on the distance of their
vectors. The other type focuses on each feature parameter
Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
Table 2. Feature Parameters Used in Filtering
meter (the whole music), tonality (the whole music)
average tempo (the whole music)
rhythm (the whole music)
the percentage of major chord (the whole music)
the percentage of minor chord (the whole music)
the percentage of sus4 chord (the whole music)
key (the whole music), tone (melody CH)
average difference of pitch
(melody CH, chord CH, bass CH)
average duration
(melody CH, chord CH, bass CH, drum CH)
average difference of duration
(melody CH, chord CH, bass CH, drum CH)
and classifies data using a threshold to the feature parame-
ter. This is conducted repeatedly for fine-grained classifica-
tion. Our system uses a decision tree that is a typical method
of the latter type. This is because feature parameters of mu-
sic data are not necessarily independent each other and also
because the probability is high that users’ preferences for
music do not include only one type of music but cover sev-
eral different types (For example, a user may like both of
ballads and rock’n’roll). Our system adopts C4.5[8] that
can address continuous value as parameters.
5.2 User Profile and Content Model
The user profile in our system is a decision tree learned
for each user in advance. The user profile is made as fol-
 Figure 3. System Architecture of C-base MR
lows. The user rates music data presented by the system
on a scale of one to three, ”like”, ”neutral” and ”dislike”.
Rating on any discrete scale like 5-scale or 7-scale is possi-
ble, but a decision tree cannot deal with grades. Therefore,
we represent users’ preferences with no grade. The system
conducts learning from the user’s ratings and makes a deci-
sion tree. Nodes of the decision tree have conditions for the
feature parameters. Leaves of the decision tree have a class
that expresses ”like”, ”neutral” and ”dislike”.
The content model is made for each music data. The
content model consists of feature parameters extracted from
music data automatically by the system.
Filtering is carried out by comparing the user profile with
the content model of target music data. As the result of com-
parison, if the music data becomes the class representing
”like”, the system recommends it to the user. If the music
data becomes the class representing ”dislike” or ”neutral”,
the system does not recommend it. Furthermore, the user
rates music data recommended by the system. The system
updates the user profile based on the user’s ratings.
5.3 Prototype System
Our prototype system with the above filtering method,
which is called ”C-base MR”, is implemented in Java
servlet. Figure 3 shows our system architecture. The sys-
Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
tem consists of a user interface layer, a servlet layer and a
database layer.
The process flow of the system is as follows. Firstly,
the user inputs his/her name and selects a menu in the user
interface. Then, the request manager gets the user’s name
and the selected menu in the servlet. In the case that the user
selects ”questionnaire”, the questionnaire module makes a
questionnaire page in HTML. The questionnaire module
sends the HTML file to the user interface, and the user inter-
face displays the questionnaire page (Figure 4 (a)). When
the user answers the questionnaire, the user’s answer is sent
to the rating database. The rating database stores users’ rat-
ings of music data, which are used to build decision trees.
In the case that the user selects ”recommendation”, the
decision tree module builds a user profile using the user’s
ratings in the rating database and feature parameters of mu-
sic data rated by the user in the feature parameter database.
Then, the comparison module compares the feature parame-
ter of target music data with the user profile and selects mu-
sic data for recommendation. The recommendation module
makes a recommendation page in HTML. The recommen-
dation module sends the HTML file to the user interface,
and the user interface displays the recommendation page
(Figure 4 (b)). The user rates music data recommended by
the system, and this leads to the update of his/her user pro-
file. The extraction module extracts feature parameters from
 Figure 4. Sample Recommendation of C-base MR

Figure 5. User Profile

Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
 MIDI data in the MIDI database offline.
Figure 4 shows a sample recommendation of our system.
A user rates music data in the questionnaire page (Figure 4
(a)). This user tends to rate music data whose tempo is fast
as ”Like”. A decision tree which reflects the user’s ratings
is constructed (Figure 4 (c)). Figure 5 simplifies Figure 4
(c). The rule in the root node reflects the most remarkable
feature of the user’s rating that is ”the tempo is fast”. Our
system recommends music data whose tempo is fast to the
user by using the decision tree (Figure 4 (b)).

6 Summary and Future Works

This paper proposed a content-based filtering system for

music data. Firstly, we analyzed characteristics of feature
parameters about music data in MIDI format and selected
feature parameters for our filtering system. Then, we pro-
posed a filtering method using the feature parameters. A
user profile and a content model were designed and our pro-
totype system was implemented in Java servlet.
Future work will evaluate our prototype system. We
will conduct a user experiment and validate how effectively
content-based filtering works for music data.
References
[1] M. Aoyama, M. Yamaoka, and H. Takashima. Software ser-
vice technologies for making e-buiness real. IPSJ Magazine,
42(9):857–895, 2001.
[2] H.-C. Chen and A. L. P. Chen. A music recommendation
system based on music data grouping and user interests. In
Proceedings of the tenth international conference on Infor-
mation and knowledge management, 2001.
[3] M. Clausen, R. Engelbrecht, D. Meyer, and J. Schmitz.
Proms: A web-based tool for searching in polyphonic mu-
sic. In Proceedings of International Symposium on Music
Information Retrieval(Music IR 2000), 2000.
[4] T. Ikezoe, Y. Kajikawa, and Y. Nomura. Music database
retrieval system with sensitivity words using music sensivity
space. IPSJ Journal, 42(12):3201–3212, 2001.
[5] T. Kumamoto and K. Ohta. Automatically and numerically
expressing impressions of a music piece for music-retrieval
based on user’s impressions. IPSJ SIGNotes DataBase Sys-
tem, (127):89–96, 2002.
[6] T. Kurose, Y. Kajikawa, and Y. Nomura. Music recommen-
dation system using kansei information. In Proceedings of
the 14th Data Engineering Workshop, pages 8–P–06, 2003.
[7] S. Loeb and D. Terry. Information filtering. Comm. of the
ACM, 35(12):26–81, 1992.
[8] J. R. Quinlan and K. Furukawa. C4.5: Program for Machine
Learning. Toppan, 1995.
[9] P. Resnick and H. R. Varian. Recommender systems. Comm.
of the ACM, 40(3):56–89, 1997.
Figure 6. Rank of Melody CH
[10] A. Satou, J. Ogawa, Y. Horino, and H. Kitagami. A discus-
sion about the realization of impression-based retrieval sys-
tem for music collection. IPSJ SIGNotes MUSic and com-
puter, (39):51–56, 2001.
[11] A. Uitdenbogerd and R. van Schyndel. A review of factors
affecting music recommender success. In Proceedings of
International Symposium on Music Retrieval, 2002.
[12] Y. Yanagisawa and H. Matsumoto. Internet Value Chain
Marketing. SCC, 1998.
A Estimation of Melody CH
Firstly, we describe features of melody CH and explain
the result of a survey that sees whether the features can be
used for estimating melody CH. Then, we explain our tech-
nique to estimate melody CH which exploits the above fea-
tures.
A.1 Survey of Melody CH
From our experience, we noticed that the following three
features of melody CH are different from those of the other
CHs.
(a) the number of notes performed at the same time is small
(Melody CH is monophonic.).
(b) the difference of pitch is small (Melody CH and CHs
playing a decorative role remain if drum CH, bass CH
and chord CH are estimated and removed from all
CHs. CHs playing a decorative role tend to enlarge
the difference of pitch to perform decorative effects.).
(c) CH number is small.
In order to know whether these features can be used for
estimating melody CH, we surveyed 50 real MIDI data and

Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
 Figure 7. Flow of Estimation for Melody CH
sorted all CHs except drum CH, base CH and chord CH in
descending order of the value for each feature. Then, we
examine the rank of melody CH for each feature. Figure 6
depicts the result.
Melody CH ranks first or second in the number of notes
performed at the same time and ranks within third in the
average difference of pitch for most of the music data. Fur-
thermore, the CH number of the melody CH is relatively
small. Therefore, we target the CH that ranks within sec-
ond in the number of notes performed at the same time and
ranks within third in the average difference of pitch for esti-
mating melody CH. Then we estimate melody CH by using
the CH’s rank to the above two features and CH number.
A.2 Estimation Method of Melody CH
Figure 7 depicts the flow of estimation of melody CH.
Firstly, CHs whose performance time are short are elimi-
nated. This is because those CHs play a decorative role in
music. Secondly, drum CH, base CH, and chord CH are es-
timated and eliminated from the rest of the CHs. Then, CHs,
which rank first or second (A=1st, B=2nd) in the number of
notes performed at the same time, are extracted. In the same
Proceedings of the 2004 International Symposium on Applications and the Internet Workshops (SAINTW’04)
0-7695-2050-2/04 $20.00 © 2004 IEEE
way, CHs, which rank within third (a=1st, b=2nd, c=3rd) in
the average difference of pitch, are extracted. After that, the
number of the common CH between (A, B) and (a, b, c)
is counted. In the case that the common CH is only one,
the CH is selected as melody CH. In the case that the com-
mon CHs are two, the flow of estimation is as follows. If A
equals a (i.e. the CH ranks first in the both parameters), the
CH is selected as melody CH. Because the CH ranking first
in the both parameters is most likely to be melody CH. If B
equals c (i.e. the CH ranks second in the number of notes
performed at the same time and ranks third in the average
difference of pitch), the CH is eliminated and another com-
mon CH is selected as melody CH. Because the CH ranking
second in the number of notes performed at the same time
and third in the average difference of pitch is least likely
to be melody CH. Otherwise, the CH whose CH number is
smaller than the other is selected as melody CH. In the case
that there are no common CHs between the two parameters,
the system gives up the estimation.