User:Kepstin/Ideas:DR14 Meter: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
Line 3: Line 3:
== Implementation Thoughts ==
== Implementation Thoughts ==
http://dr14tmeter.scienceontheweb.net/index.php?title=Main_Page 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)
http://dr14tmeter.scienceontheweb.net/index.php?title=Main_Page 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. [[User:Ianmcorvidae|Ianmcorvidae]] 23:37, 22 August 2012 (UTC)


The tool needs to be modified to allow passing in a list of filenames on the commandline [ [https://github.com/simon-r/dr14_t.meter/issues/5 github issue added] –[[User:Hawke|Hawke]]], and make sure it can output to stdout in text format. [''It does, via the -p switch but see [https://github.com/simon-r/dr14_t.meter/issues/6 this github issue] as well. —[[User:Hawke|Hawke]]''
The tool needs to be modified to allow passing in a list of filenames on the commandline [ [https://github.com/simon-r/dr14_t.meter/issues/5 github issue added] –[[User:Hawke|Hawke]]], and make sure it can output to stdout in text format. [''It does, via the -p switch but see [https://github.com/simon-r/dr14_t.meter/issues/6 this github issue] as well. —[[User:Hawke|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.'' —[[User:Hawke|Hawke]]] Filtering out bad submissions might be an issue.
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.'' —[[User:Hawke|Hawke]]] Filtering out bad submissions might be an issue.
: If we're writing our own DB or extending the loudness-war.info 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. [[User:Ianmcorvidae|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.)
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. [[User:Ianmcorvidae|Ianmcorvidae]] 23:37, 22 August 2012 (UTC)


There's possibly enough info on the official DB to allow semi-automatically importing DR submissions from there (catno, barcode): http://www.dr.loudness-war.info/ [''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. —[[User:Hawke|Hawke]]'']
There's possibly enough info on the official DB to allow semi-automatically importing DR submissions from there (catno, barcode): http://www.dr.loudness-war.info/ [''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. —[[User:Hawke|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. [[User:Ianmcorvidae|Ianmcorvidae]] 23:37, 22 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 real DR14 algorithm, I’m not sure. —[[User:Hawke|Hawke]]
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 real DR14 algorithm, I’m not sure. —[[User:Hawke|Hawke]]

Revision as of 23:37, 22 August 2012

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

http://dr14tmeter.scienceontheweb.net/index.php?title=Main_Page 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)

The tool needs to be modified to allow passing in a list of filenames on the commandline [ github issue addedHawke], and make sure it can output to stdout in text format. [It does, via the -p switch but see this github issue as well. —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 loudness-war.info 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)

There's possibly enough info on the official DB to allow semi-automatically importing DR submissions from there (catno, barcode): http://www.dr.loudness-war.info/ [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)

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 real DR14 algorithm, I’m not sure. —Hawke