User:Kepstin/Ideas:DR14 Meter

From MusicBrainz Wiki
< User:Kepstin
Revision as of 18:03, 11 September 2012 by Hawke (talk | contribs) (Implementation Thoughts)

Similar to how Acoustids are currently handled, it would be nice to have an external database linking to musicbrainz that adds support for storing Pleasurize Music Foundation-compatible dynamic range values.

Implementation Thoughts is a free, open-source (GPLv3) command line tool for calculating dr14 values. It could be hooked up with a picard plugin to allow submission and tagging. THis picard plugin could also make them available as internal tags (_release_dr14, _track_dr14)

I don't know if picard supports adding much in the way of UI elements via plugins -- right-click menu may be all. Ideally we hook this into the 'Scan' button so it requires as much/little thinking as acoustid does at present, I think. Ianmcorvidae 23:37, 22 August 2012 (UTC)
Another tool, seems to be less actively maintained, does ~the same thing, and is written in C: --Hawke
That one might be a better choice for performance reasons if nothing else; it seems to be much much faster. —Hawke (talk)

The tool needs to be modified to allow passing in a list of filenames on the commandline [ It can now accept a list of files on stdin.Hawke], and make sure it can output to stdout in text format. [It does, via the -p option. —Hawke

Site must have an API to allow lookups by release mbid. Submissions would be by api key, probably with musicbrainz authentication (like acoustid). How to handle multiple varying submissions for one release? I like medians. [Median could result in a decimal DR value, though this is unlikely.Hawke] Filtering out bad submissions might be an issue.

If we're writing our own DB or extending the one arbitrarily, we could link to acoustid fingerprints as well (fingerprints, not IDs, note); this won't necessarily help but it at least provides more data by which to find incorrect submissions. Ianmcorvidae 23:37, 22 August 2012 (UTC)

A userscript could be written to allow displaying DR numbers on the release group, release, recording pages. (This is the main draw, really.)

Hard to do recordings with this, since IIRC remasters are the same recording. However, we could theoretically show multiple ones on a recording page, I suppose, perhaps even linking to the relevant releases. Ianmcorvidae 23:37, 22 August 2012 (UTC)
Remasters should be different recordings, so recordings should be no problem — if they have a different DR value they should sound different and thus be separate recordings. —Hawke
The DR values are attached to tracks on a release; they would be shown beside each track (per release) on the recording page. Kepstin 20:50, 23 August 2012 (UTC)

There's possibly enough info on the official DB to allow semi-automatically importing DR submissions from there (catno, barcode): [Scratch that, it will be impossible due to “DR tracks: (might not be in original order)” Ensuring ordering would also have to be added into the t-meter app. —Hawke]

If we collaborate with the people who set up that DB, it's possible they still have the data stored in some sort of way that we can reverse into the original order. Barring that, a number of the submitters there seem to put the logs into the 'comment' field, which we could use. Ianmcorvidae 23:37, 22 August 2012 (UTC)
They don’t; the tools (the original or simon-r’s DR14 T.meter both) don’t ensure that the log output is in correct order (not even alphabetical/numeric order, let alone reading tracknum out of the file’s tags. —Hawke
We might still be able to do fuzzy matching by track title, I guess… (I just looked at the db, it's worse than I thought…) —Kepstin 03:00, 25 August 2012 (UTC)

If I read the code right, the release dr14 value is simply an average of the track DR14 values. So that should simplify things. Whether that’s correct per the official DR14 algorithm, I’m not sure. —Hawke