2021.9.23.2 is out, with two enhancements:
- Full VGMdb support (thanks @crayonbro for the suggestion). Types and comments are extracted on a best-effort basis, so make sure to double-check the pre-filled data to make sure its correct and well-formed.
- Improved edit notes (thanks @zas for the suggestions). Source URLs now go at the top, URLs extracted from a page are included, as are the non-maximised URLs for provenance. Those are truncated to three URLs to prevent too much noise in the edit history for releases with a lot of covers (imagine if all URLs were shown on all edits after importing all the images from this Discogs release
) Ideally each edit would only include the URLs relevant to the single image in the edit, but that’d require hooking very deeply into the upload process, and I’d likely break stuff. Example of how it is now:
https://vgmdb.net/album/86043
* https://media.vgm.io/albums/34/86043/86043-1555603051.jpg
* https://media.vgm.io/albums/34/86043/86043-1560159976.jpg
* https://media.vgm.io/albums/34/86043/86043-1560159983.jpg
* …and 1 additional images
https://www.amazon.co.jp/gp/product/B07QTNG28W
* https://images-na.ssl-images-amazon.com/images/I/51Avck-4usL.jpg
Maximised from https://images-na.ssl-images-amazon.com/images/I/51Avck-4usL._AC_US40_.jpg
–
MB: Enhanced Cover Art Uploads 2021.9.23.2
https://github.com/ROpdebee/mb-userscripts
@chaban: It’ll take me a while to fully triage all of that (update from the future: It took 2 hours), but first impressions:
An option to abort and/or add only front/first cover.
Aborting while it’s fetching images would be quite tricky, and I generally agree with @mattgoldspink here. I’m concerned that allowing an abort might lead to partial cover sets, and that wouldn’t be ideal. OTOH, having the option to fetch only the first image (presumably the front cover) would be a good compromise, IMO. #37
In general, I think it’d be nice if it first grabbed and displayed small thumbnails for all images, and only then fetches and queues the full image. That’s a non-trivial change to make though.
Bandcamp provider: Grab track images
Good idea, definitely feasible and worth it. #38
Bandcamp provider: Consider also grabbing the image as presented on the page
That should also be feasible. Off the top of my head, I’d say 1) grab the original image since we’ll definitely need it, 2) check whether its dimensions are non-square, 3) grab the thumbnail if it is. I’d argue that there should be some allowance of non-squareness though, there’s not much point in doing that if the original is 1000x1010. So maybe anything within a 1.0 ± 0.05 ratio could be considered square (So 1000x1050 would be kept as-is, 1000x1100 would get the square thumbnail)? #40
VGMdb provider: To see all images one needs to be logged in.
The VGMdb provider added in the most recent update uses the vgmdb.info 3rd-party open API, which seems to return all covers without requiring any account or API token.
Display hint about cover provider quality (ideally they can be compared)
That would be a good addition for sure, but I’m a bit stumped on how to best display it. Adding a markdown file in the repo and linking to it (like what’s being done for the supported providers) would be easiest, would that be an acceptable solution? To summarise the edit notes:
- SoundCloud has bad compression
- iTunes PNGs are often useless unless the source image is a PNG
- Deezer is upscaled and badly compressed (and IIRC they used to/still do apply color filters on some covers?)
- Bandcamp is mostly fine
- Spotify is always 640x640
I don’t think there will be any reliable way to always grab the “best” image (and “best” is often subjective anyway), like e.g. the Bandcamp example that’s upscaled from a 400x400 image, I don’t believe there’s any way that could be detected automatically without significantly hampering UX and hogging browser resources. For Apple Music, at first glance it does seem possible to automatically do the substitution of the file extension (there are some exceptions, notably URLs given by a-tisket, which use the iTunes URLs instead of Apple Music, and those don’t include the original file name). However, are we sure that those JPEGs aren’t lossily re-encoded versions of a lossy source JPEG?
In general, I think three things are needed:
- A central overview of caveats of cover art providers.
- A way of previewing the queued images in full size (like the artwork dialogs on the cover art page itself)
- Basic properties of the image (dimensions, size, file type)
Points 2 and 3 would be feasible to do once the CAA Dimensions and Supercharged CAA Edits scripts are ported to TypeScript. It’d also be nice if all of the image properties would be calculated for all images prior to actually fetching it, but I’m concerned that that would be too taxing on the network connection.
I’ve created #41 to track, but I have to work out the details a lot more.
Paste multiple external links at once
#42 and #43.
Adding it on more pages should be possible. The other thing is indeed a bug which I had encountered already, in short, the script isn’t listening for URL removals so it’s also not adding itself to the new input boxes.
)
