Difference between revisions of "User:Hawke/Classical roadmap"

From MusicBrainz Wiki
Jump to navigationJump to search
(Created page with "==Works data== As far as the works data is concerned, these issues are critical: * As mentioned previously, we need to stop having to enter both the supra-work title in the su...")
 
Line 1: Line 1:
 
==Works data==
 
==Works data==
 
As far as the works data is concerned, these issues are critical:
 
As far as the works data is concerned, these issues are critical:
* As mentioned previously, we need to stop having to enter both the
+
* As mentioned previously, we need to stop having to enter both the supra-work title in the sub-work. Symphony No. 9 should be the supra-work name and I. Allegro should be the sub-work name. The reason is obvious, if
  +
the names are combined and we later find that the supra-work name, we need to edit *all* sub-works. There are certain supra-works with several levels of works and perhaps 20-30 total sub-works (this is common in baroque collections). I made a ticket for this a long time ago. MBS-3374<http://tickets.musicbrainz.org/browse/MBS-3374>
supra-work title in the sub-work. Symphony No. 9 should be the supra-work
 
  +
* The work list needs to be condensed in a hierarchical way. Here was my ticket: MBS- 2637 <http://tickets.musicbrainz.org/browse/MBS-2637>. Being able to filter would be really nice too.
name and I. Allegro should be the sub-work name. The reason is obvious, if
 
  +
* As mentioned also previously, we need to be able to store additional data in the works such as Catalog number(s), key, perhaps popular nickname (ie Emperor, Ode to Joy), Number in a series (ie the 3rd movement, 4th in a collection, etc...) Here's the ticket MBS-3375<http://tickets.musicbrainz.org/browse/MBS-3375>
the names are combined and we later find that the supra-work name, we need
 
  +
* We need some sort of inheritance system between supra-works and sub-works. We shouldn't have to repeat the fact that Beethoven composed Symphony No. 9 in every single one of the movements. The same would go for composition dates or other data which should be inherited. If there's a case where the data shouldn't be inherited (ie. one of the movements was composed by someone else), entering only the changed data in the sub-work would or could override the supra-work value. This was proposed in RFC-339 by Jim DeLaHunt way back in October 2011. However, like most RFCs that don't involve adding a site to a whitelist, it died.
to edit *all* sub-works. There are certain supra-works with several levels
 
  +
* The language of the main work name has been brought up a few times but never fully resolved i think. Should Beethoven's works all be listed in German? Or should they be listed in English with German as an alias? I think we should be consistent here. At the very least on a per composer basis, however I would prefer a MB-wide standard. ie english for the general parts of the work titles (Symphony No.; Violin Sonata; etc...) (These can easily be translated automatically anyways) and the original language for the title types, ie song names, work nicknames. The key, if stored in a special field wouldn't be a problem anymore.
of works and perhaps 20-30 total sub-works (this is common in baroque
 
collections). I made a ticket for this a long time ago.
 
MBS-3374<http://tickets.musicbrainz.org/browse/MBS-3374>
 
* The work list needs to be condensed in a hierarchical way. Here was my
 
ticket: MBS- 2637 <http://tickets.musicbrainz.org/browse/MBS-2637>. Being
 
able to filter would be really nice too.
 
* As mentioned also previously, we need to be able to store additional
 
data in the works such as Catalog number(s), key, perhaps popular nickname
 
(ie Emperor, Ode to Joy), Number in a series (ie the 3rd movement, 4th in a
 
collection, etc...) Here's the ticket
 
MBS-3375<http://tickets.musicbrainz.org/browse/MBS-3375>
 
* We need some sort of inheritance system between supra-works and
 
sub-works. We shouldn't have to repeat the fact that Beethoven composed
 
Symphony No. 9 in every single one of the movements. The same would go for
 
composition dates or other data which should be inherited. If there's a
 
case where the data shouldn't be inherited (ie. one of the movements was
 
composed by someone else), entering only the changed data in the sub-work
 
would or could override the supra-work value. This was proposed in RFC-339
 
by Jim DeLaHunt way back in October 2011. However, like most RFCs that
 
don't involve adding a site to a whitelist, it died.
 
* The language of the main work name has been brought up a few times but
 
never fully resolved i think. Should Beethoven's works all be listed in
 
German? Or should they be listed in English with German as an alias? I
 
think we should be consistent here. At the very least on a per composer
 
basis, however I would prefer a MB-wide standard. ie english for the
 
general parts of the work titles (Symphony No.; Violin Sonata; etc...)
 
(These can easily be translated automatically anyways) and the original
 
language for the title types, ie song names, work nicknames. The key, if
 
stored in a special field wouldn't be a problem anymore.
 
   
 
== Recordings ==
 
== Recordings ==
  +
* in 90-95% of classical recordings, they should be identical to the related work. They shouldn't be identical to the recordings because the same recording could appear on multiple releases from multiple labels, in different languages and written in a different way. Perhaps when linking the recording to the work, an attribute to make the recording title a dependent of the work title. Ie, if a work title is changed, all linked recordings with such an attribute would also be renamed accordingly.
   
  +
* I've suggested previously on this list that perhaps it would be a good idea to have the same hierarchy in recordings as we do in works. Meaning we could create a supra-recording, such as Symphony No. 9, have the sub-recordings then linked. The reason is that in most cases, the performers or the performance date, location are the same for all movements. Storing them in the supra-recording would make sense. Having the same hierarchy in recordings as we do in works would also be consistent.
a.) in 90-95% of classical recordings, they should be identical to the
 
related work. They shouldn't be identical to the recordings because the
 
same recording could appear on multiple releases from multiple labels, in
 
different languages and written in a different way. Perhaps when linking
 
the recording to the work, an attribute to make the recording title a
 
dependent of the work title. Ie, if a work title is changed, all linked
 
recordings with such an attribute would also be renamed accordingly.
 
 
b.) I've suggested previously on this list that perhaps it would be a good
 
idea to have the same hierarchy in recordings as we do in works. Meaning we
 
could create a supra-recording, such as Symphony No. 9, have the
 
sub-recordings then linked. The reason is that in most cases, the
 
performers or the performance date, location are the same for all
 
movements. Storing them in the supra-recording would make sense. Having the
 
same hierarchy in recordings as we do in works would also be consistent.
 
   
 
== Release editor ==
 
== Release editor ==
  +
We should have a classical-specific release editor for classical. Ideally, we would select the works on the album, the movements and track list could populate automatically from the sub-works in the work. And then we could adjust the track list to fit the actual release. We would add the release info and the performers and it would be done. I also opened a ticket for this MBS-2636.
We should have a classical-specific release editor for classical.
 
Ideally, we would select the works on the album, the movements and track
 
list could populate automatically from the sub-works in the work. And then
 
we could adjust the track list to fit the actual release. We would add the
 
release info and the performers and it would be done. I also opened a
 
ticket for this MBS-2636.
 
   
 
== Tracklist ==
 
== Tracklist ==
  +
As for the tracklist, we should have the ability to have the tracklist in multiple languages. (I'm pretty sure this was proposed/suggested somewhere). Classical releases often have 2 or 3 languages. Having this ability would allow us to store all of them instead of trying to pick the most suitable. In some countries, that is very difficult (ie here in Canada where both English and French are official languages)
As for the tracklist, we should have the ability to have
 
the tracklist in multiple languages. (I'm pretty sure this was
 
proposed/suggested somewhere). Classical releases often have 2 or 3
 
languages. Having this ability would allow us to store all of them instead
 
of trying to pick the most suitable. In some countries, that is very
 
difficult (ie here in Canada where both English and French are official
 
languages)
 
   
 
== Tagger ==
 
== Tagger ==
Finally, Picard should be modified to tag our files a little
+
Finally, Picard should be modified to tag our files a little differently for classical music. First of all, it should support adding the work name and work ID to the tags. Second, we could set a preferred language and it could then tag using the appropriate language alias if present.
differently for classical music. First of all, it should support adding the
 
work name and work ID to the tags. Second, we could set a preferred
 
language and it could then tag using the appropriate language alias if
 
present.
 
 
Anyway, here's to hoping some these get picked up by the developers or by
 
some of the more influential members here to help pushing them through...
 

Revision as of 17:52, 11 February 2013

Works data

As far as the works data is concerned, these issues are critical:

  • As mentioned previously, we need to stop having to enter both the supra-work title in the sub-work. Symphony No. 9 should be the supra-work name and I. Allegro should be the sub-work name. The reason is obvious, if

the names are combined and we later find that the supra-work name, we need to edit *all* sub-works. There are certain supra-works with several levels of works and perhaps 20-30 total sub-works (this is common in baroque collections). I made a ticket for this a long time ago. MBS-3374<http://tickets.musicbrainz.org/browse/MBS-3374>

  • The work list needs to be condensed in a hierarchical way. Here was my ticket: MBS- 2637 <http://tickets.musicbrainz.org/browse/MBS-2637>. Being able to filter would be really nice too.
  • As mentioned also previously, we need to be able to store additional data in the works such as Catalog number(s), key, perhaps popular nickname (ie Emperor, Ode to Joy), Number in a series (ie the 3rd movement, 4th in a collection, etc...) Here's the ticket MBS-3375<http://tickets.musicbrainz.org/browse/MBS-3375>
  • We need some sort of inheritance system between supra-works and sub-works. We shouldn't have to repeat the fact that Beethoven composed Symphony No. 9 in every single one of the movements. The same would go for composition dates or other data which should be inherited. If there's a case where the data shouldn't be inherited (ie. one of the movements was composed by someone else), entering only the changed data in the sub-work would or could override the supra-work value. This was proposed in RFC-339 by Jim DeLaHunt way back in October 2011. However, like most RFCs that don't involve adding a site to a whitelist, it died.
  • The language of the main work name has been brought up a few times but never fully resolved i think. Should Beethoven's works all be listed in German? Or should they be listed in English with German as an alias? I think we should be consistent here. At the very least on a per composer basis, however I would prefer a MB-wide standard. ie english for the general parts of the work titles (Symphony No.; Violin Sonata; etc...) (These can easily be translated automatically anyways) and the original language for the title types, ie song names, work nicknames. The key, if stored in a special field wouldn't be a problem anymore.

Recordings

  • in 90-95% of classical recordings, they should be identical to the related work. They shouldn't be identical to the recordings because the same recording could appear on multiple releases from multiple labels, in different languages and written in a different way. Perhaps when linking the recording to the work, an attribute to make the recording title a dependent of the work title. Ie, if a work title is changed, all linked recordings with such an attribute would also be renamed accordingly.
  • I've suggested previously on this list that perhaps it would be a good idea to have the same hierarchy in recordings as we do in works. Meaning we could create a supra-recording, such as Symphony No. 9, have the sub-recordings then linked. The reason is that in most cases, the performers or the performance date, location are the same for all movements. Storing them in the supra-recording would make sense. Having the same hierarchy in recordings as we do in works would also be consistent.

Release editor

We should have a classical-specific release editor for classical. Ideally, we would select the works on the album, the movements and track list could populate automatically from the sub-works in the work. And then we could adjust the track list to fit the actual release. We would add the release info and the performers and it would be done. I also opened a ticket for this MBS-2636.

Tracklist

As for the tracklist, we should have the ability to have the tracklist in multiple languages. (I'm pretty sure this was proposed/suggested somewhere). Classical releases often have 2 or 3 languages. Having this ability would allow us to store all of them instead of trying to pick the most suitable. In some countries, that is very difficult (ie here in Canada where both English and French are official languages)

Tagger

Finally, Picard should be modified to tag our files a little differently for classical music. First of all, it should support adding the work name and work ID to the tags. Second, we could set a preferred language and it could then tag using the appropriate language alias if present.