Re: Possible Future Extensions
Andre Wiethoff <[email protected]> Wed, 06 May 2015 11:39:05 +0200
| Newsgroups | gmane.comp.audio.musicbrainz.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============0593810532==
Content-Type: multipart/alternative;
boundary="------------000804090004080805000700"
This is a multi-part message in MIME format.
--------------000804090004080805000700
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Hello Daniel,
thanks for your reply and your thoughts!
> This is something that I would like to do eventually but I have not
> gotten around to starting.
> Musicbrainz has user collections, this feature allows people to add
> releases to a public or private list.
> For the moment this only works for Releases (ie albums) and events but
> I believe as part of the shema change on scheduled for the 18th of May
> this will be changed to allow for more types of data to be stored.
I haven't found any information/description about the user in the
database scheme description on the homepage.
Of course it would be nice to extend the users that also (quite)
anonymous users with a user token (and a password hash) could login and
store their information with Musicbrainz.
> Musicbrainz also has a rating system that allows people to submit a
> number between 1 and 5 for most entries but there is not a lot of
> people that use this
I also found no information about this on the webpage... I assume that
this data is stored in the derived data database?
If so, we would need to think a about changing the scrobbling and rating
to a different license, as I really would like to see that data free for
any use (otherwise some uses are restricted for some players). Anyway,
it would be a possibility to offer the baseline web service for
recommending songs for free for non-commercial use and per license for
commercial projects...
> One thing missing is collections would not be able to store play
> counts so you would need to store that history somewhere else.
> We do not necessarily need to write our own scrobbeling api, it might
> be useful to use last.fm <http://last.fm> or libre.fm <http://libre.fm>
> Last.fm has api's so it should be possible to pull or push information
> out of there easily.
> libre.fm <http://libre.fm> is open source but it has mostly been
> dormant for the last few years.
Last.fm has some restrictions. You are able to query the scrobbling
history for a single user, but this would only help for exporting the
data to a different database for a single user (which is not allowed).
Also the usage of last.fm has a special terms of service (
http://www.lastfm.de/api/tos ), e.g. that they "the right to share in
revenue generated from your use of Last.fm Data" or "You must not
sub-license the Last.fm Data to others" or "For more information about
how to apply to use the API and Last.fm Data for commercial purposes..."
or "You are permitted to use the Last.fm Data solely for non-commercial
purposes and for no other purpose and subject always to any limitations
or conditions as advised to You by Last.fm at any time" or "You will not
make more than 5 requests per originating IP address per second,
averaged over a 5 minute period, without prior written consent". I think
that these restrictions are enough for not being able to use the data in
the last.fm database for a collaborate recommendation engine...
I didn't know of libre.fm, they have a large support community
("Libre.fm is supported by Bytemark, BigV, The Internet Archive and
ISC"). The last commit was from may 2014, so there was no development
for the last year at all. Further I think they have a kind of closed
ecosystem for promoting "open" artists, which can be played directly
from their webpage (sadly there was not much information about the
service itself on their webpage). Additionally, merging their tags to
Musicbrainz would be a bit "untidy" (I don't know a better matching word
for that, sorry).
Finally, if one of the services closes (or just limit the access to the
data), the users information are probably lost (or will be much harder
to integrate into a new service) - I have better hopes and believes for
the Musicbrainz service.
> The way that I am thinking of implementing this sort of system is to
> create a website where a user can login to musicbrainz, last.fm
> <http://last.fm> and libre.fm <http://libre.fm> and the website will
> be responsible for sitting in the middle and trying to best match
> scrobbles on last.fm <http://last.fm> with recordings on musicbrainz.
> Once we have the data matched to musicbrainz the task of the
> recommendation engine should be a little easier.
> It should also allow a little more portability and allow someone else
> to build competing recommendation engine but still use my tool as a
> bridge between these services.
I don't think that it would be too difficult to add the necessary
features to the Musicbrainz database.
We would need a user table (which probably exists) with
UserID (an internal database ID)
LoginName (e.g. email address or any other kind of login name)
LoginNameHash (or alike for anonymous access of the user account)
LoginPasswordHash (the users password hash)
UserAllowsAnonymousAccess (provides a flag whether the user allows other
applications/webpages to access his user statistics without specifying
his password, of course read only. There might be discussions whether
his data might be exported as snapshot in any case (which I would
favour), as he need to specify his login credentials on the
application/webpage nevertheless, so that part of the anonymizing has
gone away - while exporting would remove his real login name, so it will
be only statistics).
For scrobbling a new table would be necessary
DateTime (date and time for the scrobbling of the given title)
RecordingID (recording in the Musicbrainz database, best identified
using AcoustID and verified with song tags. Of course if an application
can only provide metadata/tags of a song, because e.g. the (embedded)
platform is not able to create fingerprints fast enough, it should be
possible to match the metadata/tags to the Musicbrainz database using
that information alone).
UserID (for combining the user with the scrobbling).
And I am not sure whether there is already a rating table for the user
(you mentioned one), but it should look like this:
UserID
Rating (from 1-5)
RecordingID (as the user should rate a specific recording of a song)
These information should already be enough to implement scrobbling and
rating (or am I missing something here?).
All these information should be in the core database (of course not
LoginName and LoginPasswordHash, so that the data may be used anonymized
by applications when parsing the data heap), regarding the usage license.
Extending the API would be another topic, of course...
And if thinking further, possibilities to automatically share the users
scrobblings on Twitter/Facebook/etc. should also be a thought for future
development.
> One thing that I want as feature 0 is the ability to export thair data
> and import in thair own instance so if and when my service shuts down
> everyone can run the software on thair own hardware or go to someone
> else that hosts it.
That is also very important to me, therefore I would like to store the
data in the open MusicBrainz database where a snapshot is always
available (and from which the user data can be exported using the
(anonymous) hashed user login information). But automatic matching the
other services data for a given user would be very difficult and
possibly not allowed (at least with last.fm: "You must not sub-license
the Last.fm Data to others").
Please let me know your thoughts on my thoughts ;-)
Robert: No problem, I will be glad for your answer whenever it is
possible to you...
Best regards,
Andre
>
>
>
>
> On Mon, May 4, 2015 at 8:14 PM, Andre Wiethoff
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hello everybody,
>
> I am Andre Wiethoff, the person behind Exact Audio Copy and Easy Audio
> Copy. My interest is mostly in audio and nowadays I also do quite some
> research on personalized music recommender systems.
>
> I came to the conclusion that only collaborative filtering will help
> most for producing good recommendations (for the time being). Even
> though AcousticBrainz produces impressive results, it is not yet up to
> be used exclusively for choosing a good playlist for the user. In my
> opinion, perhaps we will have in 10 years the analysis algorithms that
> are capable of producing results that are exact enough for
> productive use.
>
> It would create great value for the user if an application would
> be able
> to create a playlist for the given user depending on his preferences.
> Not only for streaming, but also using his local music collection. For
> now, the necessary data are all closed source, available only to the
> owning companies (and sometimes available as an API with big
> restrictions what to do with the data - some algorithms couldn't
> even be
> run if the database is not available completely, e.g. doing
> collaborative filtering with self-created algorithm is not
> possible with
> any of the APIs (as far as I know)). Users are submitting their
> information for free and the companies lock them away - there
> should be
> an open source counterpart to stop this closed information handling.
> (And of course such a database would need some lobbying work for the
> larger, commercial player companies like Sonos in order to add
> submission to their players).
>
> As a possible future extension it would be great if such information
> (e.g. scrobbling and, even more important, personal ratings of
> songs for
> each user) could also be stored in MusicBrainz. For that, a unique
> token
> per user need to be created (more or less automatically, should be
> easy
> for the user to create within any end-user application - that
> should be
> unique for all applications that the user uses). Creating such a token
> would be quite difficult when trying to do it the easy way (as
> when such
> a token already exists with one application, the other application
> need
> to retrieve that token without creating one first - this will help
> moving the personal information to a new player). And it should be
> easy
> enough that commercial player software/hardware would also be
> willing to
> implement it. Perhaps the best idea would be still to use
> Username/Password?
> Further, AcoustIDs should be used to unambiguously identify a specific
> song played (other metadata could verify the correctness of the
> assignment). Last.fm does scrobbling by metadata only (as far as I
> know), which might cause conflicts by different versions of a song
> (e.g.
> radio edit, live, etc.).
> Finally, the ratings should reflect various liking levels (I
> propose -2,
> -1, 0, 1, 2 - perhaps best displayed as thumbs up/medium up, etc.), as
> the more songs the user is able to rate, the better will be the
> results
> of the recommendation engine. If just offering thumbs up/down, people
> will not rate songs that are quite ok (and not rating a song should
> provide no (implicit) rating at all, as the user could e.g. let the
> songs play unattended).
>
> Of course at the beginning there will be no software which fills the
> database with information, but I think there need to be a framework
> first before some audio player would integrate the API to provide
> information about the songs a user plays (and hopefully likes or
> dislikes).
>
> Only after the database has been populated quite a bit, the player
> applications will receive something back for the submission of
> information. I would propose that also a baseline recommendation
> engine
> should be implemented in MusicBrainz, which can be called via API.
> Researchers or developers who want to create a better recommendation
> engines would be free to work on the full database and implement their
> own ideas. Of course creating a baseline recommendation engine is
> still
> a huge project, there are some shortcuts which would help creating
> playlists somwhat more easy...
>
> What are your thoughts on this?
>
> Thanks for your time!
>
> Best regards, Andre Wiethoff
>
> PS: I proposed to add AcoustID submission into EAC (submitting the
> fingerprints with each extracted CD together with the DiscID) already
> quite some time ago, directly to one of the developers (don't know
> anymore to whom), but didn't receive any reply. If something like this
> is interesting, please contact me (privately?).
>
>
>
> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> <mailto:[email protected]>
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>
>
>
>
> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
--------------000804090004080805000700
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
Hello Daniel,<br>
<br>
thanks for your reply and your thoughts!<br>
<blockquote
cite=3D"mid:CAAphvGoi=3DXgAfDQZxoY8MneWdffsRzoMNTEyJ6NH+5e77w=3Dzog@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">This is something that I would like to do
eventually but I have not gotten around to starting.
<div>Musicbrainz has user collections, this feature allows
people to add releases to a public or private list.</div>
<div>For the moment this only works for Releases (ie albums) and
events but I believe as part of the shema change on scheduled
for the 18th of May this will be changed to allow for more
types of data to be stored.</div>
</div>
</blockquote>
I haven't found any information/description about the user in the
database scheme description on the homepage.<br>
Of course it would be nice to extend the users that also (quite)
anonymous users with a user token (and a password hash) could login
and store their information with Musicbrainz.<br>
<blockquote
cite=3D"mid:CAAphvGoi=3DXgAfDQZxoY8MneWdffsRzoMNTEyJ6NH+5e77w=3Dzog@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>Musicbrainz also has a rating system that allows people to
submit a number between 1 and 5 for most entries but there is
not a lot of people that use this</div>
</div>
</blockquote>
I also found no information about this on the webpage... I assume
that this data is stored in the derived data database?<br>
If so, we would need to think a about changing the scrobbling and
rating to a different license, as I really would like to see that
data free for any use (otherwise some uses are restricted for some
players). Anyway, it would be a possibility to offer the baseline
web service for recommending songs for free for non-commercial use
and per license for commercial projects...<br>
<blockquote
cite=3D"mid:CAAphvGoi=3DXgAfDQZxoY8MneWdffsRzoMNTEyJ6NH+5e77w=3Dzog@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>One thing missing is collections would not be able to store
play counts so you would need to store that history somewhere
else.</div>
<div>We do not necessarily need to write our own scrobbeling
api, it might be useful to use <a moz-do-not-send=3D"true"
href=3D"http://last.fm">last.fm</a> or <a
moz-do-not-send=3D"true" href=3D"http://libre.fm">libre.fm</a=
></div>
<div>Last.fm has api's so it should be possible to pull or push
information out of there easily.</div>
<div><a moz-do-not-send=3D"true" href=3D"http://libre.fm">libre.f=
m</a>
is open source but it has mostly been dormant for the last few
years.</div>
</div>
</blockquote>
Last.fm has some restrictions. You are able to query the scrobbling
history for a single user, but this would only help for exporting
the data to a different database for a single user (which is not
allowed). Also the usage of last.fm has a special terms of service (
<a class=3D"moz-txt-link-freetext" href=3D"http://www.lastfm.de/api/t=
os">http://www.lastfm.de/api/tos</a>
), e.g. that they "the right to share in revenue generated from your
use of Last.fm Data" or "You must not sub-license the Last.fm Data
to others" or "For more information about how to apply to use the
API and Last.fm Data for commercial purposes..." or "You are
permitted to use the Last.fm Data solely for non-commercial purposes
and for no other purpose and subject always to any limitations or
conditions as advised to You by Last.fm at any time" or "You will
not make more than 5 requests per originating IP address per second,
averaged over a 5 minute period, without prior written consent". I
think that these restrictions are enough for not being able to use
the data in the last.fm database for a collaborate recommendation
engine...<br>
I didn't know of libre.fm, they have a large support community
("Libre.fm is supported by Bytemark, BigV, The Internet Archive and
ISC"). The last commit was from may 2014, so there was no
development for the last year at all. Further I think they have a
kind of closed ecosystem for promoting "open" artists, which can be
played directly from their webpage (sadly there was not much
information about the service itself on their webpage).
Additionally, merging their tags to Musicbrainz would be a bit
"untidy" (I don't know a better matching word for that, sorry).<br>
Finally, if one of the services closes (or just limit the access to
the data), the users information are probably lost (or will be much
harder to integrate into a new service) - I have better hopes and
believes for the Musicbrainz service.<br>
<blockquote
cite=3D"mid:CAAphvGoi=3DXgAfDQZxoY8MneWdffsRzoMNTEyJ6NH+5e77w=3Dzog@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>The way that I am thinking of implementing this sort of
system is to create a website where a user can login to
musicbrainz, <a moz-do-not-send=3D"true" href=3D"http://last.fm=
">last.fm</a>
and <a moz-do-not-send=3D"true" href=3D"http://libre.fm">libre.=
fm</a>
and the website will be responsible for sitting in the middle
and trying to best match scrobbles on <a
moz-do-not-send=3D"true" href=3D"http://last.fm">last.fm</a>
with recordings on musicbrainz.</div>
<div>Once we have the data matched to musicbrainz the task of
the recommendation engine should be a little easier.</div>
<div>It should also allow a little more portability and allow
someone else to build competing recommendation engine but
still use my tool as a bridge between these services.</div>
</div>
</blockquote>
I don't think that it would be too difficult to add the necessary
features to the Musicbrainz database.<br>
<br>
We would need a user table (which probably exists) with<br>
UserID (an internal database ID)<br>
LoginName (e.g. email address or any other kind of login name)<br>
LoginNameHash (or alike for anonymous access of the user account)<br>
LoginPasswordHash (the users password hash)<br>
UserAllowsAnonymousAccess (provides a flag whether the user allows
other applications/webpages to access his user statistics without
specifying his password, of course read only. There might be
discussions whether his data might be exported as snapshot in any
case (which I would favour), as he need to specify his login
credentials on the application/webpage nevertheless, so that part of
the anonymizing has gone away - while exporting would remove his
real login name, so it will be only statistics).<br>
<br>
For scrobbling a new table would be necessary<br>
DateTime (date and time for the scrobbling of the given title)<br>
RecordingID (recording in the Musicbrainz database, best identified
using AcoustID and verified with song tags. Of course if an
application can only provide metadata/tags of a song, because e.g.
the (embedded) platform is not able to create fingerprints fast
enough, it should be possible to match the metadata/tags to the
Musicbrainz database using that information alone).<br>
UserID (for combining the user with the scrobbling).<br>
<br>
And I am not sure whether there is already a rating table for the
user (you mentioned one), but it should look like this:<br>
UserID<br>
Rating (from 1-5)<br>
RecordingID=A0 (as the user should rate a specific recording of a
song)<br>
<br>
These information should already be enough to implement scrobbling
and rating (or am I missing something here?).<br>
All these information should be in the core database (of course not
LoginName and LoginPasswordHash, so that the data may be used
anonymized by applications when parsing the data heap), regarding
the usage license.<br>
<br>
Extending the API would be another topic, of course...<br>
And if thinking further, possibilities to automatically share the
users scrobblings on Twitter/Facebook/etc. should also be a thought
for future development. <br>
<blockquote
cite=3D"mid:CAAphvGoi=3DXgAfDQZxoY8MneWdffsRzoMNTEyJ6NH+5e77w=3Dzog@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div>One thing that I want as feature 0 is the ability to export
thair data and import in thair own instance so if and when my
service shuts down everyone can run the software on thair own
hardware or go to someone else that hosts it.</div>
</div>
</blockquote>
That is also very important to me, therefore I would like to store
the data in the open MusicBrainz database where a snapshot is always
available (and from which the user data can be exported using the
(anonymous) hashed user login information). But automatic matching
the other services data for a given user would be very difficult and
possibly not allowed (at least with last.fm: "You must not
sub-license the Last.fm Data to others").<br>
<br>
Please let me know your thoughts on my thoughts ;-)<br>
<br>
Robert: No problem, I will be glad for your answer whenever it is
possible to you...<br>
<br>
Best regards,<br>
<br>
Andre<br>
<br>
<br>
<blockquote
cite=3D"mid:CAAphvGoi=3DXgAfDQZxoY8MneWdffsRzoMNTEyJ6NH+5e77w=3Dzog@mail.=
gmail.com"
type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<br>
<div><br>
</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Mon, May 4, 2015 at 8:14 PM, Andre
Wiethoff <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]" target=3D"_bla=
nk">[email protected]</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
everybody,<br>
<br>
I am Andre Wiethoff, the person behind Exact Audio Copy and
Easy Audio<br>
Copy. My interest is mostly in audio and nowadays I also do
quite some<br>
research on personalized music recommender systems.<br>
<br>
I came to the conclusion that only collaborative filtering
will help<br>
most for producing good recommendations (for the time
being). Even<br>
though AcousticBrainz produces impressive results, it is not
yet up to<br>
be used exclusively for choosing a good playlist for the
user. In my<br>
opinion, perhaps we will have in 10 years the analysis
algorithms that<br>
are capable of producing results that are exact enough for
productive use.<br>
<br>
It would create great value for the user if an application
would be able<br>
to create a playlist for the given user depending on his
preferences.<br>
Not only for streaming, but also using his local music
collection. For<br>
now, the necessary data are all closed source, available
only to the<br>
owning companies (and sometimes available as an API with big<=
br>
restrictions what to do with the data - some algorithms
couldn't even be<br>
run if the database is not available completely, e.g. doing<b=
r>
collaborative filtering with self-created algorithm is not
possible with<br>
any of the APIs (as far as I know)). Users are submitting
their<br>
information for free and the companies lock them away -
there should be<br>
an open source counterpart to stop this closed information
handling.<br>
(And of course such a database would need some lobbying work
for the<br>
larger, commercial player companies like Sonos in order to
add<br>
submission to their players).<br>
<br>
As a possible future extension it would be great if such
information<br>
(e.g. scrobbling and, even more important, personal ratings
of songs for<br>
each user) could also be stored in MusicBrainz. For that, a
unique token<br>
per user need to be created (more or less automatically,
should be easy<br>
for the user to create within any end-user application -
that should be<br>
unique for all applications that the user uses). Creating
such a token<br>
would be quite difficult when trying to do it the easy way
(as when such<br>
a token already exists with one application, the other
application need<br>
to retrieve that token without creating one first - this
will help<br>
moving the personal information to a new player). And it
should be easy<br>
enough that commercial player software/hardware would also
be willing to<br>
implement it. Perhaps the best idea would be still to use
Username/Password?<br>
Further, AcoustIDs should be used to unambiguously identify
a specific<br>
song played (other metadata could verify the correctness of
the<br>
assignment). Last.fm does scrobbling by metadata only (as
far as I<br>
know), which might cause conflicts by different versions of
a song (e.g.<br>
radio edit, live, etc.).<br>
Finally, the ratings should reflect various liking levels (I
propose -2,<br>
-1, 0, 1, 2 - perhaps best displayed as thumbs up/medium up,
etc.), as<br>
the more songs the user is able to rate, the better will be
the results<br>
of the recommendation engine. If just offering thumbs
up/down, people<br>
will not rate songs that are quite ok (and not rating a song
should<br>
provide no (implicit) rating at all, as the user could e.g.
let the<br>
songs play unattended).<br>
<br>
Of course at the beginning there will be no software which
fills the<br>
database with information, but I think there need to be a
framework<br>
first before some audio player would integrate the API to
provide<br>
information about the songs a user plays (and hopefully
likes or dislikes).<br>
<br>
Only after the database has been populated quite a bit, the
player<br>
applications will receive something back for the submission
of<br>
information. I would propose that also a baseline
recommendation engine<br>
should be implemented in MusicBrainz, which can be called
via API.<br>
Researchers or developers who want to create a better
recommendation<br>
engines would be free to work on the full database and
implement their<br>
own ideas. Of course creating a baseline recommendation
engine is still<br>
a huge project, there are some shortcuts which would help
creating<br>
playlists somwhat more easy...<br>
<br>
What are your thoughts on this?<br>
<br>
Thanks for your time!<br>
<br>
Best regards, Andre Wiethoff<br>
<br>
PS: I proposed to add AcoustID submission into EAC
(submitting the<br>
fingerprints with each extracted CD together with the
DiscID) already<br>
quite some time ago, directly to one of the developers
(don't know<br>
anymore to whom), but didn't receive any reply. If something
like this<br>
is interesting, please contact me (privately?).<br>
<br>
<br>
<br>
_______________________________________________<br>
MusicBrainz-devel mailing list<br>
<a moz-do-not-send=3D"true"
href=3D"mailto:[email protected]">Mus=
[email protected]</a><br>
<a moz-do-not-send=3D"true"
href=3D"http://lists.musicbrainz.org/mailman/listinfo/music=
brainz-devel"
target=3D"_blank">http://lists.musicbrainz.org/mailman/list=
info/musicbrainz-devel</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
MusicBrainz-devel mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:MusicBrainz-devel@li=
sts.musicbrainz.org">[email protected]</a>
<a class=3D"moz-txt-link-freetext" href=3D"http://lists.musicbrainz.org/m=
ailman/listinfo/musicbrainz-devel">http://lists.musicbrainz.org/mailman/l=
istinfo/musicbrainz-devel</a></pre>
</blockquote>
<br>
</body>
</html>
--------------000804090004080805000700--
--===============0593810532==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
MusicBrainz-devel mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
--===============0593810532==--