We are putting together a sub-set of musicbrainz which mimics the (now basically defunct sigh) Echo Nest in terms of schema & data structure. One thing we where hoping you could help with is the calculation for the valence & energy properties. As far as we can tell these are based on segment duration & loudness with valance using energy as a factor. Anyone have any ideas about the calculation/algo that the ECN guys used in the context of the available AcousticBrainz data?
Our plan is to open up this work as both an open source project (with the generation tools for creating the set and importing it to MongoDB & ElasticSearch) and as a publicly available API (with a clean, human-readable JSON response type).
We don’t know how the Echo Nest arousal/valence is implemented. To my knowledge this values can be obtained from low-level descriptors by training a regression model given examples of music with low-vs-high arousal and low-vs-high valence. Some approaches are mentioned here (see page 26, chapter 2, “Dimensional regression”). This is something we can do in AcousticBrainz, if we create datasets for arousal and valence.
I guess one solution to this would be to take Echonest entries (while it’s still there) with low / high Arousal values and cross look up those entries into AcousticBrainz and then build the model off of that?
Would a Musicbrainz based dataset which combines acoustic data and situational tags (in order to allow contextual queries) be something that the Musicbrainz crew would be willing to work with us on?
I’m not sure exactly what you’re asking here, but any MusicBrainz user can add any folksonomy tags they want to any entity. This could, for example, be a tag like “en-energy=31.446”…
Well i’m glad that the community at large can contribute to the process in that way but what i’m talking about is a more concerted technical effort to do this algorithmically and then programmatically.
As I mentioned in my initial post we are looking to fill the void left by the Echonest and put its safekeeping in community hands so it can be depended upon for all those who need it without fear of it being pulled from under us.
I think you misunderstand me. There’s nothing stopping you - or a bot you write - from submitting these tags - you can even do that programmatically. So you could also have a bot account scrape Echo Nest and submit those two values as folksonomy tags (though I’m not sure of the legality of that, so maybe don’t - but if you run a local instance of MB and do it to that, hey, go for it) which you could then use to do an AB training against.
Hey Freso, Ah nice to know there is a programmatic way of adding tags to Musicbrainz. Pulling the data from the Echonest was our initial plan, we began the process but did some ‘back of the smoke packet’ calculations and realised that because their API keys are heavily rate limited (even our commercial key) it would take 130 days of solid run-time to get all the required data from the Echonest (Which is going dark on the 31st of May, so that wont work). Hence why we are trying to figure out the algorithmic approach used to generate the data for ourselves.
I’ll keep thinking of a solution to this issue but if anyone has any suggested approaches i’d really appreciate your input that 31st May cut off fast approaches!
that 31st May cut off fast approaches!