Is there more information on how the Cover Art Types are intended to work? Some are obvious, but others such as Track leave me curious. For example, is there a way to associate the image of type TRACK with a specific track? - perhaps the comment field? Just guessing though and wondering if this is described anywhere else…
1 Like
The types are documented at Cover Art / Types - MusicBrainz
No, that’s currently not possible. But it’s quite common to set the comment to “track N” for these images.
2 Likes
yes, referenced in the question. looking for more info / thoughts
That was my assumption. Are there any examples? and the larger question is there any more documentation of the thoughts behind the types?
Here are some examples:
What exactly do you miss or find unclear in the above documentation?
2 Likes
Thanks for the examples for tracks. I had never seen it in-use. I have seen a similar approach to images for booklets. Both are not documented on the Cover Art Types page or in the How to add cover art. It would be helpful if they were. It makes me wonder what else I should know and that is mentioned somewhere elsewhere. When writing a script (to name files), it would be more helpful if these were more rigorously defined with a set format etc. (I’m happy to help update the documentation pages)
Other items that cone to mind:
-
The reliance on ordering of images
-
Are multiple images of some types not allowed (e.g. Front). Which are, may seem obvious, but I saw a release this week with multiple Fronts.
-
The design philosophy is also missing. Perhaps the page defining the types is not the place, but design questions come to mind such as:
-
was the list designed to be compatible with foobar2000 and/or id3.
-
why are there no types for the front and back of a booklet that would make it easy to classify those images explicitly. (The description for BACK) says it is not to be used for the back of the booklet). If there is a reason, it would be useful to know before I propose them.
Many places now record these decisions by writing Architectural Decision Records (ADR) which document the decision and the reasoning including alternative approaches considered but rejected . Has MB considered using these?
It is needed when we want to show the booklet front cover only (if it is visible from the outside packaging, of course) but also we want to show the full packaging front, including hype sticker and obi.
Front and back are for front and back of the packaging, of what you can see on the outside.
Often the booklet front cover is actually visible on the outside packaging front, so we can set it as booklet+front in this case.
Usually, booklet back cover is not visible from the packaging outside back side, so we should not set it as back.
It’s a case by case, of course.
Do you have an example link?
3 Likes
The images in MB are aimed at identification. So it is expected a human is looking at these first. Just also helps to have convenient types for a machine reading. It is not designed for tagging, it is just a darn good resource for taggers.
Book page order is pretty well respected in MB. I would say 98% of the time you’ll find the pages in the correct order. You’ll just get caught out when there are multiple booklets in one release.
Re: back. This is not about English Language. It is purely what you see on the “back” of the complete package in hand. A back of a CD, or back of a book, or back of a tray don’t count. Same with “Spine” - that is only the external spine. There are many places in the MB world where language gets a very specified meaning. (See also “Recording”)
One place you see this bent is boxsets. Technically a boxset can have multiple fronts and backs. If you have a box with five CDs inside in separate jewel cases this is a rare example of multiple fronts and backs. Mainly due to having multiple packages you can hold in hand.
And then you have the boxset with 20 CDs, each with their own separate booklets… 
But even then, if someone has spent the time to upload the art, they usually spend the time setting the order in a clear way. And commenting each piece of art.
The trouble is there are far too many combinations of packaging types to be able to get one set of perfect machine readable rules. The guidelines MB has now are going to give many tagging scripts a pretty good head start at getting artwork into the correct category.
3 Likes
Yes, exactly.
I think this is what MB wants.
Legit several fronts and backs is different views of the same thing with and without the optional stuff.
Examples of legit several fronts:
- Release “Tina Live” by Tina Turner - Cover art - MusicBrainz
- Release “Phantom of the Paradise: Original Soundtrack Recording” by Paul Williams - Cover art - MusicBrainz
Examples of legit several back:
I don’t agree, there, this contradicts your definition above.
Boxsets should not have front images for things inside.
In this box for example, you see the usual booklet (set as Poster, here) has no Front tag, because it is inside.
Example of bad muti-fronts and multi-backs:
Only the first front and the first back are correct.
I am only describing what happens in the current MB database. And this is by properly respected older members. It is a pretty old standard method for that kind of boxset you show in your example.
It is very much specific to boxsets.
2 Likes
One release that prompted this question is Adele - 25 - US release
Note that there are two images of type “Front”
https://coverartarchive.org/release/3ce75ee5-4fb0-4209-9bde-8770d17f5fc4/12089392052.jpg
and a third image of type “Front,Booklet” for the front page of the booklet which is also the front page of the booklet (as you mention)
Note that this one of type “Front,Booklet” is not useful as a cover image as it also has the back on the booklet, so it won’t do. Therefore, there has to be an image where it’s just the front cover. One of the two images of type “Front” should not be there. The second one is a closer representation of the actual printout so it should be that one… So, now why have two images with Front as the type? The “Front, Booklet” one should just be of type Booklet. If you look at the UK release, the artwork is done better. There are a mixture of single page and double page images as appropriate.
Double page:
Single Page:
There is only a single image of type Front.
but even though it is also the front of the booklet, it is only of type “Front”.
Looking at the back of the booklet…The last image in the sequence of Booklet images is
All black… In the US set, there is no separate image for the last page of the booklet. It is shown on half of the first image which also shows the cover. It is not entirely black and has a number on it (useful for identication)
A simpler approach would be
- There is only one image of type Front
- The cover of the booklet has a type BOOKLET-COVER
- The last page / back of the booklet has a type BOOKLET-END
This would make it easier for all to understand. In the case of this example, this image
would have the type “Front, BOOKLET-COVER”. If there is a different cover for the case to the booklet, the image of each would have one of the two types.
1 Like
Because of the Edit #41007626 - Merge releases edit.
And they should be Booklet+Front, IMO.
I totally agree.
Well, only one Front, yes in this case of complete duplicate.
But in general, there can be several legit Fronts. see my examples.
1 Like
That’s what the description of the Cover page says, but it’s not what I see in practice. Lots of people uploading high resolution high quality art that is done very well. There are aspirations from many to do more in this area.
Is there any reason, why we can’t get more rigorous and make it better and more useful?
Agreed. I was asked for missing items from the documentation. So, I said an explicit statement of the ordering is one of them. Going further and adding an order as a variable would be helpful and make it easier to handle downloading booklets in the correct order as even booklet images in the correct order don’t download and create filenames in sequence on all operating systems as you observed in another thread.
I understand that, I read the definition of the types. It’s clear that it’s the back of the package. That is emphasised. Again I was asked what was missing from the documentation. I observed that the back of the booklet does not have a type. Some might think that if it’s ok to have images of type “Front, Booklet” is valid, then why not “Back, Booklet”. This goes against the description of Back, but it gets the job done…not that much worse than using the comments fields for things like page numbers or track numbers…
and others where is equally vague…with the comments field used for various undocumented conventions (Track, Booklet etc)
Indeed, I have some. I also have releases with multiple CDs which have some of the same nuances. Some work could be done there as well to clarify things. I’m just trying to understand what is defined for Cover Art types and the rationale.
With clearer guidelines, I’m confident that most of them would use the new types and variables.
I guess I’m more optimistic. MB has done a very good job on release groups and releases etc.
Agreed, but aiming for even better.
That Adele release has two fronts as it looks like there was a merge. Check the edit history. One front just needs to be deleted to be normal again.
With your critical post of Adele’s artwork, do also remember how many hours it takes to scan, crop, upload. It is not surprising many people will skip “all black” pages and focus on the ones with credits and images.
Not my database. Not my guidelines. Just the whole place is a database FIRST. Just happens to be used by taggers as a really good resource. (See also the general Release and Recording data that Picard mines for tagging).
I can’t reply point by point as you are talking to the wrong person. I don’t make any decisions around here. Just upload a ton of artwork and comply to the guidelines the best I can.
Currently the artwork is very much designed around a simple CD Jewel case or single LP. We still need additions like “gatefold inner”. Or slipcases, boxes. Tickets exist, and changes happen. You may remember the discussion about numbering booklet pages. I believe that is still in the pipeline.
Last few years I have seen new items appear for tops\bottoms of boxes, and matrixes. Things take time. There are only so many dev hours in a day. 
I agree it would be nice to say “Picard, construct the artwork for this boxset” and see it label everything automatically. I have just uploaded so many different types of packages I know how complex that would be. Even for common packaging types.
Yes, as long as I can use them as the true cover.
When I say only one Front, I mean that the only type is Front. I’m not including the other images which have OBI etc.
On your examples… is this really the front of the booklet? Shouldn’t it be just Front? How do we know it is correct? Where is the rest of the booklet?
This one is also Front, Booklet but looking at the rest of the artwork, it clearly is the front of the booklet.
It would be more definite if it was Front, Booklet-Cover.
I also noticed that in both of my Adele examples, there is no use of page numbers in the comments. This supports the argument that updating the documentation to mention this convention is needed.
@IvanDobsky note that the cover art archive describes its mission as
Images in the archive are curated by the MusicBrainz community and go through a peer review process to ensure that they are correct, free of spam and of the best quality.
note best quality. No mention of MusicBrainz’s statement that
Cover art on MusicBrainz is often used as a form of evidence for the data that appears in the database
which highlights it’s use as distinguishing releases. Two different objectives from the two organisations…
As I said, you are talking to the wrong person. I just follow the guidelines. I don’t set them. I ain’t arguing with you. I agree it would be nice to see more categories.
Re: the Tina Turner images. You can tell that is the front of the booklet due to the cat number top left corner. You can see the same cat number on the front image with all the stickers and obi.
1 Like
Nah… we just talk a lot of ****
4 Likes