One trick if you’re using Chrome is to open the image in a new tab, start dragging it, use Ctrl+Tab / Ctrl+Shift+Tab to switch back to the MB tab, and then drop the image in the form’s “or drop files here” box. (I’m not sure if it’s possible to drag-and-drop images in Firefox yet, although there’s a comment from a few days ago saying that this might work after setting the dom.events.dataTransfer.imageAsFile.enabled option.)
I don’t know about atisket, but harmony does. It determines script and language from the titles and at least if it is certain about it it also prefills the language / script fields.
I use ROpdebee’s excellent Enhanced Cover Art Uploads user scripts. It works really well in combination with harmony or atisket because once you have the release with links to the online services the script gives you buttons to import the cover art from those services.
@kellnerd I beseech thee please consider creating an option for the harmony tool that turns off the final redirect of the newly created MusicBrainz release page back to harmony, I understand that many people find this useful, but personally it breaks my workflow (I’ve got the necessary parts, e.g. coverart already ready and don’t need the things on the redirected page)
having a link to it in the page in the edit note instead is fine, I would much more prefer that then redirecting the page I was on to another page I wasn’t expecting , it confuses me and I end up closing or going back in the browser instead.
please and thank you
Just ran into a weird lookup mixup: Given the spotify URL
harmony finds the correct releases on Tidal and Apple Music, but also the entirely unrelated Ovapowered by Kai Tha Opp. Probably something wrong in the data, but just in case someone wants to investigate.
I’ve seen a few cases where Beatport releases won’t show up on permalinks even after they are found. Usually this occurs when you searched for a release with a link from one of the other platforms, a Beatport equivalent is found, but it won’t be kept for the permalink.
One recent example of mine: Search with Apple Music link
A Beatport release is found among equivalents in other platforms.
Clicking on the Permalink however, the Beatport release isn’t listed, with the red box above explicitly stating that it wasn’t found.
Interestingly, this doesn’t occur when using the Beatport link as the primary search parameter. For the same example with the above release: search results and permalink.
This can especially get annoying on those rare (yet still in existence) releases available on both Beatport and Bandcamp, since Harmony can only process already given links for the latter but can’t search for them. Search Permalink
If you directly want to do a combined lookup using data from multiple supported providers, you would have to specify them in the URL.
Same goes for your preferred region if you don’t want to use the default (currently GB, US, DE, JP), for example:
Instead of specifying each provider (equivalent to the checkboxes on the page), you can also use the default providers (currently Spotify, Deezer, iTunes, Tidal) with category=default:
Thanks for reporting, this is an annoying edge case for sure, so I am glad you caught it.
The problem is the zero-padding of the barcode, Beatport complains that it couldn’t find the barcode without the leading zero. I only spotted this because the primary source (iTunes and Bandcamp in your examples) has returned the barcode with a leading zero.
If I add the zero-padding to the permalink, it starts working again.
So it appears that Beatport is yet another provider which doesn’t return search results if the barcode does not have the right amount of zeros
Together with the permalink generation, which chooses the encoded GTIN from an arbitrary provider (because in theory they should have the same value and each provider should be able to handle leading zeros) this leads to broken permalinks while the initial lookup worked because it used the GTIN from the primary provider which had the correct number of zeros (by chance).
Ideally the Beatport provider should try multiple barcodes, but Beatport searches are already slow enough as is, so I will probably try to make the permalink generation choose a “better suited” GTIN first, I guess.
Another reason that I believe all barcodes that have leading zeroes should use them on MB. Apple Music on a-tisket is even more wrong in that it will take off the leading zero on a 14-digit and just make it a 13-digit EAN. Either we include leading zeroes, or we don’t but making it a EAN is just wrong. 7digital is the same. If a barcode has leading zeroes, it won’t find a release unless you include them on the search but will when you do.
please consider creating an option for the harmony tool that turns off the final redirect of the newly created MusicBrainz release page back to harmony, I understand that many people find this useful, but personally it breaks my workflow (I’ve got the necessary parts, e.g. coverart already ready and don’t need the things on the redirected page)
