SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Sometimes failes to correct artwork from MusicBrainz

I have noticed that, in at least 2 different files, Jaikoz does not fetch the artwork from MusicBrainz. It just leaves the field empty or populates it with the Diskogs artwork.

One of the releases is
James - Laid

Using Jaikoz 4.4.0 on Windows 7.

I don’t know exactly how MB images work, but usually they come from the Amazon ASIN. In this case, Laid - James had an image but no relationships. I don’t know where the image came from (even though it was an Amazon image), but I believe Jaikoz looks for the actual ASIN image link used in the relationships.

Someone correct me if I’m off here.

I just added that ASIN, so try it again.

Yes that is correct, also sometimes the artwork can be derived from the ASIN and sometimes it cannot.

Now for some exciting news, MusicBrainz has just started work on a Cover Art archive with in conjunction with the Internet Archive http://wiki.musicbrainz.org/MusicBrainz_Summit/11/Session_Notes#Cover_art_archive

Thans dkoh and Paul,

I tried again but for some reason Jaikoz stubbornly attaches the Diskogs artwork (a photo of the CD), not the artwork that appears on MusicBrainz.

Also, this happens with the command “Update data from MusicBrainz”. Could there be a bug somewhere that causes Jaikoz to go to Diskogs instead?

Excellent news about the Cover Art archive by the way!

Its not a bug but when you do Update from Musicbrainz it updates all fields it can from Musicbrainz then if the Musicbrainz Release has a relationship to a Discogs Release it will do further updates for empty fields from Discogs.

If you want to prevent update from Discogs completely just enable
Preferences:Musicbrainz:Automatch:Do not match from Discogs when Matching

Alternatively if you just want to prevent updating artwork from Discogs then change Preferences:Remote Correct : Discogs : Artwork

If you dont want Jaikoz to use Discogs at all, i.e match to a Discogs Release when there is no Musicbrainz Release you should also remove it from the selected tasks in Preferences:Manipulators:Autocorrecter

Paul, I have not enabled Preferences:Musicbrainz:Automatch:Do not match from Discogs when Matching but I have set the Diskogs to Replace Artwork if Empty or no MusicBrainz Id.

Therefore, since there exists a Musicbrainz artwork for this release (ASIN B000057G46), Jaikoz should be grabbing this and not the Diskogs’s artwork. There’s something preventing the program from getting the artwork from MB.

To demonstrate the problem, I enabled Preferences:Musicbrainz:Automatch:Do not match from Discogs when Matching and Jaikoz just isn’t fetching any artwork at all for this release.

I have also seen this happening with another of my albums but I can’t recall which one.

I kindof doubt it, but could this be caused because my ASIN edit has not become “official”? Even though the ASIN shows on the Laid release, it’s still in my edits for voting.

At what point do edits like these pop up in the API where Jaikoz can get it? I’ve seen that new releases aren’t found until approved unless you use the MBID. Is this similar?

Actually, I think this is a very reasonable hypothesis. I will wait until the ASIN edit is final and I’ll try again.

Thanks!

I am sorry for coming back to this thread but the edit for this track is now complete in MusicBrainz. The correct ASIN relationship is assigned to it and therefore Jaikoz would be expected to fetch that artwork.

However, when tested Jaikoz fails again to fetch the artwork for this track. The field remains empty or gets populated by Discogs’s artwork depending on settings.

The problem is sometimes the ASIN can be used to determine the artwork , and sometimes it cannot

In this case it cannot, the artwork is stored at :

http://ecx.images-amazon.com/images/I/41NVgtPjdIL.SL500_AA300.jpg

The url bears no relation to the ASIN

http://www.amazon.com/gp/product/B000057G46

Now if I was to sign up to use the Amazon Api I could do this, but very unclear what their position is on this.

I see. Thanks for clarifying this. :roll: