What do 650,000 audio files look like, anyway?

Hot on the heels of our release of the first 650,000 feature files as part of the first release of AcousticBrainz, we are presenting some initial findings based on this dataset.

We thank Emilia Gómez (@emiliagogu), an Associate Professor and Senior Researcher at the Music Technology Group at Universitat Pompeu Fabra for doing this analysis and sharing her results with us. All of these results are based on data automatically computed by our Essentia audio analysis system. Nothing was decided by people. Isn’t that cool?

The MTG recently started the AcousticBrainz http://acousticbrainz.org/ project, in collaboration with MusicBrainz.  Data collection started on September 10th, 2014, and since then a total of 656,471 tracks (488,658 unique ones) have been described with essentia. I have been working for a while with audio descriptors and I followed the porting some of my algorithms to essentia, especially chroma features and key estimation. For that reason, I was curious to get a look this data. I present here some basic statistics. I computed them with the SPSS statistical software.

WHICH KIND OF MUSICAL GENRES DO WE HAVE IN THE COLLECTION?

In order to characterize this dataset, I first thought about genre. In essentia, there are four different genre models: trained on the data by Tzanetakis (2001), another one compiled at the MTG (Rosamerica), Dortmund and a database of Electronic music. Far from providing information on the kind of musical genres, these models seem to be contradictory! For example, in the Tzanetakis dataset “jazz” seems to be the most estimated genre, while the proportion of jazz excerpts is very small in the other models.

Genre estimations using the Tzanetakis dataset
Genre estimations using the Tzanetakis dataset
Genre estimations using the Rosamerica dataset
Genre estimations using the Rosamerica dataset
Genre estimations using the Dortmund dataset
Genre estimations using the Dortmund dataset
Genre estimations using the Electronic dataset
Genre estimations using the Electronic dataset

So in conclusion, we have a lot of jazz (according to the Tzanetakis dataset), electronic music (according to the Dortmund dataset), ambient (according to electronic dataset) and an equal distribution of all generes Rosamerica dataset (which does not include a category for electronic music)….Not very clarifying then! This is definitely something that we will be looking at in more depth.

WHAT ABOUT MOOD THEN?

For Mood characterization, 5 different binary models were trained and computed on the dataset. We observe that there is a larger proportion of non-­acoustic music, non-aggressive, and electronic. It is nice to see that most of the music is not happy and not sad! From this and previous study, I would then conclude that there is a tendency in the AcousticBrazinz dataset for electronic music.

Distribution of accoustic and non-accoustic (e.g. electronic) music
Distribution of accoustic and non-accoustic (e.g. electronic) music
How aggressive our dataset is
How aggressive our dataset is

The amount of electronic music

The amount of electronic music (compare with the acoustic graph above)

...and if the music is happy or not
…and if the music is happy or not

If we check for genre vs mood interactions, there are some interesting findings. We find that Classical is the most acoustic genre and rock is the least acoustic genre (due to its inclusion of electronic instruments):

How much music in each genre is accoustic or not
How much music in each genre is accoustic or not

HOW IS KEY ESTIMATION WORKING?

From a global statistical analysis, we observe that major and minor modes are both represented, and that the most frequent key is F minor / Ab Major or F# minor / A Major. This seems a little strange; A major and E major are very frequent keys in rock music. Maybe there are some issues with this data that need to be looked at.

The keys and modes of the tracks in the database
The keys and modes of the tracks in the database

IS THERE A LINK BETWEEN FEATURES AND GENRE?

I wanted to do some plots on acoustic features vs genres. For example, we observe a small loudness level for classical (cla) music and jazz (jaz), and a high one for dance (dan), hip hop (hip), pop, and rock (roc).

The loudness of songs by genre
The loudness of songs by genre

Finally, it is nice to see the relation between equal-­tempered deviation and musical genre. This descriptor measures the deviation of spectral peaks with respect to equal-­tempered tuning. It’s a very low-­level feature but it seems to be related to genre. It is lower for classical music than for other musical genres.

Variation from equal‐tempered tuning per genre
Variation from equal‐tempered tuning per genre

We also observe that for electronic music, equal tempered deviation is higher than for non-­electronic music/acoustic music. What does this mean? In simple terms, it seems that electronic music tends to ignore the rules of what it means to be “in tune” more than what we might term “more traditional” music.

Variation from equal­‐tempered tuning for songs reported as electronic/non-electronic
Variation from equal­‐tempered tuning for songs reported as electronic/non-electronic

IS THERE A LINK BETWEEN FEATURES AND YEAR?

I was curious to check for historical evolution in some acoustic features. Here are some nice plots on the evolution of number of pieces per year, and some of the most relevant acoustic features. We first observe that most of the pieces belong to the period from 1990’s to nowadays. This may be an artifact of the people who have submitted data to AcousticBrainz, and also of the data that we find in MusicBrainz. We hope that this distribution will spread out as we get more and more tracks.

Distribution of release year for the dataset. 0 represents an unknown year
Distribution of release year for the dataset. 0 represents an unknown year

There does not seem to be a large change of acoustic features as year changes. This is definitely something to look into further to see if any of the changes are statistically significant.

Are the loudness wars true? Can you see a trend?
Are the loudness wars true? Can you see a trend?
Is music getting faster? It doesn't seem so
Is music getting faster? It doesn’t look like it
Songs aren't geting more complex
Songs aren’t geting more complex

We have many more ideas of ways to look at this data, and hope that it will show us some interesting things that we may not have guessed from just listening to it. If you would like to see any other statistics, please let us know! You can download the whole dataset to perform your own analysis at http://acousticbrainz.org/download

Announcing the AcousticBrainz project

MetaBrainz and the Music Technology Group at Universitat Pompeu Fabra are pleased to announce the first public release of the AcousticBrainz project.

http://acousticbrainz.org/

What is AcousticBrainz?
The AcousticBrainz project aims to crowd source acoustic information for all of the music in the world and make it available to the public. The goal of AcousticBrainz is to provide music technology researchers and open source hackers with a massive database of information about music.

AcousticBrainz uses a state of the art research project called Essentia (http://essentia.upf.edu/), developed over the last 10 years at the Music Technology Group.

Data generated from processing audio files with Essentia is collected by the AcousticBrainz project and made available to the public under the CC0 license (public domain). In 6 weeks since its inception, AcousticBrainz contributors have already submitted data for 650,000 audio tracks using pre-release software.

Today we are releasing client programs to submit data to the AcousticBrainz server and our first public release containing audio features for over 650,000 audio files.

What data does it have?
AcousticBrainz contains information called audio features. This acoustic information describes the acoustic characteristics of music and includes low-level spectral information such as tempo, and additional high level descriptors for genres, moods, keys, scales and much more. These features are explained in more detail at http://acousticbrainz.org/sample-data

How can I get it?
You can access AcousticBrainz data via our API. See details at http://acousticbrainz.org/api
We also provide downloadable dumps of the whole dataset. You can download it (all 13 gigabytes!) at http://acousticbrainz.org/download

What can I do with it?
We hope that this database will spur the development of new music technology research and allow music hackers to create new and interesting recommendation and music discovery engines. Here are some ideas of things we would like to see:

  • Music discovery
  • Playlist generation
  • Improving the state of the art in genre recognition
  • Analytics on the musical structure of popular music
  • and more!

This is one of the largest datasets of this kind available for research, and the only one of this size that we know of which contains both freely available data as well as the reference source code used to compute the data.

How can I contribute?
If you are a music researcher, you can help us by contributing to the essentia project. Go to the essentia homepage to see how you can do this. If you do something cool with the data let us know. We’d like to start a “made with AcousticBrainz” page where we will showcase interesting projects.

If you have any audio files, we would love for you to contribute audio features to our project. You can do this by downloading our submission clients from http://acousticbrainz.org/download. We provide clients for Windows, Mac, and Linux.

If you find any bugs or errors in the AcousticBrainz stack please let us know! Report issues to http://tickets.musicbrainz.org/browse/AB.

We can’t wait to see what kind of things you will make with our data.

The AcousticBrainz team.

Schema change update, 2014-11-17

We’re back with the schema change release, as promised! We only have a small collection of tickets, but several big things:

  • Pre-gap tracks and data tracks for CDs (where neither contribute to the discid, and pre-gap tracks have position of 0)
  • Collections can now be marked with types such as “owned” and “wishlist”, plus some special new types mentioned below.
  • CDStub data is now replicated.
  • All entities (except URLs) should now support tagging, as areas, instruments, and series were made taggable.
  • Events! And, additionally, event collections. All (non-deleted) users should have had an “Attending” and a “Maybe Attending” collection created, with the corresponding collection types.

Upgrade instructions will come in another blog post, though they should be substantially unchanged from past releases. Specifically, we’d like to confirm everything’s working correctly with a specific git commit, and make a new tag, before we post a recommendation, since there’s already been some problems discovered. Some slacker must not have tested this carefully enough (author whistles in an innocent-sounding fashion).

The git commit for this release (sans small fixes that have happened since release earlier today and any others that may need fixing) is v-2014-11-17-schema-change.

Bug

  • [MBS-7638] – CreateIndexes for instruments wrongly looks at label tables

Improvement

  • [MBS-967] – Support for hidden pre-gap tracks
  • [MBS-1059] – Types of list/collection
  • [MBS-7551] – Add folksonomy tag support to areas, instruments, and series
  • [MBS-7784] – Support for data tracks in tracklists

New Feature

Task

  • [MBS-7883] – Make sure delete_unused_url doesn’t remove URLs used in edits

Announcing libmusicbrainz release 5.1.0

I have released a new version of libmusicbrainz. The main changes in this release are the removal of ‘non-free’ XML parsing code, replacing it with libxml2. N.B. Due to the ABI change, the soname of this library has been bumped. Existing applications will need to be recompiled against the new version. The following are the main changes in this release:

  • Fix LMB-33 – Handle ‘ended’ element in ‘relation’
  • Fix LMB-34 – Remove non-free XML parser and replace with libxml2
  • Add support for cross-compilation and building out of tree

The release is available here: libmusicbrainz-5.1.0.tar.gz (MD5 checksum: 4cc5556aa40ff7ab8f8cb83965535bc3) Documentation for the new version is available under http://metabrainz.github.com/libmusicbrainz/

Downtime for fall schema change

Our next schema change version will be released on Monday, 17 November, 2014 around Noon PST/3pm EST/20:00 GMT/21:00 CET. We expect that MusicBrainz will be unavailable for 30 – 60 minutes during this time. We will put up the downtime notification on the site and tweet from @musicbrainz right before the release.

Sadly, our backup database server suffered a hardware failure and we ran out of time to get a replicated database setup after the hardware was fixed. This means that we won’t be able to put the site into read-only mode and will require us to take a full-downtime.

It sucks and we’re not happy about it either, but there is only so much we can accomplish with our limited resources. 🙁

Sorry for any troubles this may cause you.

Style update, 2014-11-03

As mentioned when the new style process was announced, at a similar time to every server release post we’ll be publishing a list of what’s changed in style during that period.

The first period of two weeks (or three, in this case) under the process has passed, and these are all the style-related issues that have been accepted and implemented during it. Most of them are very small (mostly adding sites to the whitelist for the Other Databases relationship) although a couple are new relationships or relationships being extended to more entities.

No changes to the guidelines themselves have happened during this period.

  • [STYLE-211] – Allow new allmusic.com release links
  • [STYLE-250] – Add finnmusic.net to the other databases whitelist
  • [STYLE-251] – Add pomus.net to whitelist
  • [STYLE-256] – Add fono.fi to the other databases whitelist
  • [STYLE-269] – Add mixing and mastering to area relationships
  • [STYLE-307] – グラスレ(grass thread/yunisan) as Artist and Label “Other DB” relationship
  • [STYLE-308] – ジャパメタ(japameta) as Artist “Other DB” relationship
  • [STYLE-312] – Add “Deutsche Nationalbibliothek” to whitelist for other databases
  • [STYLE-328] – Add leader/concertmaster artist-release/recording relationships
  • [STYLE-337] – Add IMSLP relationship to artists
  • [STYLE-338] – Add Stage48 Wiki to the other databases whitelist
  • [STYLE-339] – Add CiNii to the other databases whitelist
  • [STYLE-340] – Add NDL to the other databases whitelist

Server update, 2014-11-03

This release was pushed back a week due to scheduling around the GSoC summit and upcoming schema change release, but here it finally is. Editors can take note that more edit types are now auto-edits: adding recording-work relationships, adding/editing aliases, setting track durations, and editing cover artwork. We’ve also added a “Make all edits votable” checkbox to allow edits that are normally always applied automatically (like capitalization changes) to be left open for voting if there’s any dispute or uncertainty. Auto-editors should be aware that this checkbox replaces the one that previously toggled their auto-editor privileges (so it should be left unchecked wherever it was previously left checked).

As part of this release, we’ve deployed some changes that should hopefully prevent slow /ws/2 searches from tying up too many perl processes on our frontends. This may reduce the number of 502s we’ve been seeing lately, but it’s a bit early to pronounce any results. Thanks go to kepstin for suggesting the nginx trickery used here.

More thanks go to chirlu, nikki, and ianmcorvidae for their hard work on today’s release.

The git tag is v-2014-11-03 and the full changelog is below.

Bug

  • [MBS-1444] – Make ‘i’ <-> ‘ı’ an auto-edit.
  • [MBS-5961] – BC dates in search results are parsed incorrectly
  • [MBS-6545] – Medium added without tracknumbers magically gains them
  • [MBS-7399] – Can’t link to TheSession.org’s artist pages
  • [MBS-7927] – Text strings on fingerprints tab are not correctly escaped
  • [MBS-7935] – Can’t add URL examples to relationship documentation
  • [MBS-7938] – Track parser resets track artists to the release artist when “lines contain track artists” is unchecked
  • [MBS-7960] – The link to the mailing lists doc page in the menu doesn’t work
  • [MBS-7961] – Wikidocs redirects are broken
  • [MBS-7962] – Links on /doc/ pages are no longer converted

Improvement

  • [MBS-1479] – Make it possible to leave a capitalization-diacritics edit open
  • [MBS-6011] – Strip out LRM/RLM characters in text with no RTL characters
  • [MBS-7880] – Release editor should have options to copy only titles or only artists to recordings, instead of always both
  • [MBS-7902] – Use nginx X-Accel-Redirect to handle Webservice search requests rather than doing it in perl
  • [MBS-7934] – Add IMSLP autoselect for artists
  • [MBS-7944] – Make recording-work add relationship edits auto-edits
  • [MBS-7945] – Make add/edit alias edits auto-edits
  • [MBS-7946] – Make set track duration edits auto-edits
  • [MBS-7947] – Make edit cover art edits auto-edits
  • [MBS-7953] – Extend normalise_strings to cover more punctuation

Task

  • [MBS-7939] – Add autoselect and validation for release-level Allmusic
  • [MBS-7942] – Add a bunch of sites to the whitelist for dbs

MusicBrainz main site downtime

On October 30, 2014 at 2pm Pacific Time (5pm Eastern, 21:00 UK/GMT, 22:00 CET) we’re going to upgrade the RAM in our database server. This means that we’ll have a complete site-wide outage for about 15 minutes.

We’ll tweet details from @musicbrainz as the time approaches and we’ll have a notice on the site shortly before the down time.

Sorry for the inconvenience.

Picard 1.3 released

Version 1.3 of Picard has been released today, with some notable features and bug fixes.

This release has few visible changes, but overall performance and stability were much improved. A lot of minor annoying issues were fixed. Cover art code was reworked, and notably one can now enable fallback on release group cover art if no cover art exists for a specific release.

Logging was improved, user can now enable debug mode from About →View Error/Debug Log, it may help to see what is going on if needed, passwords and sensible information were hidden from the log, so user can now safely post his log to get help.

To report any issue concerning this release, please use our bug tracker. As usual you can also get help on forum or on IRC (freenode, #musicbrainz).

Special thanks to Sophist, Wieland Hoffmann, Michael Wiencek, Johannes Dewender, Lukáš Lalinský, Frederik “Freso” S. Olesen, and the whole MusicBrainz Team.
Many thanks to all users, developers, bug reporters and translators. Code contributions since 1.2 are visible on Github Contributors graph.

Unfortunately the OAuth support patch (PICARD-305) didn’t make it in this release.

Picard 1.3 can be downloaded on the Picard’s website.

Be aware that downgrading from 1.3 to 1.2 may lead to configuration compatibility issues, better save your configuration before installing 1.3 if you intent to go back to 1.2.

Among changes since 1.2:

  • The “About” window now displays the versions of libraries used by Picard
  • Picard now correctly handles matching of MP3 files saved in ID3v2.3 tags (which is the version that Microsoft Windows and iTunes both use).
    Note: You may need to re-save your tags once to get them to match in future.
  • A sort tags plugin is now provided as tag data is no longer displayed sorted by default.
  • A new tag, musicbrainz_releasetrackid, containing the MusicBrainz Track MBID introduced in the May 2013 schema change release, is now written to files.
  • Add %_recordingtitle% (PICARD-515)
  • Fix plugin install bugs (PICARD-444)
  • Fix Options → File naming examples to handle primary/secondary release types (PICARD-516)
  • A new advanced option is available to permanently set the starting directory for the file browser and “Add files/folder” buttons.
  • Requests to Musicbrainz against your own account e.g. for collections are now handled through SSL (PICARD-337)
  • Refresh of Albums using Ctrl-R and selection of Other Releases are now more responsive during batch lookups.
  • Main window is now emitting a “selection_updated” signal, plugin api version bumps to 1.3.0
  • Append system information to user-agent string
  • Compilation tag/variable functionality (for tagging & file naming) has been split into two:
    %compilation% is now aligned with iTunes, and set only for Various Artists type compilations
    %_multiartist% variable now indicates whether this release has tracks by multiple artists
    (in order to prepend the artist name to the filename as shown in the default file naming script)
  • autodetect the CD drive on Mac OS X (PICARD-123)
  • Ignore directories and files while indexing when show_hidden_files option is set to False (PICARD-528)
  • Add ignore_regex option which allows one to ignore matching paths, can be set in Options → Advanced (PICARD-528)
  • Added an “artists” multi-value tag to track metadata, based on the one in Jaikoz, which contains the individual artist names from the artist credit. Also useful in scripts (joining phrases like ‘feat:’ are omitted) and plugins.
  • Added “_artists_sort“, “_albumartists“, “_albumartists_sort” variables for scripts and plugins.
  • Made Picard use the country names also used on the MusicBrainz website (PICARD-205)
  • New setup.py command `get_po_files` (Retrieve po files from transifex)
  • New setup.py command `regen_pot_file` (Regenerate po/picard.pot)
  • New Work tag (which for Classical music is often different from the track title) saved as ID3 TOAL tag.
  • New Composer Sort Order tag (variable %composersort%).
  • Improve the Other Releases list to prioritise and separate releases which match the correct number of tracks and your Options → Metadata → Prefered Releases settings for Country and Format.
  • New %_absolutetracknumber% variable numbering tracks sequentially regardless of disc structure (so you can numbers tracks on multi-disc releases without a disc number)
  • Support dropping image directly from Google image results to cover art box
  • Add %_musicbrainz_tracknumber% to hold track # as shown on MusicBrainz release web-page e.g. vinyl/cassette style A1, A2, B1, B2
  • Show the ID3 version of the file in the Info… dialog (Ctrl-I) (PICARD-218)
  • Fixed a bug where Picard crashed if a MP3 file had malformed TRCK or TPOS tags (PICARD-112)
  • Add –files option to setup.py build_ui, used to force .ui to .py regeneration (PICARD-566)
  • New setup.py command `update_constants` (Regenerate countries.py and attributes.py)
  • Made Picard use release groups, medium formats and cover art types also used on the MusicBrainz website
  • Use MusicBrainz Server translations for release groups, medium formats and cover art types
  • Add checkbox to toggle debug at runtime in log/debug view dialog
  • Add a plugin to add Artist Official Homepage relationships to the website tag (ID3 WOAR tag)
  • Add integrated functions $eq_any, $ne_all, $eq_all, $ne_any, $swapprefix and $delprefix.
  • Add %_performance_attributes%, containing performance attributes for the work e.g. live, cover, medley etc.
  • Use $inmulti in file naming scripts i.e. …$if($inmulti(%_performance_attributes%,medley), (Medley),)
  • Add optional `priority` parameter to `register_album_metadata_processor()` and `register_track_metadata_processor()`
    Default priority is `PluginPriority.NORMAL`, plugins registered with `PluginPriority.HIGH` will be run first, plugins registered with `PluginPriority.LOW` will run last
  • Add Standardise Performers plugin to convert e.g. Performer [piano and guitar] into
    Performer [piano] and Performer [guitar].
  • Add support for release group cover art fallback (PICARD-418, PICARD-53)
  • Add a clear button to search box
  • Honour preferred release formats when matching AcoustIds (PICARD-631)
  • Prevent ZeroDivisionError in some rare cases (PICARD-630)

Changes to our style process

At the MusicBrainz Summit last month in Copenhagen, one of the topics to
be discussed was the state of the style guidelines and style process.
One thing those present agreed on was that the process was in need of
reform, for several reasons: the complexity of the process,
inconsistency with other processes in the project, the high level of
individual commitment required to make changes, long-running discussions
without conclusion or followthrough, and ultimately the state of the
final product, the style guidelines themselves. The inaccessibility of
our existing process meant that many users, both new and old, avoided
the style process, and this hurts the project: style is part of what
makes MusicBrainz what it is, and low participation means our guidelines
have grown both internally inconsistent and out of sync with community
practice. Nor is the style process a new problem for MusicBrainz:
historically, it’s changed several times and some past style leaders
have vanished into thin air.  After all, it is a hard job, for a
volunteer, to convince many voices to come to a consensus.

To improve upon these issues, we’ve decided to make two major changes.

First: to designate our JIRA issue tracker at tickets.musicbrainz.org as
the central coordination point for style issues. This way, any issue, be
it style-related or code-related, is reported and discussed in the same
place (and should an issue be misfiled, it’s easily corrected). The
issue tracker can also collect links to other discussions, in edit
notes, the forums, IRC, etc., and store links to related issues such as
features in need of implementation.

Second: to promote our current Style Leader to Style Benevolent Dictator
For Life (Style BDFL). Nicolás Tamargo (reosarevok) will then be in
charge of considering tickets and implementing changes in the style
guidelines. This change shifts the burden of evaluating style issues
from the community to our newly appointed BDFL. For simple changes and
for simple improvements to consistency and writing style, the BDFL can
change things directly, without need for lengthy discussion. Of course,
his work won’t happen in a vacuum: for changes that are complex or
contentious, the role of the BDFL will be to gather feedback and
determine the next steps before making changes. To this end, he may
occasionally call for a non-binding vote on a particular topic, to
collect a snapshot of community opinion to augment existing discussion,
all in order to make a better informed decision.

We hope that this new process will make contribution to the creation of
style guidelines easier and less onerous a commitment for everyone, and
that the resulting style guidelines will be more up-to-date, more
consistent, and more clearly written and organized. To test it out,
we’re going to try this process for 6 months, and then review how things
have progressed and if the process needs further tweaking or even
complete replacement.