How to add Cover art for Box sets comprising multiple single/artists

Is there any guidance on how to add Cover art for Box sets comprising multiple single/artists

This Smiths Box Set does have cover art for each disc and uses the medium type and then the comment contains
disc 2, disc 3 ectera

This works but the comments looks rather flakey, is use of comments field to link to medium defined anywhere, is making mediums entiry with medium ids on the cards ?

1 Like

Iā€™ve added covers for box sets like this before. What I did then was add the main cover (marked as Front, of course) and then added the front cover for each disc, marked with the type Front and with a comment telling to which disc it belonged.
Are you asking this because the situation causes issues with Picard? This has been known for a long time, and itā€™s generally accepted itā€™s not an adequate reason to add semi-accurate or inaccurate info for cover art.

2 Likes

Right in the example Ive given they use type:Other but you use Type:Front. I was trying to work out if there was a standard way of adding cover art at disc level but it appears not. Im asking because I want to know how I can interpret the MusicBrainz database for use in my own application SongKong.

There should be something in the style guidelines for this.

Unfortunately thereā€™s no way to tie cover art to individual mediums. Itā€™s a technical issue, one that has been known for a long time. The reason whoever uploaded those covers used Other instead of Front is because Picard will download any and all images that are marked as Front, and chances are they only wanted it to pick up one cover. I have seen people reassign cover art types for this reason. Your tagger will likely (if it doesnā€™t already) have the same problem. Thereā€™s not much that can be done about it as is; it will take a major schema change to fix.

This is toggleable. I canā€™t remember what the default is, but the solution is to fix Picardā€™s settings, not to change CA types. :confused:

1 Like

Well a consistent way of doing it within the constraints of what we have would be a starting point as Picard doesnt come into my scenario

It should definitely be marked Front/Back, not Other.
The first Front image will be special (itā€™ll be returned as THE front image by the CAA web service).
As for how to use it: while there may not be any standardized/official way to tie discs to a specific image, your own tagger could default to the primary front image, but, if multiple images are found, provide UI for the user to select which one(s) they want to be included in tags (making sure to include the image comment in that UI).
Even if a field was added that tied each image to a medium, that would only mean youā€™d change your default behaviour; the UI could stay in place to allow the user full flexibility.

1 Like

I dont want the user to have to select the right image. But the issue is not taggers why cant we define a standard way to add them to Musicbrainz in the first place

1 Like

Unfortunately as @HibiscusKazeneko says, itā€™s not going to be a simple process.

If something was worked out, it would be great to be able to link individual tracks to cover art as well (not that uncommon in Bandcamp releases)

1 Like

The closest we have is Cover Art / Types - MusicBrainz.
You are right; it would be nice if we had some standardized elaboration/guidance on what to do in certain edge cases, e.g. multiple front covers in a box set. I donā€™t know for sure if this has ever been covered in the form of a STYLE ticket or discussion (maybe on the old forums? my memory is fuzzy).

3 Likes

There was discussion about booklet naming conventions and stuff in [an old mailing list thread] (http://musicbrainz.1054305.n4.nabble.com/Cover-Art-Style-Guide-td4670869.html)

1 Like

Yup but it doesnt cover this boxsets. Really individual cover art per album in a boxset is the only scenario that is of interest to my customers, track level coverart is very niche.

Just because itā€™s niche to you, doesnā€™t mean itā€™s a rare thing to encounter for everyone else. MusicBrainzā€™ data structure and standards are not just for your customers (btw, you have customers and youā€™re not listed on https://metabrainz.org/supporters? Shame on you.), and the per-track cover art issue seems related enough that it should likely be handled at the same time (if not in the same manner) as per-medium cover art.

2 Likes

Well I was a supporter of MusicBrainz but me and mr kaye had a disagreement that has not been resolved so thats why Im no longer a supporter, and for the record over the years Ive paid Musicbrainz more than most of the listed supporters - but that nothing to do with this discussion so please dont bring that into it and shame me when you know nothing about it.

Im quite aware that Musicbrainz has many uses and not one for minute asking for anything special for my customers but Im pointing out that MusicBrainz users are always using MusicBrainz for per disc coverart but not in a standard way so surely it makes sense to define a standard way within the constraints of the current database, I cant see any advantage in doing it in multiple ways. And that is the issue Im concerned about, by all means look at per track coverart but that wasnā€™t what my thread was about and that does not concern me.

3 Likes

I very much would like to see this myself. Unless we have some proper implementation for cases like this it could be as simple as simple as specifying, that one adds the type ā€œfrontā€ together with a comment of ā€œmedium Nā€ (where N is the medium number) should be considered the per disc/medium cover art. Likewise type ā€œtrackā€ with ā€œtrack Nā€ could be used for per track cover art (as it is for example already done here). This can be extended to medium images as well (type media and the comment).

It removes some more detailed uses for the comment field though, for example I really like how the comments on this release specify whether it is a DVD or CD. But we could also introduce a special syntax, e.g. wrap the number strings in [ā€¦], and everything not inside [ā€¦] should be ignored for automatic evaluation of the comment. So you could wite something like Artwork for track ā€œ2 Ghosts Iā€ [track 2], thus the comment provides both the track title (or any other information) in an unstructured way, and the track position in a structured way.

2 Likes

This sounds like a very good solution, particularly using the square brackets.
Eventually having a checkbox/dropdown as part of the interface (ā€˜art relates to specific medium or trackā€™) would be awesome, but for now I think manually putting information into brackets in a consistent way is a really good idea.

This would be nice! Has anything evolved on this topic and its implementation in MB Picard?

1 Like

Sad to say that nothing has changed with artwork for years. Iā€™ve been here three years and the only change I remember is when an ā€œunedited\rawā€ option was added.

It is weird to see ā€œobiā€ but nothing for box, sleeve, inside a gatefold, inside a digipak, hub\matrix, and many other items that donā€™t fit a standard jewel case. I would love this debate to be started again. Even if it just gets us a few more tick boxes to use. Or an agreed and documented standard to allow multiple fronts like was being discussed in this thread.

2 Likes

That would be fine with me as well!
How/where should this topic be revamped for discussion?

1 Like