Thanks yvanzo, I have made a new ticket, linked it, and made a note in the description here.

aerozol: I reverted the title to “Per-medium…” only. Supporting “Per-track” images would be a different issue.

+1 I've got a few compilations that come with a different cover on each disc. Strawberry (the player) supports this already. Also, because of 1828 currently there are not many options for easily setting a cover per-disc. Usually collections that would benefit from this feature are made of several discs, between 10 and 15 is not unusual, so most manual approaches are impractical.

+1 for image entities as discussed above, in our case for associating artwork with a particular track/recording e.g. a release has a front cover but each track has its own front cover image as well. just adding it here to keep this use case in mind when this issue is considered.

thanks

In many places some releases in a release group share some cover art. Surely the workload on archive.org would be reduced if images were shared than increased?

We could use existing image urls in the image entities - there could be an option of using an existing image on the cover art archive or uploading a new image. We'd just need to keep track of the urls in the db, as I assume is currently done for release-associated cover art.

However, I do think it's unlikely that we'll get this any time soon, if at all, which is the purpose of this ticket - to make the existing system more flexible.

Distinct image entities are very unlikely to happen. Especially notable is that the three cases we've mentioned (medium images, track-specific images, booklets) are all release-specific. Two releases may share images that look the same, but these images are physically connected to the release in question.

Separating out a distinct image entity also provides a number of complications at the archive, who are already seriously overworked, don't need or want to run substantial code on our behalf, and who we can't just go write code for.

There is already code in the pipeline for release group images, implemented by a pointer to a release whose coverart should be used.

Images for other entities are another question entirely, and the backend (archive.org) work would probably be easier without a separate image entity.

+1 for image entities.

Relationships such as "wrote liner notes", "photography", etc. are also sometimes known to be specific to certain parts of the cover art (e.g., liner notes are rarely written on the medium).

It would probably also be good to be able to "group" image entities though, so all "Random Collection Album With a Complete Artist Biography" images can be seen together. Perhaps it would be enough to couple them up with a release. Perhaps it wouldn't.

Image entities would also make it user to attach an image to a release group which was also attached to a release, plus it would enable uploading artist, label, event (when/if we ever get there ), etc. images, if we want that sometime in the future.

I do actually think we should have a separate Image entity, rather than uploading cover art to each release.

I think the whole idea of a release owning images is wrong. The images should be independent of the releases/mediums/tracks/artists on which they feature.

Then, when you want to add an image to a release, you create a relationship between the release and the image, and can specify the type of artwork within the relationship.

Track-specific artwork probably doesn't have enough places of its own accord to be worth the work in isolation – but to do either part in a reasonably correct non-hacky way we need a revision of the data structure, which would make it wiser to do both at once (and probably consider other cases as well, such as booklet pages, stuff not associated with any medium (or all of them – say, the front of a box set), etc.), in order to make the structure sufficiently general for future needs.

I agree with warp. At the outset of the CAA, before I stopped having time to champion my proposal, I'd wanted our data structure, instead of (e.g.):

{ ..., 
types: ["Back", "Spine"], 
...}

to be more like:

{ ..., 
types: [{type:"Back"}, {type:"Spine"}], 
...}

Having these as objects means we can add extra stuff to the pairing of image with type, e.g. which medium or track, which page of a booklet, or even more fancy things like the portion of the image that it describes (for something like Back/Spine, for example, they're two different parts of the same image). This format would also allow several of the same type to be within the same list (as opposed to the current one, which operates as a set).

At this point, we'd probably have to keep the types key with the current semantics, but we could add a second key that has these semantics. Once that's done and the database backend updated to support this sort of extra information, something like this would be a matter of style guidelines.