Album Art Downloader XUI - Multiple Cover Types in one search from MP3Tag possible?

I'm updating the album art in my library.

I've used the excellent tutorials provided by g.p.m here:

and by M3Rocket here:

I have searches set up in Tools for each album art type: Right click filename > Tools > "Front Cover Search" to search for the front cover, ... "Back Cover Search for the back cover, ..."Disc Search" for the disc etc.

This gets me satisfactory results but I wonder if it's possible to consolidate that into one search. My thinking is that AAD opens new searches in a new window by default, so if I could form the parameter such that it would perform multiple searches in AAD, I could then select the desired image from each AAD window (which would then autoclose).

Here is my current script, which is just the "Front" and "Back" searches separated by a double pipe and a space, and "/new " before the second search:

/ar "%artist%" /al "%album%" /p "%_folderpath%%album% - Front.%%extension%%" /t Front /mn 600 /mx 1400 /o  a- /ac || /new /ar "%artist%" /al "%album%" /p "%_folderpath%%album% - Back.%%extension%%" /t Back /mn 600 /mx 1400 /o a- /ac

I also tried it with three searches in place, but reduced it to two for easier modification for testing. As is, it only opens one AAD window with the last cover type searched for, e.g. "Back" in the example above, and "Disc" in my earlier tests. I'm not much of a scripter so my other tests have been trial and error, and I get either the same, single-window result as noted above, or it fails and brings up the "command line parameter" window.

So, assuming my goal is clear enough, 1: Is this possible, and 2: what would that parameter string look like?

If not, I'm certainly open to other methods of getting multiple cover types in a simpler way.

TIA.

Wouldn't it be simpler to use AAD standalone in these cases?
And it general: I would say that it is a problem for AAD and its command line syntax. If that syntax does not allow more elaborate searches, then that is it.

Thanks for the quick reply!

Wouldn't it be simpler to use AAD standalone in these cases?

Possibly, and it could definitely be a learning issue on my part. The issue there is that I don't find AAD GUI standalone conducive to efficient use, as I have to type in the name of each album I want to search for. Using it as a plugin in MP3Tag is a lot easier to manage.

And it general: I would say that it is a problem for AAD and its command line syntax. If that syntax does not allow more elaborate searches, then that is it.

That makes sense, as the command line parameter window is an AAD window, not an MP3Tag window, which I had missed previously. That's useful for searching for a solution. Also looks like the dev is active over on the hydrogen audio forums, I'll see if I can get an answer there if I can't find one elsewhere.

Perhaps a batch file helps.
That batch file could contain the different calls for AAD.
Don't know though how the simultaneous access to the same file will come out.

Don't search for front-covers, back-covers and so on. Just let AAD show you all covers and select with the preset-feature.
Here are my parameters in Mp3Tag as a suggestion and adapt them to your needs:
'/artist "'$if2(%ALBUMARTIST%,%ARTIST%)'" '/album "%ALBUM%"' /path "'%_folderpath%$if2(%ALBUMARTIST%,%ARTIST%)' - '$replace(%ALBUM%,?,,/,-,*,,:, - )'%preset%.jpg"'
You have to define your presets in AAD. Just click on the little arrow (save as) in the right lower corner of the images and edit the presets you like to use:

Then you are able to select the found images and save them with the fitting preset.

I have to say, that I save all cover art in the album-folder and only embed the front-cover in the files with an action within an action group later.

Thanks, that looks promising. Unfortunately, the little "Save As" arrow next to the floppy icon is not showing up when I do searches in AAD. What's weird is it will show up if I do a new File Browser window, pull up an album, and tell it to search from there, so I can at least view and edit the AAD presets. And it works, kind of - it saved it as "Folder-Booklet.jpg" as opposed to "%album% - Booklet.jpg".

I can't help but notice that your parameters are very different than mine, and I don't have enough familiarity with them in general to be able to confidently parse yours. It looks like you have it set up to do either album artist or artist, replace several illegal characters with a hyphen, and then save it as your selected preset. Is that right?

In contrast to the parameter selection you used, mine has hardly any restrictions on the search options. My experience has shown that it makes little sense for my workflow to restrict the search results too much, since search differentiation based on cover type doesn't really work with AAD anyway. I have also had to experience far too often that when I searched outside of mainstream albums and rather obscure, little-known albums, the search results were narrowed down too much and did not lead to any meaningful results. That's why I leave everything to my visual inspection and choose the right covers myself from the large number of those displayed, which in principle is done very quickly thanks to the size pre-sorting.

I have searched for thousands of old albums and orphaned individual tracks via AAD over the last two decades. Now that the old stock has been processed, I actually no longer need the AAD for the front cover of new albums. The relevant web source scripts for Apple, Deezer, etc. already deliver high-quality results, so AAD is usually only required for other cover types.

My parameters in the tools for MP3Tag are very simple and create a search for the combination of album artist and album. If the tag field album artist is not filled, artist is used. The cover file found later in AAD is then saved using the naming scheme %albumartist% - %album% - %preset%.jpg. The file name is further processed using the $replace function and characters are either replaced with "nothing" or partially with "-". This combination of parameters is passed to AAD when the tools are called and ensures that AAD knows which criteria to use to search and save the file.

The main difference between your previous approach and mine is that I carry out a fairly general search and the call does not already specify the cover type. This is then specified when the appropriate preset is manually selected.

Let's test it using an album and the mentioned parameters defined in MP3Tag-Tools:
Billy Bragg - Fight Songs

You can see what is being searched for and where and under what naming scheme the cover file selected as the front will be saved. If you find other fitting cover-types in the search results you can select them and they will be saved with the selected preset.
By the way: Presets can of course also be defined with white space etc. If you look at the screenshot with the presets I defined, it says " - Front" for example.
If you have multi-page booklets, for example, you can also define a naming scheme for the other pages so that you don't have to manually set the name to prevent overwriting in every case. You can always make completely manual changes to the name by selecting "Save as" instead of selecting a preset.

The above should only serve as a framework and suggestion, because every user has their own workflow and their own preferences when it comes to naming, saving, etc.

The key to your basic question is actually the changed approach of not initiating a separate tool function for each cover type, but rather taking a more generalized approach.

Thanks for taking the time to respond and explain, appreciated. I relayed your suggestion about presets to the AAD dev and he replied with a suggested string, which I modified to the below. This works for me in limited testing, so I'll probably stick with it.

/new /ar "%artist%" /al "%album%" /p "%_folderpath%%%album%% - %%type%%.%%extension%%" /mn 600 /o a-

The difference to my suggestion is the use of the variable %type% instead of %preset%.
With %type% you let AAD decide which cover type the image to be saved is and it automatically puts this cover type in the file name. With %preset% you define your cover types yourself and select them manually when saving. I also use the album artist in addition to the file name, because naming the file purely after the album is not clear enough for me if the file accidently ends up outside of its album folder.

So if for some reason you don't like the way AAD classifies it, you can still define presets yourself and simply replace %type% with %preset% in the parameters.

That makes sense. With AAD not showing me the dropdown arrow to select the preset, though, it'll be easiest to stick with the type, I think.


That makes sense to me about using the album artist in the file name. I do my music files similarly - %artist% - %album% - %tracknumber% - %tracktitle%. Tried it without the %artist% but it bugged me.

The reason for the not showing the dropdown arrow is, that you have not set %%preset%% instead of %%type%% in the parameters.

Thanks, that fixed it. I would have sworn I'd tried that previously, but it works now.

You've been super helpful, so I feel bad for asking, but I'm having one other issue with AAD. Sometimes, not every time, when I click on a search result to view it full size, it is automatically removed after I've viewed it. It'll come back up in subsequent searches. Any idea what's going on there?

Edit - looks like removing the following from the parameter fixed it. Not sure of other effects though.

/o a-

Is there a list of AAD syntax/parameters/commands somewhere? The Sourceforge page has a link to HydrogenAudio, which has a link to Wiki/Reference that goes back to SF.

As you know, there are a variety of parameters/options for displaying, sorting and grouping the covers found. And that is probably where the behaviour you observed lies.

When AAD scans the sources for covers, in many cases the size of the images in Pixels or other properttes are not returned as information, and to speed things up the images are not actually downloaded in full unless you have set it that way in the options. If, for example, you have set a grouping and/or sortiung by size for the display of the found images, they load at the bottom of the list with an unknown size. If you then click on these images, they are downloaded in full and immediately sorted higher up according to their size, unless you have activated "Do not move existing results". This can give the impression that the images are disappearing. The same applies to the filter set for the minimum size of the covers that should be included in the search results. For example, you have specified a minimum size of 600 px. If an image of unknown size is downloaded by clicking on it and the size of, say, 500 px is known, the image is simply removed from the display because it does not meet the filter specifications.

This sorts the search results so that the highest resolution images are displayed first.

Just start AlbumArt.exe with the parameter "/?" (AlbumArt.exe /?).
For almost every command-line-software "/?" stand for the help. A page with all parameters and descriptions will open.

Thanks for your parameters. I've simplified them for my use case as

'/artist "'%ARTIST%'"' '/album "'%ALBUM%'"' '/path "'%_folderpath%'Artwork\'%preset%.jpg'"'

I only save the main cover as Cover.jpg in the album folder, all extra art ends up in an "Artwork" subfolder.

This made me chuckle. I have a high 5-digit count of "Cover.jpg" files in my collection. Should my file structure ever get messed up (highly unlikely) I'd be "shit outta luck". Same goes for my movie/tv show collection where I have over 12.000 "poster.jpg" files for example haha.

Using AlbumArtDownloader as a tool in Mp3tag makes it far more useful (I'm not a huge fan of the UI) but I still find its results a bit lacking compared to using this site where I usually get my main covers.

It's also a bit of a shame that \ is substituted with - in the preset values.
I've unsuccessfully tried to trick it into saving the main cover in the main folder instead of the Artwork subfolder by using
..\Cover.jpg as the value, which saves it as ..-Cover.
Similarly, trying Artwork\Cover.jpg and Artwork\\Cover.jpg (trying to escape the \) to try and make it create a subfolder only yielded Artwork-Cover.jpg and Artwork--Cover.jpg. Pity.

However it's still a good addition, so thanks for your insights!