Assistance with Cover Art - Local vs. CAA when Fetching - and Storing & Fetching Preferences

Tags: #<Tag:0x00007f9ad5d016d8> #<Tag:0x00007f9ad5d01610>

In the ranking order of Cover Art sources, it stops going down the list when it finds ‘something’. Does this mean that if the particular source has a puny little thing for the front cover and nothing more, that it will stop going any further?

…or will it keep looking in subsequent sources for something of each of the files selected in first column of [Select Types…] for the first of each image type encountered until it exhausts all the source options?

Then can I have the local cover art source directory be a specified path name string for a workflow like this:

Check for Local Cover Art first. (Local Cover Art at the top of the source list) in a directory separate from where the images will be organized with ‘Use the Following File Name for Images:’

As an example, I’d have Local Cover Art looking into …/Album/ArtInput first. Nothing there? Keep going. I’d have to insert some neato regex wildcard dynamic thing that I have no clue how to setup in for the Local Cover Art. That’s another question, as RegExp is still total complete voodoo to me. I’m lucky enough to remember to do *^^^^^^ for the first X characters.

Local cover art files match the following regular expression:
^(?:cover|folder|albumart)(.*)\.(?:jpe?g|png|gif|tiff?)$] <-- a variant of that with a directory name in addition to the wildcard image hunting.

If there’s nothing there, it’s going to the next source in the list. Keep going as usual.

What I want to do is have the ability to slide in (better, my preferred, whatever artwork images) instead of what is returned by the other sources.

So, while naming/tagging stuff, if I see something come across that I have an alternate/preferred or ‘better’ version of, I can slide that in?

Of course, when appropriate, more times than not, the ‘better’ / additional files will be submitted to the CAA. But on the occasion that my selection is something done for a custom reason that others wouldn’t like as a default?

…and after all that, if there is already existing Cover Art where the Album / Tracks have an MBID already, to then leave well enough alone? So that anything I may have in place as a custom/preferred piece would not get replaced?

Some bits of this I’ve found threads about, particularly handing existing Cover Art, though still a bit ambiguous to me.

The gist of this question is can the Local cover art files match the following regular expression look in a folder for stuff to use before checking the existing artwork?

Something like ^(?.../Album/ArtLocal/ ...:cover|folder|albumart)(.*)\.(?:jpe?g|png|gif|tiff?)$ before it checks the Album root directory for existing artwork.

…and when there is existing artwork because the files have been processed via Picard already, (It would have an MBID) to then leave the existing stuff alone unless I remove it? In other words, search for only what is missing of the choices in the first column under select images.

Any of these steps would be appreciated, the non-replacement being the best one

If I understand you correctly, you want to use Picard’s scripting when looking for local cover art? Afaik it’s not possible at the moment and you can only use regular expression. I created a ticket for this some time ago:, maybe @outsidecontext could look at it at some point in the future if he finds some time :slight_smile:

Additionally, the save dialog could be split into “directory” and “filename” and the load dialog could be split into “directory”, “filename” and “extension” which would maybe look cleaner (not really a big deal to me tbh, just a suggestion). And perhaps we could even ditch the regex symbols ^ and $ since the input field already sets the start and the end of the row anyway :stuck_out_tongue:

I think in theory this should work. I basically use it that way for local cover art. By putting the local cover art provider first the other lookup options would not be used if local art exists. I’m not sure about the matching currently, but if it matches for entire paths it should be possible to setup a proper regex to look for files. If the regexes only match the filename though this won’t work. I’ll have to check.

I think @tdiaz thought about using the existing regular expressions, and that should actually work. Btw, the existing usage of regular expressions complicates your idea a bit, since I’m not sure how the regex and the scripting should best play together.