FTR, I had the same problem with a small set of small images.
But my PC is most certainly not very powerful.
My browser process was overloading one of the CPU cores and I had to wait for minutes before my Enter edit mouse click was possible in a tiny window of 1 or 2 seconds.
The system shows the first one as having no pending tasks at all. I’ve asked the IA.
Good enough. I would think indexing to be a fairly simple and straightforward automation with high output unit numbers compared to more complex routines, so it should very well be a matter of priority – but then also, every now and then users get the impression of being a flaw to design.
Yes, that feature may come by full courtesy of whatever browser is used, is however integral to the MB Add Cover Art user nuisance – the string of actions however easy enough. At the moment 3 GB RAM 64-bit here, and browser crashes even with Task Manager giving CPU load at 1 % and browser session fresh at 300 MB – but that’s Windows’ make-up face, I know.
Kind of you, thanks. That extreme is my normal. I am guessing CAA has set high resolution to low priority, in order to up output number. All in order of perspective though.
Hank from the Archive:
i’ve got a guess - there’s an odd character (xD7) in the “comment” string for the first image:
https://archive.org/download/mbid-bccc36fc-f315-4803-98f1-b8d662eb6a80/index.json
the derive is probably running a newer version of PHP, and the newer
json_encode()may be stricter than what i’m seeing on the command line
confirmed -
json_last_error_msg()tells usMalformed UTF-8 characters, possibly incorrectly encoded
@Bitmap, this sounds like a problem on our side?
4 Likes
Yes, it looks like the CAA-indexer is sending index.json files with latin-1 encoding. I’ll investigate the issue today.
5 Likes
As an aside, the comment field shouldn’t be used to store information already present elsewhere (such as the image size or the file format).
1 Like
@reosarevok, @Bitmap & @chirlu : I usually put a comment like “2810×2810” under a picture meant for front (and ‘Folder.jpg’ source), to indicate it is cut to square shape. The link in Hank’s answer refers to the release topmost in my list, but that one has no ‘(xD7)’ character (multiplication sign ‘×’).
Cut? As in cut off? You shouldn’t modify cover art – it should show the release as it is (possibly non-square).
No, not anymore.
2 Likes
[quote=“chirlu, post:12, topic:178073”]
Cut? As in cut off? You shouldn’t modify cover art – it should show the release as it is (possibly non-square).[/quote]
Yes, because it is always immediately followed by the uncut cover front; and since the uncut cover front of a CD most often is 1 of 2 booklet cover pages, a ‘Front only’ would otherwise have to be added (or, instead, a similar automated preview). I understand your objection and the notion of Front not including the folded pseudo-Back of that spread, and am happy to comply with whatever MB principle-in-practice I am still trying to pick up on. (In this particular case, one could counter-argue with the auto-link for Amazon pictures, then in both directions with Guideline completeness.) The cut (about 20 px at 600 dpi) is done to just excise visible staples and even out edges, as the paper is often not cut in right angles and seldom print aligned. The cut Front is also made from the full booklet cover spread image, identical dust pattern and all for anyone to check. Every scan other than the cut Front thus annotated have their source edges visible.
I also scan in greyscale (exceptionally even black/white for text only) pages that have no colour, fully aware that an other may think something vital is missing.
I also have a bad scanner, poor image correction ability (colour, dust, pen writing; and other practical realities subject to user/temper rule) and little time.
Trying not to sound sarcastic, I will hence go for uncut Front. No problem.
No mistake then. Thanks.
@Griomo I believe @chirlu is referring more to things like Digipaks - these don’t have a ‘square’ cover, and sometimes editors try to add them/crop them because the result looks better on their mp3 player.
Luckily we have the option to use the release-group image when tagging (which can be set to the ‘cleanest’ and most digital playback-friendly square image) so we can comfortably vote no on those additions.
I don’t think anyone has a problem with slight edits to remove staples or weird bits visible on the edges (I often do this, as you say often the cover often isn’t cut perfectly square, leaving large areas of white on the sides of the scan), especially if the full scan is still available 
Any edits that make it no longer represent the release in hand though, just for consistency/ personal preference sake… no thanks.
3 Likes
Digipak, yes of course – but then again, how much deviation to allow for a square before it becomes something else, or precision to go the other way, still is subject to user rule, as also the borders that “represent the release in hand”. Better keep to visible or visibly nearing edges (slight edits), to save time from others’ correction and own response. Any mp3 user wanting a square Folder.jpg is free to perfect it from the uncropped Front original, just as I have done.
@Anyone This release
2016-10-16 17:54 UTC http://musicbrainz.org/release/61cf3dfd-4d3b-4bd8-92ca-f284d001ccb7/cover-art
has its sole picture visible on Cover Art page but not ‘heading’ release right of page, and i think Comment dash is from me forgetting to set Type. So this should not be exactly the same fault as the above one.
It’s the job of MP3 players to either display rectangular image with white borders or to pan and scan (zoom and crop) it to square.
We should not upload cut off covers for this or that purpose, it must all be post edit by the specific needs users. 
Maybe it could be a Picard feature to auto squarify front covers for the people who want it?
Auto‐square front cover (zoom and crop)
Update (2017-08-02):
4 Likes
A new version of the CAA-indexer has been deployed which should prevent some failures in thumbnail generation. I re-indexed the releases linked in this thread, but if you see any more, send them to me.
7 Likes
I got this list from the IA:
mbid-7781fbf1-8dc7-4b9c-b21e-a81b6a3b607c
mbid-21273725-fc85-4557-985a-502ad74476a4
mbid-0375999c-82be-4d1a-bc29-acb4e2167d7e
mbid-1fffce2e-3e61-431b-af11-cea4d008e877
mbid-380b96dd-d0fe-44b0-8d2b-791b4ccd6bec
mbid-77f46a62-2820-42a3-a57e-efed4abf0691
mbid-7af3b9cf-8f40-48a6-9f36-c0ca7eaff69b
mbid-83076c88-03ab-4ced-9406-65f45983fe1b
mbid-d50fe8c2-3869-42b7-b631-b3426ca1aa91
1 Like
In reosarevok’s list, 6 out of the 9 are by me. Here 2 more:
mbid-9584d047-bad3-44ec-9685-e621bf1ecf1d
mbid-aced546e-9eb3-41fe-9e30-3209b5527eaa
Edit: … and now they are OK. That was quick, thanks again.
1 Like
The one posted in between went MiA:
mbid-61cf3dfd-4d3b-4bd8-92ca-f284d001ccb7
To make it show in the sidebar on the right, you have to set the type to “Front” (done so now): http://musicbrainz.org/edit/42277794
2 Likes
Of course. And in case of multiple Front images, top position takes precedence. And it says so in the How to Add Cover Art Note. (Maybe all drop-down menus should collapse to chosen alternative highlighted, to meet user intuition with consistency (at Choose Type, Search Edits, and everywhere).) Thanks again.
2016-11-26 16:54 UTC mbid-0f831ee3-8b76-42aa-84d4-8236fb380a35
Front shows, others do not.
2016-11-24 14:09 UTC mbid-ab3a132e-b4aa-451b-8d2a-f0bd862712bf
Last 2.
Edit: Fixed, tank you.
1 Like