ahoy all,
i came across a case where a release has a front cover, but then certain tracks/recordings of that release have their own particular front cover or additional artwork. is this something that can represented in MusicBrainz? i did not see a way to create a cover art relationship with a track or recording.
thanks, w
Recordings, no, and that’s one of the issues people have with using standalone recordings to represent individually-hosted digital tracks. Unfortunately, there’s also no way to associate images with specific tracks in the database, either. What we do have, are CAA images, a “track” image type, and comments to point out the proper track to any humans reading – see this release for an example, though unlike me you’ll probably want to mention the track number rather than relying on position and title.
By the way, I don’t know if you meant it like this, but “relationship” has a particular meaning on MusicBrainz, and adding cover art (of any type) via relationships has long since been deprecated. It could definitely be nice to have a structured way to say which track a “track” image is for, but until and unless the devs decide how to and whether it should be added, that will probably have to do.
that looks like a decent solution for the time being, thank you for pointing that out. i normally refer to the ID3 artwork types which does not have a “Track” type like MB.
are there any plans to add this functionality? perhaps there is already an existing feature request? as you point out with this solution the correspondence between a track and its personal artwork is now dependent on comments and titles, with no real link.
i did actually mean relationship in the MB sense as i had assumed that underneath it all the Release artwork was linked to it via an MB relationship, as most other things are in MB (if i understand correctly).
OK, some things to chew on, thanks again.
peace, w
I found the ticket for per-medium CAA images:
There’s some talk on that ticket for per-track etc. as well, and I didn’t find a separate per-track ticket either doing a (very!) quick search.
They’re not. 
CAA images are not MusicBrainz entities. They’re uniquely linked with individual Releases.
thanks for pointing me to that, i added a comment regarding the per track/recording artwork in the hope that it will be considered if/when that issue is addressed.
interesting. actually in that ticket above one of the prevailing suggestions is to make artwork/images their own entities in the DB and just use the standard relationship mechanism to link them to releases, mediums, tracks, recordings, etc. right now the way cover art is handled seems to be a special case, lacking the flexibility of the relationships.
thanks again for your comments and help.
I’m with Ian in the ticket discussion on image entities being undesirable. The thinking in this community is that CD-in-hand is the best reference, but accurate and direct scans are a close second. The issue with just about every other potential source is that most databases will fall back on a single standard image for every release in a group, or at the very least every release without a more specific cover, and doing so lose the small details we rely on; a while ago, me and another user were only able to verify we had different releases because one catalog number was truncated and one was oranger - all the rest of the printing we looked at was identical - and because of that one small difference I wound up adding a new release with new artwork.
If we decouple art from releases by moving it to its own entities, and ignoring everything that would affect on the CAA (which, though the reminder is likely unnecessary, is not technically part of MB), it by definition makes it so much easier for the same image to be linked to multiple releases. New users and tagging completionists - as opposed to those who prioritize data quality, and not that I hold it against either group - will abuse that ability to add art to the wrong release. Yeah, there’s a small argument to be made about any images that are actually shared identically within a group, but it comes at the price of giving up one of the main things allowing us to be (ideally) more accurate than any of the other metadata sites.
We do still need to eventually have some in-schema way of associating images with particular media/tracks, but entities and relationships are not how I want to go about it. I myself am partial to something like Ian’s second JSON example given in the third comment, with the addition of an optional id field alongside the type to contain the relevant MBID, though I could also see it going the other way and having the image ID linked from the track entity. Either way, it will need new UI to restrict the selection to only what’s associated with the same release and I’m not sure if there’s any lower-level way to ensure that. Would finally give the track table some inarguable purpose, at least! 
And, yes, I know it probably already groups recordings to their displayed titles; unless that’s also where pseudo-release alternate tracklists get merged, though, I remain somewhat unconvinced that that couldn’t be covered by bloating medium a bit.