Re: Possible Future Extensions

--===============1917347752==
Content-Type: multipart/alternative; boundary=f46d043893c5452d6305155da549

--f46d043893c5452d6305155da549
Content-Type: text/plain; charset=UTF-8

Hello Andre,

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.

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

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 or libre.fm
Last.fm has api's so it should be possible to pull or push information out
of there easily.
libre.fm is open source but it has mostly been dormant for the last few
years.

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 and libre.fm and
the website will be responsible for sitting in the middle and trying to
best match scrobbles on 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.
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.

Anyway happy to hear your thoughts.

Regards,

Daniel


On Mon, May 4, 2015 at 8:14 PM, Andre Wiethoff <[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]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>

--f46d043893c5452d6305155da549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Andre,<div><br></div><div>This is something that I w=
ould like to do eventually but I have not gotten around to starting.</div><=
div><br></div><div>Musicbrainz has user collections, this feature allows pe=
ople 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 o=
f 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><br></div><div>Musicb=
rainz also has a rating system that allows people to submit a number betwee=
n 1 and 5 for most entries but there is not a lot of people that use this</=
div><div><br></div><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><br></div><div>We do not necessarily need to write our own scro=
bbeling api, it might be useful to use <a href=3D"http://last.fm">last.fm</=
a> or <a href=3D"http://libre.fm">libre.fm</a></div><div>Last.fm has api&#3=
9;s so it should be possible to pull or push information out of there easil=
y.</div><div><a href=3D"http://libre.fm">libre.fm</a> is open source but it=
 has mostly been dormant for the last few years.</div><div><br></div><div>T=
he way that I am thinking of implementing this sort of system is to create =
a website where a user can login to musicbrainz, <a href=3D"http://last.fm"=
>last.fm</a> and <a href=3D"http://libre.fm">libre.fm</a> and the website w=
ill be responsible for sitting in the middle and trying to best match scrob=
bles on <a href=3D"http://last.fm">last.fm</a> with recordings on musicbrai=
nz.</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 a=
llow a little more portability and allow someone else to build competing re=
commendation engine but still use my tool as a bridge between these service=
s.</div><div>One thing that I want as feature 0 is the ability to export th=
air data and import in thair own instance so if and when my service shuts d=
own everyone can run the software on thair own hardware or go to someone el=
se that hosts it.</div><div><br></div><div>Anyway happy to hear your though=
ts.</div><div><br></div><div>Regards,</div><div><br></div><div>Daniel</div>=
<div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, May 4, 2015 at 8:14 PM, Andre Wiethoff <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email protected]" target=3D"_blank">brainworks@=
exactaudiocopy.de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">H=
ello 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&#39;t even b=
e<br>
run if the database is not available completely, e.g. doing<br>
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&#39;t know<br>
anymore to whom), but didn&#39;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 href=3D"mailto:[email protected]">MusicBrainz-deve=
[email protected]</a><br>
<a href=3D"http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel"=
 target=3D"_blank">http://lists.musicbrainz.org/mailman/listinfo/musicbrain=
z-devel</a><br>
</blockquote></div><br></div>

--f46d043893c5452d6305155da549--


--===============1917347752==
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
--===============1917347752==--