MusicBeetle

Intelligent Music Royalties Collection and Distribution System

Carlos Serrão, Hélder Carvalho and Nelson Carv

alho

ISCTE-IUL/ISTAR-IUL, Ed. ISCTE, Av. das Forças Armadas, 1649-026 Lisboa, Portugal

Keywords: Music, Related-Rights, Royalties, Distribution, Cloud, Recommendation.

Abstract: Music industry has been completely disrupted by a range of new online digital services and social network-

ing systems that has forever changed the way users and businesses experience and use music. This had a

tremendous impact on the established music business models that had guided a dozen year-old industry. On

what concerns business music users, i.e. businesses that make use of music as part of their own business

model, and on the business relation they establish with author societies or their representatives, they are re-

quired to pay royalties for the use of music. These royalties need to be distributed and authors will have the

opportunity to see their work rewarded properly. The proper distribution of royalties is a non-transparent

and complex process. In this paper, the authors present a system, called MusicBeetle that enables the identi-

fication, collection and distribution of music royalties through the usage of decentralised system and low

cost hardware devices.

1 INTRODUCTION

The Internet and the digital technology has created

serious challenges in terms of Intellectual Property

protection and management of digital content assets,

for both end-users, content authors, content distribu-

tors and rights collecting and distributing societies

(Torres, Serrão, Dias and Delgado, 2008).

The Related Rights (RR) or Neighbouring Rights

(NR) are terms in copyright law that represent the

rights which are similar to the author rights but

which are not connected with the actual author of the

work (Frith and Marshall, 2004). Both the author

rights and the related rights are copyrights. The

RR/NR are independent of any authors’ rights,

which may also exist in the work (WIPO, 1961). The

rights of performers, phonogram producers and

broadcasting organisations are certainly covered,

and are internationally protected by the RR/NR

legislation (Correa, 2007). In the specific case of the

music industry, and as an example, four different

CD recording of a song:

•

The authors’ rights of the composer of the music;

•

The authors’ rights of the lyricist;

•

The performers’ rights of a singer and the musi-

cians;

•

The producers’ rights of the person or corpora-

tion, which made the recording.

Therefore one the most important activities of

these Music Related/Neighbouring Rights Manage-

ment Societies (MRNRMS) is the collection of

neighbouring rights on behalf of producers and per-

formers related to public performance of recorded

music (Correa, 2007). Consequently the mission of a

MRNRMS can be resumed in the following four

major objectives:

•

Raise public awareness to the reality of relat-

ed/neighbouring rights and the need for its pro-

tection (a fact still relatively new and little

known);

•

Boosting the delivery of remuneration for distri-

bution to the holders, be they producers or art-

ists;

•

Realize the collection of related/neighbouring

rights to all places of public performance using

recorded music for commercial purposes, as well

as all the inspectors to use of recorded music, by

any means;

•

The community awareness in relation to associ-

ated rights will, in large part, be accomplished

with the collaboration of public authorities with

powers of supervision on Copyright and Relat-

ed/Neighbouring Rights, as well as the users of

406

Serrão C., Carvalho H. and Carvalho N..

MusicBeetle - Intelligent Music Royalties Collection and Distribution System.

DOI: 10.5220/0005486304060413

In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 406-413

ISBN: 978-989-758-104-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

recorded music in various areas and industries

that in compliance with the law, should ask for

their license.

These MRNRMS are responsible for issuing li-

censes to businesses that use represented recording

music as a mean to conduct their own business mod-

els. Moreover, they are also responsible for the ef-

fective collection and distribution of the associated

fees to the music producers, performers and authors

(Bustinza, Vendrell-Herrero, Parry, and Myrthianos,

2013). Most of these MRNRMS exist in nearly eve-

ry civilised country in the World and they often

operate their business based on manual and non-

automatic processes, causing them to be less effec-

tive on their core business functions.

2 BUSINESS MUSIC USERS

(BMU) AND ROYALTIES

DISTRIBUTION

Businesses use in-store media entertainment content

as a way to increase the perceived value of their core

business while engaging more customers and creat-

ing the opportunities for them to stay longer and

consume more (Teece, 2010). Music is an important

part of their business model. They recognise its

importance and therefore are willing to comply with

the legal requirements that impose the payment of

royalties to authors. Not only business music users

(BMU) are required to use legal content (legally

acquired music) but they also need a public execu-

tion license (Vaccaro and Cohn, 2004). Public exe-

cution licenses are a requirement for businesses that

depend on the usage of music for public execution

on their businesses - this includes, for instance, dis-

cos, bars, restaurants, stores, gyms, parking zones,

hotels and many more.

The MRNRMS are responsible for collecting the

rights royalties from the different BMU and distrib-

ute those royalties to the different beneficiaries of

such royalties (artists, performers, and others). Usu-

ally this distribution method is performed through

the sampling of the percentage of the number of

times a given music is played on a given medium

(Figure 1). Currently, some specific companies are

hired to audit the music usage, using specific human

auditors to listen to the different medium (radio

stations, TV channels, and some other mass media

mediums) for a given period of time and produce

statistical data estimations that are used to extrapo-

late the real music usage ratings that are after used to

perform royalties distribution. Also, some additional

criteria are used to charge BMU, like the business

space, the number of days the business operates

during the year, and other similar.

Figure 1: Related-rights distribution scenario.

The way, this all process is conducted, is com-

pletely error prone and not transparent. The process

is not accurate, and leaves out from the royalties

distribution chain some of the less well-known art-

ists (Castro, Alves, Serrão and Caraway, 2010).

Moreover, this system can only be used for larger

music distribution channels, and are not adequate for

the different BMU that use music as part of their

business model - they represent a large amount of

entities that are charged for a license that enable

them to use music on their business and execute

their business model.

These facts have created the need for a new type

of system that allowed the MRNRMS to charge

BMU in a fairer way and distribute owed royalties to

artists in a more transparent manner.

The following sections of this paper present a

system, called MusicBeetle, that is responsible for

automatically auditing the music usage by BMU and

by ensuring the appropriate royalties collection by

the MRNRMS and distribution to the authors. The

following section presents the MusicBeetle system

that is divided into two different components - Mu-

sicBeetle.box and the MusicBeetle.cloud. The two

components are further described and details about

how they both operate to fulfil the automatic music

auditing process and royalties distribution.

3 THE MUSICBEETLE SYSTEM

In order to improve the related-rights royalties col-

lection and distribution process that is implemented

manually by the MRNRMS, it was designed and

implemented a system that automates the entire

process.

MusicBeetle-IntelligentMusicRoyaltiesCollectionandDistributionSystem

407

The system, called MusicBeetle, was composed

by two different components: (a) a critical client-

side component that was capable of automatically

identifying the music being used and create a report

of all the music used on a given period of time by a

specific BMU (MusicBeetle.box), and (b) a set of

cloud-based services integrated with the MRNRMS

information systems that registers all the different

music business licensees, their music usage profile,

and information about music identification and art-

ists database (MusicBeetle.cloud).

In order for the entire system to work, the differ-

ent BMU have to install specific hardware devices

that are connected to the Internet (the MusicBee-

tle.box, that will be presented in the following sec-

tion) and connected to the music sound system used

by the BMU. On the other side, the MRNRMS has

access to an large database of the entire music reper-

toire that they represent on a given country or has

the means to access further information online.

The following sections provide an overview of

these two different components of the system, how

they interoperate and which are their major func-

tionalities.

3.1 MusicBeetle.box

The MusicBeetle.box is one of the critical compo-

nents on the system. This client-side hardware com-

ponent allows the system to actively listen to the

music being used at the BMU side, record the music

candidate identification, and report back the music

consumption to the MRNRMS.

Here are some of the most important require-

ments for the development of such critical compo-

nent:

•

The system should be able to connect to an ex-

ternal sound system;

•

It should be able to listen to the music that is be-

ing played at the sound system;

•

It should be connected to the Internet (or at least

it should temporarily connected to the Internet -

not requiring a permanent connection);

•

The system should be able to create unique iden-

tifiers for the music that is listening (from time to

time) based on audio fingerprinting technology

(Cano, Batlle, Kalker, and Haitsma, 2005);

•

The system should be able to record at least a

month time of audio identifiers;

•

And finally, another important requirement is

that the system should be inexpensive.

All of the above requirements were considered in

the design and development of a solution.

3.1.1 MusicBeetle.box Hardware

Architecture

Having into consideration all of the previous tech-

nical and financial requirements, the obvious choice

was to select an inexpensive hardware solution,

based on the “all-in-one” boards that existed on the

market. After analysing some of the existing ones

(Raspberry Pi, CubieBoard, PandaBoard, Beagle-

Board, and CuBox), it was decided to select the

Raspberry Pi (RPi). The RPi represents a cost effec-

tive solution that also presents the processing capa-

bilities required by the solution to implement.

Figure 2: MusicBeetle.box (based on the Raspberry Pi

hardware) and the integration with the client Sound Sys-

tem and the Internet.

Therefore, RPi was selected as the principal

hardware component to implement the MusicBee-

tle.box prototype (Richardson and Wallace, 2012).

Raspberry Pi is a credit card-sized single-board

computer that was developed in the UK by the

Raspberry Pi Foundation with the intention of pro-

moting the teaching of basic computer science in

schools. Raspberry Pi is based on the Broadcom

system on a chip (SoC), including an ARM proces-

sor, a GPU, and some amount of memory (originally

256 MB and later 512 MB). The system has Secure

Digital (SD) or MicroSD sockets for boot media and

persistent storage (Upton and Halfacree, 2012).

Moreover, Raspberry Pi has also an HDMI port,

several USB ports, an Ethernet port and an audio

connector (Figure 2).

The Raspberry Pi board has become the natural

and adequate solution to sustain the MusicBee-

tle.box system and to implement crucial require-

ments, like the capability to listen to music and con-

nect to the Internet to report the audited music. Ad-

ditionally, each of the RPi boards costs around 35

euros, making it inexpensive enough for mass distri-

bution.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

408

3.1.2 MusicBeetle.box Logical and Software

Architecture

Apart from the hardware that was selected, the Mu-

sicBeetle.box is also composed by a set of software

that was specifically developed to implement some

of the requirements of the system. All the developed

software runs on the Raspbian Linux-based (on the

Debian Wheezy distribution) operating system. On

top of the operating system, a set of specifically

developed software is running to implement a set of

operations that enable the correct operation of the

MusicBeetle.Box.

The following schema (Figure 3) depicts how the

MusicBeetle operates to conduct the music audits at

the BMU side.

Figure 3: Schema that demonstrates how the MusicBee-

tle.box operates to audit music usage.

The implemented music auditing process is

composed by the following operations:

1. The MusicBeetle.box has an active process that

continuously listens for the existence of new

music on the sound board;

2. Every time music/audio is detected, the process

captures and records 15 seconds of audio data;

3. A candidate audio fingerprint is calculated for

the audio sample from this 15 seconds of cap-

tured audio;

4. A timestamp of the date and time of the audio

data capture and the candidate audio fingerprint

are stored on a temporary MusicBeetle.box da-

tabase;

5. After a waiting process of 30 seconds, the pro-

cess verifies if there is more audio data availa-

ble to capture. If there is, it repeats the entire

workflow (returning to step 2).

In order to conduct this auditing process and be-

ing able to operate at the BMU side, the MusicBee-

tle.box implements the following software architec-

ture (Figure 4). This software architecture lies on top

of the specific Raspberry Pi Linux distribution

(Raspbian), with some specific software developed

for accomplishing the required tasks of the Mu-

sicBeetle.box.

Figure 4: Schema that demonstrates how the MusicBee-

tle.box operates to audit music usage.

The MusicBeetle.box is composed by two differ-

ent software processes that are running on the box.

These two software processes are “music_audit” and

“music_report”. Both of these processes are auto-

matically activated immediately after the Raspberry

Pi is turned on and the Raspbian operating system

finishes booting up.

The “music_audit” is the process that is respon-

sible for auditing and identifying the music that is

used at the BMU side. This process conducts the

following functions:

•

Actively listens to the sound board for the exist-

ence of audio data. If that data exists, “mu-

MusicBeetle-IntelligentMusicRoyaltiesCollectionandDistributionSystem

409

sic_audit” records 15 seconds of the audio data,

using “arecord” (an utility that is part of the AL-

SA utils package) and saves it to a temporary

file;

•

After this, “music_audit” uses two different audio

fingerprint open-source tools (AccoustID and

Echoprint) to create two candidate audio finger-

prints from the audio samples that were previ-

ously captured and recorded, using “chromaprint”

and “echoprint”. These audio fingerprints are

used to create a tentatively positive identification

of the music being played, while performing a

posterior comparison with a fingerprinting data-

base in a matching process. The matching pro-

cess takes place at the MusicBeetle.cloud;

•

The following example describes how to how to

use “echoprint” to create a audio fingerprint from

an audio sample captured by the box:

“./echoprint-codegen audio_sample_[01].mp3 0

15”.

•

After creating the two candidate audio finger-

prints, “music_audit” saves them, together with a

timestamp of the date and time of the audio sam-

ple capture. This data is saved on an temporary

SQLite database (“sqlite”);

•

“music_audit” continues to actively monitor the

existence of more audio data on the audio board

of the Raspberry Pi, repeating the recording, au-

dio fingerprinting and saving processes.

The “music_report” is the process that is respon-

sible for the communication of the candidate music

identifications detected by the MusicBeetle.box to

the MusicBeetle.cloud system. This process is re-

sponsible for the following functions:

•

“music_report” is a process that is run by the

“crond” Linux daemon. “crond” runs “mu-

sic_report” on a daily basis (every 24 hours), at a

given time (the frequency and time can be con-

figured on the MusicBeetle.box);

•

“music_report” connects to the SQLite database

and extracts all the available records that corre-

spond to the last period of audited music that has

not yet been send to the MusicBeetle.cloud;

•

The process builds a JSON data structure (Figure

5) that contains the necessary data to be sent to

the MusicBeetle.cloud. This structure contains

information about the unique identifier of the

MusicBeetle.box on the system (UUID), a

timestamp of the data and time of the transfer

(TIMESTAMP), the two values of the samples

fingerprints (FP1 and FP2, each one created with

a different audio fingerprinting algorithm) and

the identifier of the audio sample (SID);

•

After this, “music_report” establishes a secure

connection, using SSL/TLS protocol, with the

MusicBeetle.cloud service endpoint and posts the

JSON data structure over the network. If no con-

nection is available, MusicBeetle.box will retain

the previous audit data and continues to store

more data, until a connection becomes available

and the transfer process concludes with success

(after receiving a message from the MusicBee-

tle.cloud service confirming that the data recep-

tion was successful).

{

“musicbeetlebox_uuid”: “[UUID]”,

“transfer_timestamp”:

“[TIMESTAMP]”,

“audits”: [

{

“sample_id”: “[SID]”,

“sample_timestamp”:

“[TIMESTAMP]”,

“sample_fp”: [

“fp1”: “[FP1]”,

“fp2”: “[FP2]”

{

“sample_id”: “[SID]”,

“sample_timestamp”:

“[TIMESTAMP]”,

“sample_fp”: [

“fp1”:

“[FP1]”,

“fp2”: “[FP2]”

}

]

}

Figure 5: Sample JSON data structure containing the data

to be sent from the MusicBeetle.box to the MusicBee-

tle.cloud. [UUID], [TIMESTAMP], [SID], [FP1] and

[FP2] are simply placeholders that are replaced by the

actual values.

Both the “music_audit” and “music_report” are

two important processes in the way the MusicBee-

tle.box operates and conducts its major functionality:

audit the BMU music real usage and reporting that

information back to the MRNRMS. All the match-

ing, accounting and management is performed on

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

410

the MusicBeetle.cloud, that will be detailed in the

following section.

3.2 MusicBeetle.cloud and Services

MusicBeetle.cloud is a key element in the Mu-

sicBeetle ecosystem. It represents the services that

are run on a cloud service by the MRNRMS that will

enable the management of the music portfolio (and

artists) whose rights are represented and managed by

the MRNRMS. These services have to assure the

following:

•

The MRNRMS should have a system with data

that represents the music and artist portfolio

whose rights they represent. This system should

contain not only information about the music, but

also about the artists;

•

MusicBeetle.cloud should also have information

about the BMU that are registered at the MRN-

RMS, and information about the MusicBee-

tle.boxes that are installed on their side;

•

Also another important service that is required is

the capability of being able to match the audio

audits, sent from multiple MusicBeetle.boxes,

and then perform the identification of the music

tracks, and account for the number of times a

Figure 6: The schema represents the different services that

are running on the MusicBeetle.cloud and how they inter-

act with other systems (both internal to the MusicBeetle

ecosystem or outside).

given music track has been played by the BMU

during a given period of time;

•

The MusicBeetle.cloud service should also be

capable of accounting the necessary amount to

be distributed to a given artist, according to the

music usage by the BMU ecosystem (that are le-

gally licensed by the MRNRMS and possess a

MusicBeetle.box) as well as to charge the specif-

ic rightful amount to the BMU according to the

effective music usage.

The different services present at the MusicBee-

tle.cloud (Figure 6) cooperate with each other and

with external services to ensure that MusicBeetle

can meet the requirements that were previously

identified. One of the most crucial operations of

these services is the capability to receive reports

from the different installed MusicBeetle.boxes, and

process such reports in terms of music identification,

royalties accounting and fees to be charged to the

BMU. This process is detailed on the next section.

3.2.1 Music Identification, Reporting and

Royalties Management Process

One of the most vital operations that is executed at

the MusicBeetle.cloud is the capability to receive the

multiple reports from the MusicBeetle.boxes, and

process them in terms of music identification, royal-

ties distribution and fees charging.

In order for these services to operate properly,

the following assumptions need to be fulfilled:

1. It is necessary to build a repository that con-

tains the music meta-information (related to the

music track) and audio fingerprints that are

unique to each of the music tracks. Each music

track must also be associated with an artist (or

multiple artists and/or recording label, if it is

the case);

2. A repository with the information about the art-

ists that are represented (registered) by the

MRNRMS is necessary, and a relation with

their music tracks;

3. It is also necessary to have all the information

about the BMU that are licensed by the MRN-

RMS and the list of MusicBeetle.boxes that are

assigned to them.

After all of these pre-requisites are met, the pro-

cess that is responsible for music identification,

royalties distribution and fees charging is aligned

with the following steps:

1. The process is initiated by the MusicBee-

tle.boxes while sending report data to the “Mu-

sic Identification and Matching Service”;

1.1. The “Music Identification and Matching

MusicBeetle-IntelligentMusicRoyaltiesCollectionandDistributionSystem

411

Service” receives the JSON data from the

MusicBeetle.box;

1.2. The service verifies the field that con-

tains “musicbeetlebox_uuid” and contacts

the “Music business users and MusicBee-

tle.boxes service registry” to check if that

specific MusicBeetle.box is registered and

is valid within the MRNRMS context;

1.3. After validating the MusicBeetle.box,

the service contacts the “Music Business

users accounting service” to retrieve identi-

fication of the BMU that will be charged for

the music usage.

2. After these initial steps, the “Music Identifica-

tion and Matching Service” will try to identify

the music tracks send on the JSON report.

2.1. The service looks into the “audits” field

of the report and starts looking for existing

music samples (“sample_id”) identification;

2.2. For each of the samples, the “sam-

ple_id”, “sample_timestamp” and “sam-

ple_fp” are retrieved;

2.3. Inside the “sample_fp” the values of

both “fp1” and “fp2” are extracted;

2.4. “fp1” and “fp2” are used by the match-

ing service to identify the music to which

the samples refer to. The “Music and Artists

Portfolio Management service” is used to

perform this matching operation. If a match

is found, the corresponding music meta-

information can be retrieved and infor-

mation about the music track and the corre-

sponding artist can be used to establish the

royalties distribution process;

2.5. If the sample fingerprints cannot be

matched to any of the musics at the reposi-

tory, it will be possible to pass that data to

external matching and identification ser-

vices to try a successful identification;

2.6. If it is not possible to identify a music

sample, it is classified is a particular way,

so that the MRNRMS can find a different

way to distribute the royalties;

3. Finally, after the music track is identified, it is

possible to direct the usage royalties to the ap-

propriated artists and to charge the correct and

fair fees to the BMU:

3.1. After the matching process concludes

with success the service contacts the “Rep-

resented artists accounting service” to credit

the artist for the corresponding value of its

music usage;

3.2. The service also contacts the “Music

business users accounting service” to debit

the BMU on the usage of that specific mu-

sic track.

This process is repeated for each of the Mu-

sicBeetle.boxes that report music auditing infor-

mation to the services on the MusicBeetle.cloud.

4 CONCLUSIONS

The music industry has changed across time. The

well-established music business models that lasted

for decades were completely shacked by a new

emerging reality boosted by technology. Information

and Communication Technologies (ICT) (Rosen-

blatt, Mooney and Trippe, 2001) has altered the

relation between recording companies, artists, music

and end-users (both individuals and businesses)

(Vaccaro and Cohn, 2004). At the same time ICT

has also created new music business models and

raised opportunities for key actors in the music val-

ue-chain to become more efficient in its mission

fulfillment (Handke and Towse, 2007).

One of these actors is the Music Relat-

ed/Neighbouring Rights Management Societies

(MRNRMS), entities that are responsible for the

collection and distribution of royalties on the behalf

of the artist (or other entities that represent them)

(Kretschmer, Klimis and Wallis, 1999). These

MRNRMS license BMU, charging them a fee for

using commercial music as part of their core busi-

ness model and distribute these fees to the represent-

ed artists (Towse, 1999). The problem is that collec-

tion and distribution process is not fair, accurate or

transparent. Therefore there was the necessity for a

system that could charge BMU according to their

actual music usage, and distribute royalties to artists

whose music’s have been played. The MusicBeetle

system was developed to provide the necessary an-

swer to these requirements.

The developed prototype was tested in the par-

ticular context of a Portuguese MRNRMS, where

some of the properly licensed BMU were invited to

participate in the system trials.

From the tests conducted it was possible to im-

prove the way the license was charged to the MRN-

RMS customers, this more direct relation with the

real music consumption, improved the way the roy-

alties collection occurred (resulting from the direct

music usage by the BMU) and also ensure more

transparency on the way the royalties are distributed.

Artists represented by the MRNRMS or by any of its

associates received the royalties’ value according to

its real music usage.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

412

MusicBeetle contributed to the rethinking of an

old paradigm in Related Rights (RR) or Neighbour-

ing Rights (NR) royalties’ collection and distribu-

tion, enabling a fairer rights charging and collection

and a transparent distribution of royalties. Besides

this, the system also provided the necessary mecha-

nisms to audit the charging and distribution of such

royalties.

REFERENCES

Bustinza, O. F., Vendrell-Herrero, F., Parry, G., and Myr-

thianos, V. (2013). Music business models and piracy.

Industrial Management and Data Systems, 113(1), 4–

22.

Cano, P., Batlle, E., Kalker, T., and Haitsma, J. (2005). A

review of audio fingerprinting. Journal of VLSI Signal

Processing Systems for Signal, Image and Video

Technology, 41(3), 271–284.

Castro, H., Alves, A. P., Serrão, C., and Caraway, B.

(2010). A new paradigm for content producers. Mul-

tiMedia, IEEE, 17(2), 90-93.

Correa, C. (2007). Trade related aspects of intellectual

property rights: a commentary on the TRIPS agree-

ment. OUP Catalogue.

Edinburgh University Press.

Handke, C., and Towse, R. (2007). Economics of copy-

right collecting societies. International Review of In-

tellectual Property and Competition Law, 38(8), 937-

957.

Kretschmer, M., Klimis, G. M., and Wallis, R. (1999). The

changing location of intellectual property rights in mu-

sic: A study of music publishers, collecting societies

and media conglomerates. Prometheus, 17(2), 163-

186.

Richardson, M., and Wallace, S. (2012). Getting Started

with Raspberry Pi. “ O’Reilly Media, Inc.”

Rosenblatt, W., Mooney, S., and Trippe, W. (2001). Digi-

tal rights management: business and technology. John

Wiley and Sons, Inc.

Teece, D. J. (2010). Business models, business strategy

and innovation. Long range planning, 43(2), 172-194.

Torres, V., Serrão, C., Dias, M. S., and Delgado, J. (2008).

Open DRM and the Future of Media. MultiMedia,

IEEE, 15(2), 28-36.

application to performers’ rights in the music industry.

Kyklos, 52(3), 369-390.

Upton, E., and Halfacree, G. (2012). Meet the Raspberry

Pi. John Wiley and Sons.

Vaccaro, V. L., and Cohn, D. Y. (2004). The evolution of

business models and marketing strategies in the music

industry. International Journal on Media Management,

6(1-2), 46-58.

WIPO. (1961). WIPO-Administered Treaties: Rome Con-

vention for the Protection of Performers, Producers of

Phonograms and Broadcasting Organizations. Re-

trieved February 06, 2015, from

http://www.wipo.int/treaties/en/text.jsp?file_id=28975

MusicBeetle-IntelligentMusicRoyaltiesCollectionandDistributionSystem

413