Difference between revisions of "User:Jacobbrett/Recordings"

From MusicBrainz Wiki
Jump to navigationJump to search
Line 29: Line 29:
=== The Schema ===
=== The Schema ===


[[File:Schema.png]]
[Diagram here]


==== Recordings ====
==== Recordings ====

Revision as of 08:26, 7 January 2013

This article is in the process of being written and refined. It is heavily inspired by the thoughts of many others on this matter.

The Big Questions

What do consumers want?

I think the average person would only care to differentiate mixes of a recording, if at all; that is, mono vs. stereo, remix vs. album edit vs. radio edit. This large group may include systematic users of MusicBrainz, such as BBC Music.

What do nerds want?

Some nerds want to be able to identify audio down to the bit-level; that is, accessing dynamic range information for a piece of audio (e.g., a track on a CD); viewing a waveform representation of said audio; a hash of the (digital) audio, for lookup purposes.

Otherwise, some nerds want to be able to discern different masters of particular mixes--perhaps a 1970s master vs. a clipped 2000s master or a 2000s master with far less dynamic range. Not at the anal bit-level mentioned above, but close enough.

Why should we care about the nerds?

I think such granularity is required if MusicBrainz desires to have the most quality database of unambiguous information, in fact it should be the absolute destination for music metadata; any extraneous "nerd" data should be able to be ignored if so desired by the common user--this should be reflected in the schema, web-services and most importantly the user interface.

We need only see point two of MusicBrainz's aims to recognise these long-term requirements:

MusicBrainz aims to be: The universal lingua franca for music by providing a reliable and unambiguous form of music identification, enabling both people and machines to have meaningful conversations about music.

A Potential Solution

Here is one solution I've devised that I hope would cover practical use-cases mentioned above and more. I think the solution implemented must be the best starting point for additional features into the future, so that we're not stuck redefining and reimplementing existing features to suit. It's especially important to get these features correct sooner rather than later to limit corruption of data quality as the database grows exponentially.

Obviously, much work would need to be done on use-case and interface testing.

The Schema

Schema.png

Recordings

Calculating nominal length

Mixes

How can one identify a mix?

Masters

When to differentiate masters?

gain

extra silence at beginning/end

0-1 seconds extra audio at beginning/end

Tracks

The User Interface

Catch-alls

Extras

Acoustids

Track entity features

Waveforms

Dynamic Range calculation

Length calculation (strip silence)