#metabrainz

yvanz: ?

Freso: You shared a doc on google drive, I just requested access to it.

yvanz: I sent a link straight to the blog.

There's no reason to look at the Google doc anymore, I've already moved it over.

And it's already scheduled for publication.

armalcolite: we already do ML in acousticbrainz, with SVM

some researchers here are working on deep learning stuff, but one requirement is more data in AB, we're currently working on choosing the best data to compute

Freso: Thanks for the link.

when the contest launches I'll post a link

More data in AB? On it!

oh

Freso: we mean more detailed data for each recording

the stuff we currently have is not detailed enough

deep learning is funny

it mostly throws away the last 20 years of best practises around preprocessing of audio

mayhem: hmm. regarding MBVM-30, you could always map DBDefs.pm into the container using a volume

MBVM-30: Make WEB_SERVER based URLs resolve to relative paths https://tickets.metabrainz.org/browse/MBVM-30

this way, more advanced users can make a change to the config file and restart without having to re-build the image

[musicbrainz-server] y-van-z opened pull request #454: MBS-8168: Add distribution of labels by type to /statistics (master...mbs-8168-label-types-stats) https://git.io/vD8QU

alastairp: Ah. Can't help with that. Yet.

alastairp not detailed enough means all entries have to be resubmitted?

SothoTalKer: Eventually, yes.

woooo

cool

SothoTalKer: yes

(This is one of the reasons I ask/require artists that want me to add their stuff to send my their music in some form, and why I archive CD rips, even if I'm not actually interested in the music.)

that means i have to buy more stuff :-)

oh no... :)

Hi to all, I have a question regarding Musicbrainz api. If I use the 'browse' API feature in order to find all artists related to a given recording, it will give me only the main artisti. However in the web I can see all artists that performed that given recording, and the instrument they played.

example: https://musicbrainz.org/release/0883ead0-94b8-4...

[listenbrainz-server] paramsingh opened pull request #117: Fix another small bug where listen_type was not being detected. (master...listen-type-fix) https://git.io/vD8Nh

this writing tests for the beta idea of mayhem's was pretty good, I'm finding bugs left and right :P

alastairp: oh i wonder how good SVM performs, though i have seen it to provide good results in many use cases. And it has numerous benefits of its own. :D

we find with SVM that our results are quite comparable to the state of the art

for most of the existing datasets which are used in the field

within a few percentage points in cross validation accuracy

however, see our paper about this: http://mtg.upf.edu/node/3498

alastairp: that is just awesome! May be we can try with more complex methods to obtain better results?

of course

part of last year's SoC worked on a framework which will make this easier

and it seems like other people are interested in this too (https://community.metabrainz.org/t/contributing...)

so, we need to work out a way to let people contribute new classifiers in a way that we can 1) evaluate that they're actually better than something simple like svm, and 2) find a way that we can run their code on our servers in a safe way

dabuni: wasn't there something with relationships?

I'm 95% sure that the solution to 2) is docker

no, this is what i get

{ artists: [ { 'gender-id': '36d3d30a-839d-3eda-8cb3-29be4384e4a9', 'sort-name': 'Davis, Miles', 'life-span': [Object], area: [Object], country: 'US', end_area: [Object], 'type-id': 'b6e035f4-3ce9-331c-97df-83397230b0df', disambiguation: 'jazz trumpeter, bandleader, songwriter', gender: 'Male', ipis: [Object], name: 'Miles Davis', type: 'Person',

alastairp: i see, this was what kartik was working on

but why do we need people to submit their own classifiers?

well thanks anyway SothoTalker

dabuni: https://musicbrainz.org/recording/27318ce1-d1dc...

instruments are linked via relationships and I think there was a way to get these with the API

ok, I'll check

thanks!

Anyway, is it possible to scrap directly from the web?

alastairp: I mean writing a full framework for allowing classifier submission and testing just for a small bunch of people who know ML/deep learning, what good would it do ?

even from those small bunch, only a handful would spend time in writing a classifier for AB

....without sending too many requests s

(per second)

armalcolite: yes, this was kartik's project

dabuni: https://musicbrainz.org/doc/Development/JSON_We...

well, if people can build a docker container which has a single program inside which takes an unknown input file and returns a classification

then we can use that to classify incoming submissions to AB

if you add inc=artist-rels it should give you the other information

we've been focusing on the dataset tools, with the assumption that a good quality dataset with SVM will give good results

and we've shown that to be the case

but there is more and more interest in people writing their own custom classifiers

cool , SothoTalker, I'll take a look, Thanks a lot

if it does not work, come back here and complain :D

alastairp: a user currently submits his choice of data for running a ML job specified by us, but what we want is the ability for the users to run the same job on their own systems? (preferably using their own model)

kartik's project was to get users to run our algorithms on their systems (for the training process only)

if someone proposes a new algorithm that works well, it makes sense for us to run it ourselves

so that we're not dependent on a remote system

Freso: sorry for the late reply. should the ticket be modified?

[picard] zas closed pull request #618: Fix 'date' to id3 mapping (master...date-id3-mapping) https://git.io/vDcCP

bitmap: cover art thumbnails aren't displayed on mb.o main page since days now, any update on this issue ?

zas what's the status on 1.4 right now? 14 is final right? And about picard gsoc projects?

samj1912: 1.4 will be released on 14th, then we'll start to work on 1.4.1 (merge current PRs + fixes of 1.4), i think 1.4.1 will be out during next month. GSoC projects will concern Picard 2.0 branch

We'll create this branch after 1.4 release, and backport 1.4.x fixes to it

For 2.0, i want to focus on Py3 / Qt5 port first, before adding new features (apart those added to 1.4.x)

Cool

The qt5 port is almost done

For GSoC i was thinking about UI improvements (redesign)

I think it will take me barely a day for the rest

The sooner is the better ;) We'll still have a lot of tasks for 2.0 as it will imply code rework, and simplification

We also have to introduce a new api point for 2.0 plugins and make the plugins api more concrete

Yes, we need to have better plugin description (and i18n)

And cross platform issues with plugins

Yes, through new metadata headers

Majorly pip dependencies

Yup

I wonder if we could install plugins through pip so we have requirements.txt for each of them

Yup would be nice

But the plugin authors will have to package the plugins for pip

Also we need to provide concrete UI guidelines for plugins that have a UI interface

The last fm plus plugin is a pain to modify because of no UI file

Yes, i think we need an _easy_ way to configure options, perhaps not forcing people to code Qt UI stuff, but instead generating UI from a simple config

Yup

Because from what I can see, most of the UI is similar for similar config options

True

I saw beets plugins

They are maintained nicely from what I saw

But then it's just command line so..

Also zas we need a rewrite for the threading part

I was reading up on Qt applications and background multitasking involving file io

According to guidelines only UI part should run on the main thread

Speaking of Picard, can anyone help this user? :) https://community.metabrainz.org/t/renaming-fil...

samj1912: you can start to create tickets targetting 2.0, so we can discuss stuff there

reosarevok: Hey ;) I will let someone do it, i don't know much about this obscure scripting language ;) phw usually handles those questions with elegance

samj1912: yes, i read same things, basically main thread = UI, intensive subtasks = new threads, but with save/load threads it is more or less where we go, isn't it ?

zas but the process events thing implemented by Sophist doesn't exactly scale well according to qt docs

zas: Fair enough :)

bitmap: ping me when online, for email stuff, i think the best would be to switch from current port to another one, on mb server side, not sure if it is easy or not to do it. Else i will stop current container and replace it on the same port by new one, but it is more complicated and unsafe concerning mail messages/queues

Qtconcurrent and qtimer provide alternatives

Plus the current threading implementation of loading also involves gui updates which sometimes cause the gui to get unresponsive

samj1912: yes, we can rethink the whole threading stuff for 2.0, i think it is very needed, as 1.4 in this domain is more a pile of hacks than anything ;)

Yeah :p

We can discuss on whether we want to have the loading in a separate thread because it causes ctrl c in command line to get unresponsive until the loading is complete

We can add a simple exit signal to solve it however

Also regarding https://github.com/metabrainz/picard/pull/604, adding QtCore.QCoreApplication.processEvents() calls everywhere doesn't look the good way to solve such issue

I think Py3 + Qt5 will give us more possibilities (and also Qt4 has many bugs we had to workaround...)

Plus having proper threading implementation might allow picard to expand from an album based tagger to a more singles oriented tag corrector (which a lot of normal people generally use taggers for)

We can discuss more on this

Yes, qt5 is definitely needed to proceed

That will also solve a couple of ws issues I believe

And encoding/decoding issues...

The whole unicode drama

It's entirely tiring at times :p