TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews, Doc sprint (yvanzo), Repo review (reo)
yvanzo: before I start writing it, we don't have any docs for how to add support for a new URL domain to the code, right?
As in, a doc that explains what files to change for autoselect/cleanup, favicons, sidebar, etc
yvanzo
reosarevok: No, we should even probably have a separate doc explaining how to handle those tickets to check current usage in the DB, old and current links on the web…
Like HACKING-URLCLEANUP.md?
reosarevok
Hmm, I was going to put it on HACKING but that also seems good
We can move it to a dev docs repo if we eventually start one
i saw those in RTD tutorial first and thought to add LB docs as well.
alastairp
why do we have "Web root url" in the api docs? I can't see it used anywhere in the docs
lucifer
yeah, i think we can remove that. dosen't make sense to list non-api endpoints there in LB API docs.
mayhem
alastairp: got a sec for some brainstorming?
alastairp
yes, go for it
lucifer
although it could come in handy in dev/maintainer docs
mayhem
let me find a reference real quick. hang on.
alastairp
lucifer: yeah, there may be value in having it somewhere, but it feels a bit out of place right there
lucifer
yup makes sense. i'll remove that in another PR. the current ones depend on each other so making the change here will cause cascading merges/rebases to resolve conflict.
alastairp
no prob
akshaaatt
lucifer, A reminder about the data safety form in playstore 😃
mayhem
meh. can't find the paper that talks about moods derived from listens. but that paper said something along the lines of:
"Extrating moods from audio is hard and doesn't work that well".
*extracting
alastairp
the one I linked last week?
mayhem
yes.
and in general, there is a sentiment that user behaviour is a better input to recommendation that audio files.
A point that Dimi made in this defense.
so, then it seems that AB is really barking up the wrong tree.
not only does it not provide good results, its also very hard to do unless you have access to a huge cache of files. Easy for spotify, very hard for us.
alastairp
yeah, the question of "can you throw machine learning at audio signals and get some results?" has always been uncertain
mayhem
And I think that we fell in love with the concept; we were never fully clear on what data we wanted to collect, and we just got ourselves hornswaggled on this approach. I think it its time to step back even further than we already have and re-examine.
exactly. so, how about we don't. period.
instead, lets us ask ourselves: what data do we want to collect?
once we answer that, we should find ways to collect those pieces of data, by the easiest means possible. meaning: what approaches fit with an open source approach.
alastairp
so, instead of "description of songs based on analysing audio", maybe we actually just want "description of songs"
lucifer
akshaaatt: thanks for the reminder, lets talk with mayhem about that after this conversation.
mayhem
DING! EXACTLY THAY!
THAT
because reading the moods from behaviour paper gives a clear insight. If transferlearning is needed -- well, we have a CF filtering setup already. If we're bolting another piece of on top of that, then this may not be that much work in the grand scheme of things.
right now AB needs: DSP and ML knoweldge.
the new approach only needs ML knowledge. and everyone wants to do this right now -- its the hot thing to be doing.
and we have the infrastructure for it already. so, lets use that.
thanks!
there are bits and pieces of AB that are clearly useful. such as creating datasets, managing them and then throwing them at ML.
newAB could then throw away all the audio stuff and keep all the ML/dataset stuff.
alastairp
yes, right
mayhem
we could start with collecting mood information manually from users as part of BrainzPlayer. (listen to a track, select the mood from a dropdown, submit to newAB.
once we have a body of those, we can start doing the ML as described in the paper. the paper allows us to "fill in the blanks" of the data we're missing.
with me so far?
alastairp
oh, that's interesting
working out how to collect data has always been a bit of an open question
mayhem
and those are our strengths OR are things that are tangibly close to being within our reach.
alastairp
and I think that the AB way of saying "here are some results, do they look wrong? give us feedback" was a bit weak because the data was a bit sparse
mayhem
so, lets focus on that. lets build an OpenML project with a focus on music.
yes, indeed.
alastairp
but maybe integrating into BP might be a better way of getting that data
the previous way that we've done it is give it to students as an assignment. "your task is to listen to these 500 songs from jamendo and categorise genre/mood/other things, then do some analysis on the results"
mayhem
I think BP is the outlier on this front. I think with enough effort, we can do music analysis on it. I think you're close to showing that.
but, just to get BPM, do we really need to build all this infra for it?
what if we wrote BPM stuff as a pluging for picard?
and picard runs 3+ algs and if there is consensus, submit the data.
bam, we're done.
alastairp
how do you mean? people use picard and tap along with the song?
oh, for the algorithms. mmm
one sec, let me commit some stuff
mayhem
yes. since it looks like there are promising algs, lets stuff them into picard and be done on that front.
then focus ML in the newAB and I think we have a project might might get more people interested in helping.
mayhem wonders if lucifer has any ideas
monkey
Are "moods" a specific subset of tags?
lucifer
nothing to add but following along the discussion. +1 on all BP, picard and new AB ideas
monkey
(I've been wanting to add a tags input and display into the ListenCard on LB, perhaps another input can prompt for adding/selecting moods)
zas
legoktm[m]: ping
mayhem
monkey: moods could be tags -- yes, but I think I would build a more general infrastructure to support this in newAB.
The only thing that bugs me about this is that newAB no longer deals with acoustics. thus the name is now borked.
3. If there is not, have the user select the most "salient" parts of the song. and then run analysis again. do we get a stable result now? if so, we're done.
4. If not... not sure. "tap on every downbeat" and we'll calculate it?