Creating Personalized Playlists: Music Recommendations with Algorithms and User Feedback, Study Guides, Projects, Research of World Music

Download Creating Personalized Playlists: Music Recommendations with Algorithms and User Feedback and more Study Guides, Projects, Research World Music in PDF only on Docsity! 
 
 
 An
Intelligent
Online
Music
Player
 Semester Project, March 2009 – April 2009 Student: Mihai Calin ETH – ITET Master Studies Advisors: Olga Goussevskaia / Michael Kuhn Supervisor: Prof. Dr. Roger Wattenhofer Task Formulation Media usage is changing rapidly these days. This process has been ignited by several technological advances, in particular, the availability of broadband internet, the World Wide Web, affordable mass storage, and high-quality media formats, such as mp3. Many music lovers have now accumulated collections of music that have reached sizes that make it hard to maintain an overview of the data by just browsing hierarchies of folders and searching by song title or album. Search methods based on song similarity offer an alternative, allowing users to abstract from manually assigned metadata, such as, frequently imprecise or incorrect, genre information. In a context where music collections grow and change rapidly, the similarity-based organization has also the advantage of providing easy navigation and retrieval of new items, even without knowing songs by name. This opens possibilities, such as sophisticated recommendations, context-aware retrieval, and discovery of new genres and tendencies. In previous projects we have created a Euclidean map of the world of music, which contains more than 400K songs. This map places similar songs close to each other, whereas the distance between unrelated songs becomes large. Such a map exhibits several advantages in terms of applications. It allows to quickly find songs similar to each other, to define regions of interest, or to create smooth playlists by following paths, such as straight lines between start- and end-songs, for example. Based on this map, we have developed the music-explorer website (www.musicexplorer.org) that provides a similarity based view on music collections. The current website, however, provides only limited benefits to the user. In particular, it is not able to directly play music. The goal of this thesis is to improve in this point by connecting the music-explorer website to existing web-content. In a first step, Mihai will study different APIs, such as the last.fm, youtube, google, or facebook API, and investigate how the music-explorer project could benefit from each of these data sources. Dependent on the outcome of the API evaluation, Mihai will then design one or several new use-cases for the music-explorer website that involve some of the evaluated data sources. In a last step, Mihai will then implement at least one of the proposed use cases and make it available to the user on www.musicexplorer.org. Table
of
Contents
 1
 Introduction ................................................................................................................. 3
 2
 Problem
Statement .................................................................................................... 4
 2.1
 Motivation.......................................................................................................................... 4
 2.2
 Approach............................................................................................................................ 5
 3
 Related
Work ............................................................................................................... 6
 3.1
 ETH
Projects...................................................................................................................... 6
 3.2
 External
Projects ............................................................................................................. 7
 4
 Vision.............................................................................................................................. 8
 4.1
 Requirement
Specifications ........................................................................................ 8
 4.2
 User
Perspective.............................................................................................................. 9
 4.3
 Implementation
as
Facebook
App...........................................................................10
 5
 Audio
and
Video
Content
Provider.....................................................................11
 5.1
 Content
Provider
Analysis .........................................................................................11
 5.2
 YouTube
API ...................................................................................................................12
 5.2.1
 Technical
Possibilities .........................................................................................................12
 5.2.2
 Coverage
Analysis..................................................................................................................12
 5.3
 Query
Design...................................................................................................................15
 5.4
 Post­processing
YouTube
Results ...........................................................................16
 6
 Architecture ...............................................................................................................18
 6.1
 Client
and
Server
side
Functions .............................................................................18
 6.1.1
 The
Client
Side ........................................................................................................................18
 6.1.2
 The
Server
Side.......................................................................................................................19
 6.1.3
 The
Communication .............................................................................................................20
 6.2
 Music
Space
(KDTree) .................................................................................................20
 6.3
 Playlist
Generation
Algorithm..................................................................................21
 6.3.1
 Existing
Solutions ..................................................................................................................21
 6.3.2
 First
Approach ........................................................................................................................21
 6.3.3
 Improvement...........................................................................................................................23
 6.4
 User
Feedback ................................................................................................................24
 6.4.1
 Direct
and
Indirect
User
Feedback.................................................................................24
 6.4.2
 Activity
and
Feedback
Log
Structure ............................................................................25
 7
 Conclusions.................................................................................................................26
 8
 Discussion
and
Future
Work ................................................................................27
 8.1
 Achievements .................................................................................................................28
 8.2
 Future
Work....................................................................................................................28
 8.2.1
 Nice
to
Have .............................................................................................................................28
 8.2.2
 Feedback
Analysis
and
Integration................................................................................28
 8.2.3
 User
Awareness......................................................................................................................29
 9
 Bibliography...............................................................................................................29
 
 3
 1 Introduction
 Music
 has
 always
 been
 a
means
 of
 entertaining
 people
 even
 from
 the
 earliest
 ages
 of
 the
 civilization.
 Historically
 it
 was
 produced
 by
 musicians
 and
 only
 available
 during
 life
 concerts.
 The
 technological
 evolution
made
 it
 possible
 to
 save
 the
music
on
vinyl
plates,
 later
electromagnetic
 charged
stripes,
CDs
until
 the
 technology
brought
us
 to
saving
 tracks
digitally.
When
dealing
with
a
huge
 collection
of
tracks,
people
encounter
management
problems
they
did
not
have
 before.
So
they
have
to
develop
new
ways
of
using
the
music
collection
for
their
 entertainment.
Playlists
are
a
good
approach
for
saving
successions
of
tracks
that
 one
 likes.
 The
 most
 dominant
 problem
 of
 existing
 playlist
 generation
 mechanisms
 is,
 however,
 their
 lack
 of
 flexibility:
 new
 tracks
 are
 not
 automatically
added,
they
don’t
adapt
to
the
user’s
current
mood
etc.

 A
 new
 approach
 in
 dynamically
 organizing
 tracks
 into
 playlists
 is
 on
 its
 way:
 companies
 like
 last.fm
 already
 suggest
 an
 algorithm
 of
 mapping
 songs
 one
 to
 each
other
based
on
their
“similarities”;
but
how
to
compute
these
similarities?
 One
way,
that
did
not
prove
to
be
very
productive,
is
to
analyze
the
audio
content
 of
 the
 track
–
 its
audio
 frequencies.
This
way,
 tracks
are
split
 in
categories
 like
 “Heavy
Metal”
and
“Blues”,
but
people
do
not
 like
all
 tracks
of
a
certain
gender
 and
 these
genders
might
be
 inaccurate.
Another
way,
which
 is
 given
more
and
 more
 attention
 by
 researchers
 and
 companies
 worldwide,
 is
 computing
 similarities
between
tracks
based
on
user
input.
As
an
example:
if
two
users
add
 the
 same
 two
 tracks
 to
 their
 playlists,
 one
 can
 deduce
 that
 these
 tracks
 are
 similar
 and
 so,
 also
 other
 people
 that
 pick
 one
 of
 them
 are
 likely
 to
 enjoy
 the
 other
one
as
well.

 Lorenzi
(Lorenzi,
2007)
proposes
a
way
of
representing
the
similarity
between
 tracks
 in
a
10‐dimensional
Euclidian
space
 (further
called
music
space),
where
 the
 closeness
 of
 tracks
 is
 approximately
 proportional
 to
 their
 similarity.
 7M
 songs
currently
appear
in
the
database,
but
only
500K
of
them
have
enough
user
 statistics
 to
be
mapped
 in
 the
graph.
Using
 this
 simplified
and
computationally
 efficient
way
of
finding
similar
tracks,
several
applications
can
explore
new
ways
 of
computing
playlists.
Most
of
them
offer
support
in
playlist
generation
but
none
 also
 provides
 the
 tracks
 to
 be
 played.
 This
 could
 be
 seen
 as
 a
 disadvantage
 because
not
all
people
possess
all
tracks
that
are
suggested
by
the
space.

 This
report
sets
its
goal
in
developing
an
application
that
uses
the
space
of
music
 for
 computing
 intelligent
 playlists
 and,
 more
 important,
 trying
 to
 deliver
 the
 required
 songs
 to
 the
 user
 through
 publicly
 available
 tracks
 on
 YouTube.com.
 For
promotion
purposes
and
also
user
data
gathering,
it
was
chosen
to
make
the
 application
available
on
Facebook1,
which
ensures
an
easy
referral
to
friends.

 The
development
process
is
not
an
easy
one
as
many
technologies
are
required
 to
work
together
to
provide
the
user
with
a
good
experience.
The
huge
amount
of
 data
that
has
to
be
processed
is
demanding
with
respect
to
both
algorithms
and
 























































 1
www.facebook.com
‐
community
networking
site
 
 4
 underlying
 hardware.
 In
 the
 end
 of
 this
 report,
 a
 fully
 functional,
 but
 feature‐ limited,
version
of
an
online
music
player
is
presented.
This
application
could
be
 the
 step
 stone
 of
 future,
 more
 detail‐oriented
 applications
 because
 it
 sets
 the
 basis
of
a
new
playground:
an
online
music
player.

 2 Problem
Statement
 This
 chapter
 debates
 the
 necessity
 of
 a
 new
 solution
 to
 make
 the
 world
 of
 intelligent
track
comparison
even
more
accessible
to
the
end
user,
 followed
by
an
 approach
sketch.

 2.1 Motivation
 Several
 solutions
 already
 use
 intelligent
 playlists
 embedded
 in
 music
 players
 installed
 on
 computers.
 There
 are
 also
 online
 solutions,
 the
 most
 popular
 of
 which
is
 last.fm,
which
acts
as
a
personalized
radio
station
that
plays
preferred
 music.
On
the
other
hand
it
does
not
allow
playback
of
a
certain
track.
There
are
 also
 other
 solutions,
 like
 the
 genius
 function
 of
 iTunes
 or
 the
Music
 Explorer;
 both
 use
 the
 user’s
 music
 collection
 to
 generate
 playlists.
 The
 biggest
 disadvantage
 of
 the
 latter
 solution
 is
 that
 the
 user
 can
 use
 only
 tracks
 that
 he/she
already
has
on
his/her
PC
to
generate
playlists.
Of
course
this
limits
the
 power
or
the
algorithm
very
much.

 There
 are
 already
 services
 that
 provide
 the
 music
 content
 (like
 last.fm
 or
 YouTube
to
name
a
few)
so
it’s
a
natural
conclusion
to
try
to
use
these
services
in
 connection
with
the
playlist‐generating
algorithm.

 In
 order
 to
 understand
 the
 utility
 of
 such
 an
 application,
 just
 imagine
 the
 following
 scenario:
 one
 enjoys
 listening
 to
 music
 while
 working.
 It
 is
 not
 common
to
store
music
on
the
company’s
computer
so
one
rather
has
a
personal
 mp3
player
with
himself
during
office
time.
If
one
takes
enough
time
to
prepare
 ones
playlists
in
order
to
fit
ones
current
mood,
it
is
a
pretty
decent
solution.
But
 what
 if
 new
 tracks
 appear
 that
 one
 might
 like?
 One
 first
 has
 to
 do
 serious
 research
 in
order
 to
 find
 them
and
then
go
 through
buying
 them,
downloading
 them
 to
 his/her
 mp3
 player,
 updating
 the
 playlists…
 it
 already
 sounds
 very
 difficult,
 right?
 Now
 the
 suggested
 scenario
 is
 the
 following:
 one
 opens
 a
web
 site,
types
in
a
track
that
reflects
ones
current
mood
and
hits
“play”.
That’s
it!
The
 player
chooses
tracks
that
one
likes,
also
plays
new
tracks
that
one
did
not
hear
 before,
and
can
go
like
this
for
hours
and
hours
without
repetition.
One
can
go
on
 with
one’s
work
and
in
order
to
stop
the
music,
one
only
has
to
hit
stop
or
close
 the
browser.
The
simplicity
of
the
solution
speaks
for
itself.

 The
goal
of
this
thesis
is
to
analyze
and
implement
an
approach
of
building
such
 a
 web‐based
music
 player.
 The
 questions
 it
 has
 to
 find
 answers
 for
 are:
 How
 should
 the
 user
 interaction
 be
 designed
 to
 maximize
 the
 user
 satisfaction?
 Where
 to
 source
 the
 audio
 (and
 video)
 data
 from,
while
 ensuring
 a
maximum
 coverage?
And
finally,
how
to
promote
the
application
in
order
to
attract
as
many
 users
as
possible?

 The
different
implementation
possibilities
are
evaluated
and
the
best
solution
is
 implemented.
 The
 logic
 behind
 the
 web‐based
 music
 player
 computes
 a
 
 7
 applications,
 such
 as:
 comparing
 similarities
 between
 several
 track
 pairs,
 computing
the
nearest
neighbor,
finding
tracks
along
a
certain
path
or
“negating”
 a
track
–
meaning
finding
another
track
that
is
far
away
from
this
track.
A
further
 discussion
of
 the
correctness
of
 this
mapping
 is
out
of
 the
scope
of
 this
report;
 therefore
this
report
considers
the
provided
music
space
as
efficient
and
uses
it
 as
it
is.

 Based
 on
 the
 previously
 described
 music
 space,
 several
 applications
 were
 developed
 to
 bring
 the
 advantages
 of
 the
 music
 space
 to
 the
 end
 user.
 The
 musicexplorer
web
application
(Gonukula,
Kuederli,
&
Pasquier,
2008)
presents
 an
approach
of
organizing
the
user’s
music
collection
based
on
an
online
service.
 The
user
has
the
possibility
to
upload
the
titles
of
its
music
collection,
select
two
 of
 them
and
the
algorithm
computes
a
playlist
 that
 is
a
smooth
crossover
 from
 one
track
to
the
other.
Both,
the
musicexplorer
and
the
application
presented
in
 this
report,
allow
the
user
to
generate
intelligent
playlists.
The
downside
of
the
 musicexplorer
 is
 the
requirement
 that
 the
user
already
possesses
 the
 tracks
 to
 be
played.
If
his/her
collection
is
limited,
so
is
the
playlists
at
the
output.
Using
 publicly
available
tracks
not
only
make
it
easier
for
the
user
but
also
the
results
 are
be
better.

 Bossard
 presents
 a
 new
 way
 of
 exploring
 the
 Space
 of
 Music
 with
 a
 visual
 approach
 that
 should
 allow
 the
 user
 to
 visually
 select
 tracks
 from
 the
 music
 space
 (Bossard
L.
 ,
 2008).
The
 ideas
are
 implemented
on
 the
android
platform
 through
a
customizable
music
player.

 3.2 External
Projects
 Several
companies
have
recently
discovered
the
advantages
of
user‐personalized
 playlists
 and
 are
 currently
 building
 their
 business
 model
 based
 on
 providing
 high
quality
but
simple
to
use
solutions
to
their
customers.
Last.fm
is
one
of
the
 first
 ones
 on
 the
market
 to
 offer
 personalized
music
 playback;
 it
 achieves
 this
 through
 an
 online
 “radio
 station”
 that
 is
 supposed
 to
 play
music
 that
 the
 user
 likes.
The
Last.fm
approach
is
very
similar
to
the
one
proposed
by
this
report:
it
 is
 an
 online
music
 player
 that
 usually
 plays
 the
 user’s
 favorite
 tracks
 and
 also
 introduce
 new
 tracks
 if
 available.
However,
 because
 the
 personalization
 of
 the
 player
 is
done
on
a
per‐user
basis
(opposed
to
 the
per‐session
proposal
of
 this
 report)
 it
 could
 happen
 that
 it
 does
 not
 react
 so
 fast
 to
mood
 changes
 in
 the
 user’s
behavior.
The
biggest
drawback
 is
 still
 the
 inability
of
 the
user
 to
 select
 certain
tracks
to
play;
even
if
he/she
has
a
certain
favorite
track
in
mind,
he/she
 has
to
stick
to
the
automatically
generated
playlist
of
the
player.
This
limitation
 is
 probably
 more
 license‐based
 than
 technological,
 but
 it
 is
 a
 field
 where
 improvement
is
desired.

 Another
approach
to
delivering
similar
tracks
to
a
user
is
the
Genius
function
of
 the
Apple
iTunes
music
player.
The
principle
is
fairly
easy:
iTunes
analyzes
your
 music
 library,
submits
the
tracks
to
an
 iTunes
server,
which
returns
popularity
 measurements
 personalized
 for
 your
 tracks.
During
 playback,
 the
 user
 has
 the
 possibility
to
select
a
track
and
let
the
application
generate
a
playlist
containing
 tracks
similar
to
the
selected
one.
The
biggest
drawback
of
this
approach
is
the
 limitation
to
the
user’s
personal
computer,
where
he/she
holds
his/her
private
 music
collection.

 
 8
 During
 the
 development
 process,
 two
 new
 companies
 launched
 an
 implementation
 that
 is
 very
 similar
 to
 the
presented
 approach.
One
of
 them
 is
 Songza
(www.songza.com),
an
online
music
player
where
users
can
search
for
a
 track
and
play
it.
The
audio
(and
sometimes
also
video)
content
is
sourced
from
 YouTube
 or
 Last.fm.
 The
 user
 has
 the
 possibility
 to
manually
 create
 a
 playlist.
 However
 no
 mechanism
 of
 automatically
 generating
 playlists
 is
 yet
 available.
 The
second,
and
much
more
similar
to
this
report’s
implementation,
is
DropPlay
 (www.dropplay.com).
 It
 allows
 the
 user
 to
 search
 for
 songs,
 generate
 playlists
 based
on
 similarity
 and
also
 share
 these
 songs
with
 friends
on
Facebook.
Only
 time
will
show
which
of
the
two
implementations
will
be
better
for
the
users.

 The
 discussion
 of
 external
 projects
 is
 continued
 in
 the
 Vision
 chapter,
where
 the
 pros
and
cons
of
the
mentioned
applications
are
further
analyzed
and
weighted.

 4 Vision
 This
chapter
sets
the
ground
rules
for
developing
the
application,
mostly
based
on
 experience
 gathered
 from
 already
 existing
 implementations.
 Important
 decisions
 about
 audio
 content
 sourcing
 and
 application
 promotion
 are
 discussed
 and
 reasoned
in
this
and
also
the
next
chapter.

 4.1 Requirement
Specifications
 As
 presented
 in
 the
 related
 work
 section,
 there
 already
 are
 several
 implementations
 that
 are
 more
 or
 less
 similar
 to
 this
 report’s
 solution.
 All
 of
 them
have
their
strengths
and
weaknesses
so
they
are
going
to
be
analyzed
and
 combined
 to
work
 in
 the
 targeted
 scenario.
 The
 goal
 is
 to
 create
 a
web
 based
 application
that
is
simple
to
use
and
that
can
function
independent
of
the
users
 resources.
What
can
be
learned
from
other
approaches
and
what
can
be
used
to
 increase
the
value
of
this
implementation?

 Compared
 to
 the
 current
 musicexplorer
 web
 application,
 the
 designed
 application
 is
 also
 a
web‐based
 service
 and
 targets
 the
 same
 audience:
 people
 who
want
 to
 have
 their
music
 experience
 enhanced
without
 a
 lot
 of
 effort
 on
 their
 side.
 The
 users
 interact
 with
 the
 existing
 musicexplorer
 application
 by
 submitting
 all
 the
 titles
 of
 their
music
 library
 and
 then
 selecting
 two
 of
 those
 tracks
 that
 are
 used
 as
 endpoints
 of
 a
 playlist.
 All
 the
 tracks
 in
 between
 represent
a
smooth
progress
 from
one
 track
 to
 the
other.
This
 implementation
 faces
 the
problem
 that
 it
 completely
depends
on
 the
user
 to
provide
 the
audio
 content.
 The
 quality
 of
 the
 offered
 result
 is
 only
 as
 good
 as
 the
 number
 and
 variety
of
submitted
tracks;
even
the
best
implementation
performs
poorly
if
it
is
 fed
with
low
quality
resources.
Also
the
mapping
of
tracks
from
the
user’s
tags2
 to
the
applications
tags
is
a
problem
to
take
into
account.
The
lack
of
own
music
 content
is
also
a
problem
for
people
that
do
not
own
a
big
music
collection
or
do
 not
 have
 it
 at
 hand.
 Hence,
 the
 current
 application
 sets
 a
 high
 priority
 to
 























































 2
Track
meta‐data,
namely
artist
and
title
 
 9
 providing
the
intelligent
playlists
together
with
the
audio
content.
This
ensures
 both
a
greater
QoS3
and
ease
of
use.

 Generating
an
intelligent
playlist
and
then
playing
the
tracks
is
similar
to
Last.fm.
 In
the
case
of
Last.fm
however,
license
limitations
prevent
the
user
to
search
for
 specific
 tracks
 and
 play
 them.
 As
 long
 as
 the
 designed
 application
 has
 no
 restriction
 in
 this
 matter,
 it
 is
 a
 high
 priority
 to
 implement
 such
 a
 popular
 feature.
A
 search
bar
 allows
 the
user
 to
 browse
 through
 the
 library
 and
 select
 individual
 tracks
 to
 play.
 Last.fm
 also
 avoids
 displaying
 an
 actual
 playlist,
 although
most
users
like
to
at
least
see
the
tracks
that
follow,
and
possibly
even
 edit
this
list.
To
honor
the
playlist
generating
feature
of
the
application,
a
playlist
 is
 displayed
 to
 the
 user
 together
 with
 the
 possibility
 to
 add,
 remove
 and
 rearrange
 tracks
 from
 the
 list.
 This
 makes
 the
 application
 very
 similar
 to
 the
 music
players
the
user
is
already
used
to.

 As
discussed
in
the
last
paragraph,
the
UI4
imitates
a
common
music
player
such
 that
the
users
do
not
have
to
get
used
to
something
completely
new.
This
brings
 the
question
wheater
to
implement
the
application
as
an
installable
–
standalone
 application
or
as
a
web
service
running
in
a
browser.
Modern
technologies
 like
 JavaScript
and
AJAX
allow
a
simple
development
of
a
solution
running
in
the
web
 browser.
Also
encouraging
for
using
this
approach
is
the
fact
that
the
application
 most
 likely
 provides
 online‐based
 streamed
 audio
 content.
 Online
 applications
 provide
decent
 results
 if
 they
don’t
have
 resource‐consuming
 client
 side
 tasks;
 also
they
are
easy
to
update
and
maintain.
In
respect
to
all
the
mentioned
pros,
it
 makes
 sense
 to
 develop
 the
 application
 as
 a
 JavaScript
 based
 implementation
 that
runs
directly
 in
 the
web
browser,
without
 the
need
 to
download
or
 install
 anything.
 4.2 User
Perspective
 As
 one
 of
 the
 important
 goals
 is
 to
 have
 a
 user‐friendly
 application,
 it
 is
 necessary
 to
 provide
 good
 results
 with
 a
 minimum
 of
 information
 requested
 from
the
user.
As
a
second,
but
also
very
important
feature,
the
user
actions
have
 to
 be
 logged
 for
 understanding
 and
 improving
 the
 application’s
 behavior.
 The
 logging
should
be
made
optional,
to
avoid
privacy
issues.

 Understanding
 the
 resources
 that
 are
 at
 disposal
 is
 necessary
 to
 find
 the
 minimum
information
required
to
return
satisfactory
results.
In
order
to
provide
 tracks
that
the
user
likes
to
listen
to,
the
application
has
to
know
which
are
the
 preferences
of
the
user.
Last.fm
does
that
by
tracking
the
user’s
preferred
tracks
 over
 several
 sessions
 and
 probably
 computes
 a
 user
 profile
 based
 on
 this
 behavior.
This
approach
 is
an
elaborate
one
but
 introduces
a
huge
overhead
 in
 the
user‐management
algorithms.
And
if
the
user
decides
at
some
point
to
listen
 to
something
else,
the
inertia
of
the
algorithm
makes
this
very
difficult.
The
best
 approach
that
also
ensures
a
minimum
user
interaction
is
no
user
tracking
at
all.
 The
application
should
work
well
for
each
user,
independent
on
his/her
history
 with
the
application.

 























































 3
Quality
of
Service
 4
User
interface
 
 12
 guaranteed
quality
and
 the
application
only
 switches
 to
YouTube
 if
 there
 is
no
 unclipped
 track
 on
 Last.fm.
 Implementing
 both
 alternatives
 however,
 brings
 problems
especially
in
the
UI
part
of
the
application.
Also
indirect
user
feedback
 is
much
harder
to
trace.
This
is
why
the
application
is
relying
on
YouTube
as
it’s
 content
provider.

 5.2 YouTube
API
 5.2.1 Technical
Possibilities
 As
 discussed
 in
 the
 previous
 section,
 YouTube
 is
 the
 chosen
 music
 content
 provider.
It
should
be
noted
at
this
point
that
no
music
content
is
being
held
or
 even
transferred
through
the
server
hosting
the
service.
Only
the
YouTube
movie
 id
is
passed
to
the
client
application
that
embeds
the
video
using
YouTube’s
own
 player.

 The
 YouTube
 API
 offers
 the
 possibility
 to
 do
most
 of
 the
 actions
 performable
 manually
through
the
web
site
in
a
programmatic
manner.
These
actions
include
 receiving
a
list
of
results
to
a
search
query
and
for
each
of
these
tracks:
its
id,
the
 link
 to
 its
 implementation,
 link
 to
 its
 thumbnail
 etc.
 Moreover,
 the
 API
 offers
 methods
to
set
the
query
parameters,
like:
the
country
restriction,
the
language,
 the
uploader
and
also
the
order
of
the
results.

 The
 API
 also
 offers
 possibilities
 of
 logging
 in
 with
 a
 user
 account,
 uploading
 videos
from
that
account,
generating
playlists
and
many
others
features,
but
they
 are
(currently)
of
no
use
to
this
application.

 5.2.2 Coverage
Analysis
 YouTube
was
chosen
over
Last.fm
to
be
 the
sole
music
content
provider
of
 the
 project
both
because
of
 its
 simple
 to
use
API
but
also
 for
 covering
most
of
 the
 popular
tracks.
Coverage
is
one
of
the
strong
points
of
Last.fm,
but
the
fact
that
 for
 most
 tracks
 only
 a
 30
 seconds
 sample
 is
 provided,
 biased
 the
 decision
 in
 YouTube’s
favor.

 To
analyze
to
what
extend
the
library
is
covered
by
tracks
from
YouTube
a
test
 was
 run
 on
 samples
 taken
 from
 the
DB.
 In
 order
 to
 have
 an
 accurate
 result,
 a
 certain
number
of
random
samples
were
chosen
from
the
DB
in
order
to
make
an
 assumption
about
the
coverage.
The
results
show
that
 from
137
samples,
more
 than
half
had
no
corresponding
track
in
YouTube
(Figure
5‐1).

 
 
 13
 
 Figure
5­1
­
YouTube
Track
Coverage
 
 The
 coverage
 test
 was
 run
 over
 7M+
 tracks
 available
 in
 the
 DB,
 randomly
 choosing
 137
 tracks.
 But
 around
 60%
 of
 the
 tracks
 have
 a
 popularity
 of
 1,
 meaning
 that
 only
 one
 user
 ever
 listen
 to
 them.
 As
 a
 comparison,
 the
 average
 popularity
of
the
rest
of
40%
of
the
tracks
is
24
with
a
maximum
of
around
62K.
 The
statistic
doesn’t
necessary
reflect
the
real
coverage
of
the
DB,
because
most
 users
 only
 listen
 to
 the
 most
 popular
 tracks
 –
 also
 enforced
 by
 the
 playlist
 generation
algorithm
that
select
mostly
rather
popular
tracks.
Hence,
in
order
to
 reflect
the
effective
coverage,
a
new
statistic
approach
is
chosen,
detailed
next.

 
 found;
47%
 not
found;
53%
 
 14
 
 Figure
5­2
­
DB
Tracks
Popularity
Distribution
 
 Figure
5‐2
 illustrates
the
popularity
distribution
 in
the
database.
From
the
plot
 one
can
for
example
see
that
more
than
100K
tracks
have
popularity
above
10.
In
 order
 to
 create
 a
 weighted
 analysis
 of
 the
 coverage,
 tracks
 for
 analysis
 were
 chosen
in
the
following
manner:
the
list
of
tracks
was
sorted
by
popularity
and
 the
 first
 10
 tracks
 were
 added
 to
 the
 statistic.
 Next,
 10
 tracks
 were
 chosen
 randomly
from
the
next
power
of
10
tracks
(for
the
second
step
100)
and
so
on
 until
the
limit
of
7M
tracks
was
reached
and
the
sample
contained
191
tracks.

 
 
 Found;
81%
 Not
Found;
19%
 
 17
 Table
5­1
­
Post­Processing
Rating
Rules
 Rule
 Score
 Is
first
track
in
result
set
 +3
 Is
second
track
in
result
set
 +1
 Music
video
 +4
 Official/original
 +4
 Video
 +2
 Lyrics
 +3
 HQ/HD
 +2
 High
Quality
 +2
 Mtv/bbc
 +1
 Live
 ‐2
 Tour

 ‐2
 Instrumental
 ‐4
 Either
 title
 or
 description
 contains
 the
word:
 Cover
 ‐4
 
 In
 order
 to
 see
 the
 rules
 in
 action,
 the
 tracks
 from
 the
 statistic
were
 analyzed
 again,
showing
the
results
in
Figure
5‐6.
The
percentage
of
not
delivered
tracks
 has
 lowered
 by
 12%
 (from
 39%
 to
 27%)
 leaving
 only
 8%
 of
 the
 results
 non‐ optimized.
This
analysis
shows
that
 the
post‐processing
can
have
an
 important
 impact
on
the
result
and
should
be
implemented
in
future.

 
 
 Figure
5­6
­
YouTube's
Track
Coverage
After
Post­Processing
 
 Having
decided
upon
YouTube
as
content
provider,
the
rest
of
the
implementation
 details
are
discussed
in
the
next
chapter.

 Best
Result;
73%
 A
better
 implementation
in
 the
tirst
three
 results;
27%
 
 18
 6 Architecture
 After
discussing
the
application’s
approach
to
serving
its
goal,
it’s
time
to
describe
 the
 technical
details
of
 the
 implementation.
What
 functions
 should
 the
client
and
 server
side
implement?
How
modularized
can
and
should
the
application
be
built?
 What
 is
 the
 best
 approach
 in
 dealing
 with
 the
 huge
 data
 amount?
 What
 advantages
do
the
different
APIs
bring
and
how
can
they
be
used?
 6.1 Client
and
Server
side
Functions
 The
 goal
 of
 the
 application
 is
 set
 and
 also
 the
 ground
 rules
 –
 also
 for
 implementation
 –
 have
 also
 been
 set
 in
 the
 Vision
 Chapter.
 The
 application
 is
 designed
as
a
two‐sided
application:
client
and
server
side.

 6.1.1 The
Client
Side
 The
client
side
must
implement
the
UI
of
the
application.
It
must
be
a
stand‐alone
 program
 that
 only
 requests
 and
 delivers
 parameterized
 data
 from
 and
 to
 the
 server.
 It
 is
 important
 to
have
a
 strict
 and
 simple
 communication
between
 the
 two
applications
(client
and
server)
such
that
an
extension
or
even
replacement
 of
 each
 one
 of
 them
 is
 easy
 to
 understand
 by
 the
 developer.
 The
 client
 application
is
responsible
for
delivering
an
intuitive
UI
and
handling
all
requests
 of
the
user
that
are
related
to
the
UI.
Basically
the
client
implements
the
whole
 music
player
UI,
with
play,
pause,
repeat
functions
as
well
as
playlist
generation
 and
modification.
The
list
of
tracks
actually
present
in
a
playlist
is
generated
by
 the
 server
 and
 returned
 to
 the
 client
with
 enough
 parameters
 (video
 id)
 such
 that
 the
 client
 itself
 can
download
 the
music
 content
 from
YouTube.
No
music
 content
is
available
from
or
routed
through
the
application’s
service.

 The
seed
to
be
used
for
generating
a
new
playlist
is
not
selected
in
a
traditional
 ‘search
 and
 select
 candidate’
 manner.
 A
 type
 sensitive
 field
 responds
 to
 each
 keystroke
with
a
suggestion
list
for
tracks
that
contain
the
words
either
as
artist
 or
title.
The
user
has
to
select
a
 track
 from
this
 list
and
use
 it
as
a
seed
for
the
 playlist
 he/she
 wants
 to
 generate.
 The
 client
 does
 not
 fetch
 results
 from
 the
 server
for
each
letter
the
user
types.
A
delay
is
set
such
that
a
suggestion
request
 is
sent
to
the
user
only
if
the
user
has
stopped
writing
for
more
than
‘delay’
time
 ago.

 The
playlist
is
fully
customizable
and
offers
the
user
the
possibility
to
rearrange
 the
 tracks
 in
 order
 to
 influence
 the
 playing
 order,
 to
 remove
 and
 to
 jump
 to
 tracks.
No
restrictions
are
made
on
the
rearranging
of
the
playlist;
for
example
if
 a
user
whishes
to
replay
a
track
that
he/she
already
heard,
he/she
is
able
to
do
 that.
Also
the
playlist
is
responsible
of
always
having
a
minimal
number
of
tracks
 loaded
 after
 the
 currently
 playing
 one.
 If
 this
 number
 decreases
 because
 of
 playing
 track
 advancement,
 track
 removal
 or
 reordering,
 the
 playlist
 automatically
loads
new
tracks
until
the
minimum
size
is
reached
again.

 The
UI
has
an
area
used
to
display
track
specific
information
like
title,
artist
and
 other.
 The
 user
 uses
 this
 area
 also
 to
 directly
 give
 feedback
 about
 the
 current
 track
 (low
quality
or
bad
 track
 choice).
A
direct
 link
 to
 the
 implementation
on
 YouTube
is
also
available.

 
 19
 6.1.2 The
Server
Side
 The
 server
must
 provide
 the
 following
 two
 services
 for
 the
 client
 application:
 playlist
generation
and
suggestion
generation.
The
core
of
the
server
is
the
only
 non‐interchangeable
part
and
it
acts
as
a
bridge
between
the
modules
to
provide
 the
 services
 requested
 by
 the
 client.
 The
 server
 side
 application
 consists
 of
 modules
 that
 handle:
 the
 database,
 the
 YouTube
 related
 data,
 the
music
 space
 data
 and
 the
 client
 connection
 socket.
 The
 client
 connection
 socket
 is
 distinct
 from
the
core
module,
such
that
it
can
also
be
interchangeable
if
a
different
type
 of
client
is
used
to
connect
to
the
same
server.
In
this
case
however,
the
core
has
 to
 be
modified
 as
well
 to
 provide
 the
 new
 functionalities.
 Also
 the
 socket
 has
 responsibilities
 like
maintaining
 the
 session
 and
 converting
 the
 data
 from
 the
 structures
(Objects)
used
in
the
server
to
the
ones
used
in
the
communication
to
 the
client.
Figure
6‐1
‐
Modular
Structure
of
the
Server
Side
Application
offers
an
 overview
of
the
modular
structure.

 
 Figure
6­1
­
Modular
Structure
of
the
Server
Side
Application
 The
suggestion
service7,
uses
an
algorithm
that
executes
an
indexed
crawl
in
the
 database
 for
 the
 words
 currently
 entered
 by
 the
 user.
 Words
 shorter
 than
 3
 letters
 are
 not
 included
 to
 avoid
 a
 high
 number
 of
 results.
 Also
 the
 results
 returned
 by
 the
 suggestion
 algorithm
 are
 sorted
 by
 popularity,
 such
 that
 the
 most
popular
 tracks
 come
up
 in
 the
 limited
number
of
 suggestions
 at
 an
 early
 stage
of
typing.

 The
 server
 also
 offers
 the
 possibility
 to
monitor
 and
 change
 its
 state
 by
 other
 means
than
the
client
application
or
the
console.
A
servlet
connects
to
the
service
 and
 enquires
 status
 information
 like:
 state
 of
 the
music
 space,
 state
 of
 the
 db
 connection
or
errors
that
were
thrown
upon
client
requests;
this
information
is
 printed
 out
 in
 a
 web
 site
 so
 it
 can
 be
 accessed
 via
 a
 web
 browser.
 The
 























































 7
Service
that
proposes
tracks
as
result
of
user
inserted
words.
Described
later.

 
 22
 that
have
already
been
picked
by
the
algorithm
previously
and
cannot
be
chosen
 anymore.

 
 Figure
6­2
­
Jumping
behaviour
when
using
static
seed
 A
 modification
 of
 this
 algorithm
 might
 bring
 the
 solution
 to
 this
 problem:
 reassigning
 the
 seed
 for
 each
 iteration
 (Figure
 6‐3).
 The
 playlist
 generating
 algorithm
is
a
successive
iteration
of
an
algorithm
that
chooses
the
nearest
track
 to
 the
 seed,
 followed
 by
 setting
 the
 newly
 found
 track
 as
 seed
 for
 the
 next
 iteration.
In
this
way
the
application
avoids
as
much
as
possible
jumps
over
long
 distances
 in
music
 space
metric.
 In
 the
 same
 scenario
 as
 the
 last
 example,
 the
 modified
algorithm
performs
without
big
jumps.

 
 23
 
 Figure
6­3
­
Smoother
jumping
when
dynamically
assigning
seeds
 The
 modified
 algorithm
 also
 has
 other
 advantages:
 the
 distance
 between
 the
 chosen
 tracks
 is
 always
very
 short,
 guaranteeing
a
 smooth
 transition.
Not
only
 can
 the
 algorithm
 provide
 an
 infinite
 number
 of
 tracks,
 but
 also
 each
 track
 is
 guaranteed
to
be
very
similar
to
the
previous
one.
The
random
walking
behavior
 of
 the
 Amarok
 algorithm
 (Känel,
 2008)
 is
 also
 simulated,
 allowing
 the
 user
 to
 randomly
explore
unknown
regions
of
the
music
space.

 6.3.3 Improvement
 Choosing
 the
 nearest
 track
 to
 the
 current
 seed
 provides
 results
 equally
 distributed
 regarding
 the
 popularity
 of
 the
 tracks.
 But
 the
 probability
 of
 users
 enjoying
the
returned
tracks
is
greater
if
the
popularity
of
the
returned
track
is
 maximized.
 An
 improvement
 suggestion
 is
 therefore
 not
 to
 return
 the
 track
 nearest
to
the
seed,
but
the
track
in
the
vicinity
of
the
node
that
has
the
highest
 popularity.
To
find
it,
the
algorithm
queries
for
the
first
10
tracks
in
its
vicinity
 and
 takes
 the
 one
with
 the
maximum
 popularity.
 Figure
 6‐4
 shows
 a
 playlist‐ computing
example
with
and
without
this
enhancement.

 
 24
 
 Figure
6­4
­
Algorithm
performance
with
(right)
and
without
(left)
vicinity
priority
search
 The
 example
 in
 Figure
 6‐4
 shows
 the
 algorithm
 performing
 with
 or
 without
 vicinity
popularity
 search
 (the
vicinity
 consists
of
 three
 tracks).
On
 the
 left
 the
 algorithm
 selects
much
 less
 popular
 tracks
 in
 the
 first
 10
 than
 the
 one
 on
 the
 right;
but
all
this
comes
at
a
cost:
the
step
size
of
the
right
algorithm
is
no
more
 than
three
times
greater
(on
average)
than
the
one
on
the
left.

 Because
 songs
 of
 the
 same
 artist
 are
 usually
 very
 close
 together
 in
 the
music
 space,
the
application
tends
to
select
several
songs
of
the
same
artist
and
place
 them
successively
 in
 the
playlist.
This
 is
an
undesired
behavior.
To
avoid
 it
 the
 algorithm
can
be
taught
to
also
avoid
tracks
whose
artist
has
appeared
in
the
last
 4
 tracks.
 By
 applying
 this
 additional
 constraint,
 the
 algorithm
 avoids
 placing
 tracks
of
the
same
artist
less
then
4
tracks
apart.

 When
searching
for
tracks
in
the
vicinity
of
a
seed,
tracks
that
have
already
been
 added
to
this
playlist
in
the
past
are
omitted
–
as
a
rule.
Doing
so,
if
the
algorithm
 was
not
able
 to
 ‘move’
 to
a
different
region
 in
 the
music
space
 it
starts
picking
 the
 lower
 popularity
 tracks.
 So
 after
 24
 tracks
 the
 algorithm
 can
 start
 adding
 tracks
that
were
present
24
tracks
ago.
Why
24?
24
tracks
with
an
average
of
5
 min/track
are
almost
two
hours
of
music
–
enough
time
to
re‐enjoy
the
tracks.

 6.4 User
Feedback
 The
 importance
of
user
 feedback
(both
 indirect
and
direct)
has
been
discussed
 throughout
 several
 sections
of
 this
 report.
Most
 important
when
designing
 the
 feedback
algorithm
was
the
decision
what
data
to
store
so
that
it
is
of
use
to
any
 future
evaluation.

 6.4.1 Direct
and
Indirect
User
Feedback
 Direct
user
feedback
is
represented
by
the
feedback
the
user
chooses
to
submit
 to
the
application
in
order
to
help
the
community.
Currently
two
types
of
direct
 feedback
are
 implemented:
 ‘Quality
 is
 bad’
 and
 ‘I
 don’t
 like
 the
 track’.
Because
 
 27
 handle
 by
 itself.
 Among
 these
 services,
 the
 most
 important
 was
 to
 generate
 playlists
for
the
music
player
based
on
track
similarity
analysis.

 The
UI
was
 the
next
 thing
 to
debate
and
how
to
design
an
UI
 that
 is
both
very
 simple
and
intuitive,
but
also
powerful
enough
to
provide
enough
information
to
 the
 service
 when
 asking
 for
 playlists
 and
 also
 to
 be
 able
 to
 record
 the
 user’s
 action
for
a
future
evaluation.

 YouTube
 has
 been
 chosen
 as
 main
 music
 content
 provider
 and
 the
 main
 arguments
 that
 brought
 it
 a
 step
 in
 front
 of
 Last.fm
 were
 the
 good
 enough
 coverage
 of
 the
 music
 space
 and
 an
 availability
 of
 full‐length
 tracks,
 whereas
 Last.fm
 usually
 provides
 only
 a
 30
 seconds
 snippet
 for
 a
 track.
 Analysis
 of
 YouTube
coverage
shown
that
in
a
real
life
example,
YouTube
offers
content
for
 about
 80%
 of
 the
 tracks.
 Unfortunately,
 the
 current
 implementation
 can
 find
 only
 60%
 of
 the
 tracks
 in
 a
 satisfactory
 quality
 range.
 However
 it
 has
 been
 shown
that
with
post‐processing
of
the
YouTube
results,
an
additional
17%
can
 be
mapped
to
good
quality
track
implementations
on
YouTube,
making
it
able
to
 provide
good
results
to
about
77%
of
the
user’s
requests.
Also
it
has
been
shown
 that
 through
 a
 good
 feedback
 system,
 these
 numbers
 can
 be
 boosted
 even
 further.
Note
that
these
percentages
reflect
the
real
world
usage
statistics
of
the
 application
(i.e.
highly
popular
tracks);
they
cannot
be
generalized
for
the
whole
 music
space.

 The
 playlist
 generating
 algorithm
 is
 based
 on
 analysis
 of
 the
 provided
 music
 space
 and
 its
 possibilities
 as
 similarity
 measurement
 tool.
 Several
 algorithms
 previously
 developed
 by
 ETH
members
 were
 presented
 and
 analyzed
 both
 in
 respect
to
their
own
advantages
and
limitations
but
also
their
use
in
the
context
 of
 this
 project.
 An
 algorithm
 has
 been
 developed
 that
 uses
 only
 one
 seed
 to
 create
 an
 ‘infinite’
 series
 of
 succeeding
 tracks
 –
 meaning
 tracks
 that
 are
 each
 very
similar
to
the
previous
and
next
one.
The
simplicity
of
the
algorithm
makes
 it
possible
 to
 request
any
number
of
 tracks
 from
the
system
and
 the
similarity
 metric
 between
 two
 successive
 tracks
 to
 be
 constant
 over
 the
 whole
 list
 of
 returned
tracks.
Also,
the
list
attempts
to
take
the
user
on
random
walks
in
the
 music
 space
 to
 explore
 new
 regions
 of
 music.
 Enhancements
 brought
 to
 the
 algorithm,
like
using
the
popularity
value
of
each
track
to
make
a
more
advanced
 selection
 of
 neighboring
 tracks,
 raised
 the
 average
popularity
 of
 the
 outputted
 tracks
making
the
algorithm
provide
tracks
that
are
even
more
attractive
to
the
 users.

 The
goal
of
building
a
simple
skeleton
application
for
providing
an
online
music
 player
 has
 been
 achieved.
 The
 application
 is
 a
 good
 playground
 for
 further
 developments
or
innovations
especially
in
the
algorithmic
part.

 8 Discussion
and
Future
Work
 The
 Section
 deals
with
 the
 ideas
 that
 didn’t
make
 it
 to
 the
 development
 process
 mainly
because
of
the
tight
time
schedule,
but
that
are
important
to
mention
and
 at
some
point
or
another
have
to
be
addressed
in
future
development.

 
 28
 8.1 Achievements
 The
 goal
 of
 the
 thesis
 was
 to
 create
 a
 simple
 application
 to
 be
 used
 as
 a
 playground
for
future
ideas
of
providing
valuable
music
content
to
users.
Also
a
 simple
algorithm
was
developed
that
delivers
good
playlists
with
minimal
input
 from
the
user
side.

 8.2 Future
Work
 8.2.1 Nice
to
Have
 Especially
on
the
side
of
playlist‐generating
algorithms
there
is
space
for
a
lot
of
 new
ideas.
Past
ETH
internal
reports
have
shown
that
there
are
a
lot
of
ideas
that
 can
make
the
best
out
of
the
given
music
space.
Some
of
the
ideas
were
discussed
 in
this
report
to
find
a
new
algorithm
that
combines
the
advantages
of
the
other
 algorithms
while
repressing
the
downsides.
Of
course
no
algorithm
is
perfect
in
 every
sense,
but
especially
this
report
shows
that
one
can
find
a
better
algorithm
 as
 other
 approaches,
 as
 long
 as
 it’s
 customized
 on
 the
 targeted
 solution.
 Algorithms
 that
 require
more
 elaborate
 user
 input
 can
be
 easily
 deployed
 and
 tested
on
the
developed
application
because
of
its
module‐based
structure.
Some
 examples
of
such
algorithms
are
found
in
the
other
ETH
internal
reports
like
the
 musicexplorer
web
application,
 the
Amarok
plugin
and
a
 (not
 further
detailed)
 like/dislike
 track
 generation
 algorithm
 (developed
 for
 the
 Android
 platform,
 (Bossard
L.
,
2008)
currently
under
submission).

 When
 discussing
 the
 KDTree
 and
 its
 all‐in‐memory
 implementation,
 the
 disadvantages
of
this
solution
have
been
presented.
A
future
step
is
to
integrate
 the
KDTree
more
into
a
database,
rather
than
storing
the
data
in
memory.

 In
retrieving
the
results
from
YouTube
the
application
does
perform
well
only
on
 60%
of
the
tracks.
A
post‐processing
algorithm
has
been
presented
that
helps
the
 rising
 this
margin
 to
77%;
 this
algorithm
has
not
been
yet
 implemented
 in
 the
 application.
Also
the
integration
of
user
feedback
is
very
helpful
if
considered.

 Depending
on
 the
concurrent
user
access
on
 the
service,
parts
of,
or
 the
whole
 concept
of
shared
resources
would
have
to
be
generated
all
over.
Especially
the
 suggestion
 retrieval
 algorithm,
 currently
 running
 in
 the
Server’s
 core,
 could
be
 externalized
 to
 a
module
 and
 enhanced
 not
 to
 crawl
 the
 database
 each
 time
 a
 user
hits
a
keystroke.

 8.2.2 Feedback
Analysis
and
Integration
 The
 feedback
 recorded
 by
 the
 application
 is
 very
 important
 for
 it’s
 future
 development.
It
gives
a
lot
of
information
about
the
users
behavior
and
allows
a
 good
analysis
of
 their
actions
when
using
the
application.
Based
on
the
results,
 some
of
the
parts
of
the
application
can
be
changed,
most
probably
the
playlist
 generation
algorithm
if
it
turns
out
that
the
people
are
not
very
satisfied
with
the
 results.

 Even
 more
 important
 is
 to
 analyze
 and
 react
 to
 direct
 user
 feedback.
 This
 is
 especially
essential
in
managing
the
quality
of
the
YouTube
videos
of
the
tracks.
 Because
 this
 quality
 warranty
 is
 out
 of
 the
 hands
 of
 this
 application
 it’s
 important
to
react
to
the
user’s
feedback
on
this
matter.

 
 29
 Implementing
 a
 mechanism
 that
 allows
 users
 to
 suggest
 a
 better
 YouTube
 content
 based
 on
 several
 proposals
 is
 an
 important
 tool
 for
 the
 current
 application,
because
it
would
allow
the
users
to
directly
help
at
providing
good
 music
content.
Through
 implementing
an
advanced
user
 feedback
 function,
 the
 application
could
be
designed
to
analyze
the
received
feedback
and
to
update
its
 state
automatically
and
in
real
time,
for
the
benefit
of
the
whole
community.

 8.2.3 User
Awareness
 Another
 point
 only
 touched
 by
 the
 current
 implementation
 is
 the
 Facebook
 integration.
The
application
is
available
on
Facebook
and
users
can
recommend
 it
 to
 their
 friends,
but
 the
application
 is
not
using
 the
access
 to
 the
user’s
data
 yet.
 This
 data
 could
 prove
 very
 important,
 especially
 for
 generating
 the
 application’s
own
–
unbiased
–
track
similarity
space.
Tracks
listened
to
by
users
 could
 be
 analyzed
 over
 several
 sessions,
 not
 only
 session‐based
 as
 it
 happens
 now,
moreover
it
could
be
compared
to
the
history
of
friends
to
determine
ways
 of
recommending
tracks
based
on
the
friends’
preferences.

 Having
such
a
knowledge
about
the
users
could
lead
to
completely
new
ways
of
 generating
 playlists,
 maybe
 without
 any
 user
 interaction
 at
 all…
 similar
 to
 Last.fm’s
approach,
but
with
possibly
better
 results
because
 the
playlists
 could
 be
based
not
only
on
the
private
but
also
on
the
friends’
track
history.

 9 Bibliography
 Bossard,
 L.
 (2008).
 Pancho
 ­
 The
 Mobile
 Music
 Explorer.
 Zürich:
 DCG.TIK.EE.ETZH.CH.
 Bossard,
 L.
 (2008).
 Visually
 and
 Acoustically
 Exploring
 the
 High­Dimensional
 Space
of
Music.
Zürich:
DCG.TIK.EE.ETHZ.CH.
 Gonukula,
 A.,
 Kuederli,
 P.,
 &
 Pasquier,
 S.
 (2008).
MusicExplorer:
 Exploring
 the
 Space
of
Songs
on
your
PC.
Zurich:
DCG.TIK.EE.ETHZ.CH.
 Google.
 (2008,
 04
18).
Google
Web
Toolkit.
 Retrieved
04
18,
 2008,
 from
Googe
 Code:
http://code.google.com/webtoolkit/
 Lorenzi,
 M.
 (2007).
 Similarity
 Measures
 in
 the
 World
 of
 Music.
 Zurich:
 DCG.TIK.EE.ETHZ.
 Unknown.
(2008).
Amarok
Plugin.
Zürich:
DCG.TIK.EE.ETHZ.CH.
 Wikipedia.
 (2008,
 04
 18).
 AJAX
 (programming).
 Retrieved
 04
 18,
 2008,
 from
 Wikipedia:
http://en.wikipedia.org/wiki/Ajax_(programming)
 Wikipedia.
 (2009,
 04
 22).
 KD
 Trees.
 Retrieved
 04
 22,
 2009,
 from
 Wikipedia:
 http://en.wikipedia.org/wiki/Kd_tree