I think composition still works well enough for audio books, a piece if writing can still be a composition, i.e you compose a story. But if you can think of something better please share.
I do like this idea overall. A couple of things seem odd about the naming scheme to me (but itās unlikely to ever affect me so feel free to ignore).
Youāve called the track level composition but linked them all together with the work keyword, so the level 1, level 2 seem in the wrong order - because itās WORK_PARTOF_LEVEL1 rather than COMPOSITION_PARTOF_LEVEL1. My suggestion here is to use composition to mean the super work, since a typical recording would anyway have a work at the same ālevelā as it only. Also, composition has composit in it, suggesting a whole of parts.
Would it be better to stick the MUSICBRAINZ with the ID? Partly because they go together and also an alphabetic sort will keep all the bits together. You could even go for MBID to keep it a bit shorter.
An example of a pretty common and well-known work which āis part ofā two other works:
Other taggers might eventually adopt this scheme, so it may affect you sometime in the future.
Other MBID tag names are of the form MUSICBRAINZ_${TYPE}ID:
https://picard.musicbrainz.org/docs/mappings/
1 Like
I more meant because I have very little classical
Thanks. I should have guessed that was following a standard
Shouldnt Le quattro stagioni (āThe Four Seasonsā) actually have a part relationship to Il cimento dellāarmonia e dellāinventione, op. 8
Not really. Thatās a set of 12, of which the four concerts usually grouped as āLe quattro stagioniā happen to be part - but theyāre two different groupings of the concerts. It makes more sense to link all the 12 parts separately rather than introducing extra levels for these specific 4
Hmm, for me it would be useful to know that that the Four seasons is part of a larger work. But anyway I accept there good reasons why a work might be part of multiple works and this can be represented in Xml as the MusicBrainz schema already allows, but its just simply too complex to represent this within the constraints of the existing tagging systems.
Im using composition as in ācomposeā rather than as in āparts ofā but I se that could be confusing. If you have an alternative list of names please post the complete list as its difficult to work out how it fits together when you only talk about one or two field names.
So I think Iām just suggesting the opposite order to you, so:
WORK recording level work
WORK_PARTOF_LEVEL1
WORK_PARTOF_LEVEL2
ā¦
WORK_COMPOSITION super work
and the TYPE and ID ones as you had them but again this order.
To me this makes more sense as youāre saying WORK PART OF LEVEL1 (the work is part of level 1 is how I read that, rather than the composition is part of level 1ā¦)
Yeah, I get that. Itās not really confusing just a possibility to tie the two ideas together.
An alternative suggestion, which may fit better with audiobooks etc. would be to use piece (which also means a bit of) where youāve used composition so:
WORK_PIECE recording level work
WORK_PIECE_PARTOF_LEVEL1
WORK_PIECE_PARTOF_LEVEL2
ā¦
WORK super work
Thanks, thats the same order as me, the difference is you have renamed WORK_COMPOSITION as WORK and WORK as WORK_COMPOSTION. For me the trouble with this is
- The most importance thing for most users will be the overall work with my naming convention that is the succinct WORK but its yours its the more cumbersome WORK_COMPOSITION.
- You now have the possibility that WORK_COMPOSITION is assumed to be to do with a composition (as I meant it) rather than comprising parts as you meant it so you havent solved that issue.
The alternative of using PIECE does remove any confusion over the work composition but I donāt see PIECE has anything to do with audiobooks and its not a word I would use regarding music although I know it can be used that way i still think a āsong is a recording of a compositionā is better than āsong is a recording of a pieceā, especially if the piece is not part of a larger work.
I would still think of [Il cimento dellāarmonia e dellāinventione, op. 8] (Work āIl cimento dellāarmonia e dellāinventione, op. 8ā - MusicBrainz) as a composition (in musical terms) - but perhaps Iām wrong - so I donāt see the problem here.
If you donāt like WORK_PIECE my other suggestion would be to add COMPOSITION into each of the levels so
WORK_COMPOSITION
WORK_COMPOSITION_PARTOF_LEVEL1
ā¦
WORK
because itās the recording level work that is āpart ofā not the super work.
You have a point the difficulty is because there can be anything from 1 to 6 levels in the current db of works what works well for one scenario is not so good for other. The trouble with PIECE is that it sounds like PART and if you have a recording linked to one WORK then its not a piece. I agree that COMPOSITION could be thought of as the top level all encompassing work but as thats the most useful work for most seems better to have simple WORK.
Some applications already do use PART as work, specifically a Movement but the trouble is they only consider a two level work hierachy and cant consider more than that.
Your idea of using WORK_COMPOSITION for all part of levels logically makes sense, but does mean we end up with some rather cumbersome long field names, and long fields are a practical pain
Undecided, Outsidecontext as co-author of tag mapping do you have an answer ?
1 Like
Unfortunately not. I already tried to write a meaningful reply on this topic. But I realized that nested works is something I neither understand very well nor care much about.
1 Like
So as I mentioned there is a field defined for VorbisComment as PART and also PARTNUMBER at http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html and referred to in http://wiki.hydrogenaud.io/index.php?title=Tag_Mapping for the case of a something like Concerto the part would be the the work (i.e movement) the recording was linked to, and the PARTNUMBER would be the where that work came in the list of the upper work and it seem to just use the TITLE field for upper work which I would not do.
Of course this mechanism only supports two levels of work but it helpful for use to make use of existing defacto standards wherever possible and use similar for other formats so although PART isnt very descriptive Im now thinking along these lines:
MUSICBRAINZ_PART_WORK_LEVEL0_ID
PART
PART_TYPE
PARTNUMBER
MUSICBRAINZ_PART_WORK_LEVEL1_ID
PART_LEVEL1
PART_LEVEL1_TYPE
PARTNUMBER_LEVEL1
MUSICBRAINZ_PART_WORK_LEVEL2_ID
PART_LEVEL2
PART_LEVEL2_TYPE
PARTNUMBER_LEVEL2
ā¦
MUSICBRAINZ_WORK_ID
WORK
WORK_TYPE
Of course PART doesnāt make much sense if the recording is just linked to a work , and that work is the top level work as most work types of 'sonāg are, but in that case perhaps we should just fill in MUSICBRAINZ_WORK_ID, WORK and WORK_TYPE for in this case and leave PART and PARTNUMBER alone
Users who dont know about MusicBrainz can continue to use PART and can deduce WORK, but we now have multiple levels and the Musicbrainz links are availabale for those who know about it
1 Like
Those OGG tag recommmendations also mention a OPUS tag, how does this fit in? Would that be the most top level work then?
No that is different (but something I am going to add), as I understand it every time a classical composer creates a new top level work such as symphony or concerto they give it a new Opus number, generally starting from Op1. So in the example earlier Il cimento dellāarmonia e dellāinventione, op. 8 is Opus 8, i.e Vivaldis eighth major work.
Il cimento dellāarmonia e dellāinventione isnāt a work but a set of works. Itās a set of 12 concertos published together. The order of opus numbers with Vivaldi isnāt the order of in which the works were composed. I guess itās related to publishing like with many earlier composers. Vivaldi used only 12 opus numbers (all for sets, 114 works included) even though he composed over 800 pieces.
Recommended reading:
Then it might best fit a Series entity (of Works) rather than a Work entity?
As a structure it would fit well but for many practical reasons itās better to keep using works.
For example we currently use series for work catalogs but series doesnāt support mixing different types to same series. If op. 1 is a set but op. 2 isnāt these couldnāt be part of the same catalog. There would be also trouble with duplicates because search engine currently support only one entity type at once. Random visitor wouldnāt understand to select āseriesā when checking if a work already exists and would keep adding new duplicates.
Thereās already over 700 000 works/parts on the database and it would be a nightmare to manually convert some of these to new format. It would also need some precious developer time.
1 Like