Cover not loaded for Pseudo-Release

ListenBrainz
, ,
1

Hi,
While testing ListenBrainz, I saw that a listened music if it’s a Pseudo-Release, the cover from the original release with which has a relationship, isn’t loaded. Is that how it should work?

Capturar
The Angels from G.E.M, with cover is from an original release and the one without cover is the Pseudo-Release.

I’ve also noticed that Picard, doesn’t load the complete information and cover, from the original release of a Pseudo-Release.

Thanks,

2

I’m not aware of any software that actually follows the Relationship Type / Transl-tracklisting - MusicBrainz link (probably because it incurrs an extra webservice call).

It’s certainly feasible though, as you can do it manually in Picard:

  1. Tag the files using the original release
  2. Right-click for other versions and select the pseudo-release.
  3. The modified fields should just be titles and artists, assuming that editors adhere to Style / Specific types of releases / Pseudo-Releases - MusicBrainz so that no other values are present.
3

I would expect it to use the release group image whenever there isn’t an image on a release anyway tbh.

Though it is a nice nudge to upload an image we’re going to get a lot of junk images this way :thinking:

1 Like
4

I guess the most efficient solution would be to allow linking a CAA entry to multiple releases to reduce redundancy (instead of having 10 copies of the same 3000x3000 PNG across every pseudo-release and slight streaming variation). And to allow replacing a CAA entry with a higher res version without breaking these links.

5

That’s the way I’m currently doing in Picard, I thought that relationship would be more seamlessly with Picard an ListenBrainz since the guidelines indicate to not insert duplicated values including covers .
I can see how alias, could be a better alternative than Pseudo-releases as debated in other topics, and don’ give the temptation for creating new original releases… :frowning:

Sorry force of habit… I can delete the image if it’s worth it

1 Like
6

Don’t we already do this by having a release group cover?

I don’t mind having 10 copies of an image across releases as long as it’s the actual cover for that release. If it’s more about filling gaps/having something display in a player then the release group cover is perfect for the job :+1:

1 Like
7

If it’s more about filling gaps/having something display in a player then the release group cover is perfect for the job

To do this we need to solve what @rob calls the “cannonical recording” problem. A recording can appear on multiple releases (and release groups) so which release should be chosen for the recording. We have some idea on how to approach this problem and will be working on this soon.

8

I’m confused - in my scenario it seems to pick the exact cover (and link to) for the release ID that I’ve submitted a listen for. If that release doesn’t have a cover, it displays the icon. This indicates that it’s getting an exact release match, which means it can get the release group from that?

This is the same song that I’ve matched to two releases (one with cover) in the same RG to test:

image

Definitely is tracking the specific release?

1 Like
9

The majority of listens submitted to LB do not have MBIDs. The MBID mapping process in LB finds a recording and release match for them based on the artist name and track name of the listen. As a result for the majority of listens, release is not chosen by the user but by LB.

In your case, the release MBID has been submitted by the user so we do know the exact release. Then it indeed becomes a matter of fetching the release group and finding another release in it with cover art. MB does it to show cover art on release group pages and we can probably implement that in LB too.

3 Likes
10

That would be amazing! As MB release groups already have specific art linked we can use the RG covers :grin:

4 Likes