# \[Suggestion\] - Rework MusicBrainz cover options to Settings schema
**URL:** https://community.mp3tag.de/t/suggestion-rework-musicbrainz-cover-options-to-settings-schema/65676
**Category:** Web Sources Discussion
**Created:** [August 21, 2024, 12:51am UTC](https://community.mp3tag.de/t/suggestion-rework-musicbrainz-cover-options-to-settings-schema/65676 "2024-08-21T00:51:23Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [August 21, 2024, 12:51am UTC](https://community.mp3tag.de/t/suggestion-rework-musicbrainz-cover-options-to-settings-schema/65676/1 "2024-08-21T00:51:23Z")
Lately I've been playing around with MusicBrainz WS scripting, and I've come across the following roadblock:
Defining a cover size for preview thumbnails can be done in the script; however doing the same for cover size in results is more difficult. This is because Mp3Tag already has cover options built-in (in File\>Options\>Tag Sources\>"MusicBrainz Cover Size"); and those take precedence from anything written in a script.
Since the introduction of the Settings schema, its now possible to create a Settings menu that enables setting cover size for results; but -in the case of MusicBrainz specifically- for _those_ settings to be applied, an extra step of going to Mp3Tag's program options and setting the cover size to "default" is mandatory, and only then can WS script settings take effect.
My suggestion is to rework -or even remove, if possible- MusicBrainz's fields from Mp3Tag's settings, since they can be written from within a WS script.
This is merely a suggestion, but in my opinion I think this would be a change for the better, since it would give (MusicBrainz) web source script authors more possibilities (and lighten Mp3Tag's code).
Thank you for your time.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [August 21, 2024, 6:26am UTC](https://community.mp3tag.de/t/suggestion-rework-musicbrainz-cover-options-to-settings-schema/65676/2 "2024-08-21T06:26:08Z")
> [@rboss](#):
>
> My suggestion is to rework -or even remove, if possible- MusicBrainz's fields from Mp3Tag's settings, since they can be written from within a WS script.
The other way around would be a command in WSS that disables existing settings.
Something like
`UseMusicBrainz_CoverSizeSettings "off"`
the default setting would be
`UseMusicBrainz_CoverSizeSettings "on"`
Such a setting would not render existing WSS inoperable.
MusicBrainz (the [CoverArtArchive.org](http://CoverArtArchive.org) to be more specific) offers 4 cover art sizes:
If someone needs another cover art size like 625x625 pixel I would suggest to use an Action "[Adjust Cover](https://docs.mp3tag.de/actions/adjust-cover/)" to reduce a bigger cover art to the exactly needed size.
Such an Action has the additional advantage that it doesn't mind what the source of the cover was. It adjust all covers in the selected files to the given Max. size.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [August 21, 2024, 11:58am UTC](https://community.mp3tag.de/t/suggestion-rework-musicbrainz-cover-options-to-settings-schema/65676/3 "2024-08-21T11:58:40Z")
> [@LyricsLover](#):
>
> The other way around would be a command in WSS that disables existing settings.
That would be perfectly fine too.
IMO, since the settings schema is meant to give the possibility of having variable options for WS scripting with a user-friendly interface, having those hard-coded in Mp3Tag's settings feels redundant. And if sometime in the future [CoverArtArchive.org](http://coverartarchive.org/) changes their offering of cover sizes, there would be no need for a new version of Mp3Tag to maintain compatibility.
But for legacy support of existing WSS, your suggestion is the best one. My suggestion was not one for the immediate, but to be considered down the road.