# \[Feature Request\] Please show Picture/Cover art description as new information field
**URL:** https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952
**Category:** General Discussion
**Created:** [January 19, 2022, 1:32pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952 "2022-01-19T13:32:47Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 19, 2022, 1:32pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/1 "2022-01-19T13:32:47Z")
As far as I know, we don't have (yet) the possibility to show the content of "Cover description" in a self-defined column or in the tag panel.
We can set it manually by right-clicking on a existing Cover Art:
**But it would be great to have a new information field like**
`cover_description`
in addition to the already existing 6 fields about covers:
If you want to know which of your musicfiles includes such a cover description and what this field contains, you can use the 3rd-party-tool [exiftool](https://exiftool.org/) with this commandline:
`exiftool.exe -m -ID3:PictureDescription -p "$filename with a Cover_Picture_Description:$ID3:PictureDescription" -r -if "$ID3:PictureDescription" -ext mp3 .`
Please use it exactly as listed above with all spaces and the space dot at the end!
_(Of course you can change the part_ `with a Cover_Picture_Description:` _as you need)_
This command will recursively search your \*.mp3 files starting from your current directory and output matching files like this:
```auto
03 - PANDORA.mp3 with a Cover_Picture_Description:Pandora - up10Tion
10764 directories scanned
52055 files failed condition
1 image files read
```
In this test, 52'055 mp3 files did not include such a cover description, only 1 file has matched the condition and show its content as `Pandora - up10Tion` (as in the example screenshot above).
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 19, 2022, 1:40pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/2 "2022-01-19T13:40:46Z")
I support this and would like to add that the function should check all embedded pictures for descriptions, not just the first one.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [January 19, 2022, 4:24pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/3 "2022-01-19T16:24:26Z")
> [@ohrenkino](#):
>
> the function should check all embedded pictures for descriptions, not just the first one.
Can you elaborate on that? Should it compose multiple descriptions to a delimited list?
I'm asking, because the other information fields only consider the first image which would make the the behavior inconsistent.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 19, 2022, 4:39pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/4 "2022-01-19T16:39:28Z")
The idea would be:
it would be a shame if the first picture did not have a description but the second would and if you filter for something like
> [@LyricsLover](#):
>
> `cover_description` PRESENT
and you would not get a hit as the description is only available in further embedded pictures then the result would be misleading.
I am not sure what to do with the description - if I want to update it, I would have to select all files with the same image and edit it. Otherwise I would not know which cover I would be treating.
On the other hand: if the filter selected the right set of files, I think the rest would be manual work.
I mean, right now the filter with
%\_cover\_type% HAS back
also produces results even though the column for %\_cover\_type% shows only the type of the first cover (which is usually "front") and I have to check what the back cover looks like.
So my primary intention was to make sure that if I want to filter for files with picture description, I get them all, regardless which picture has the description.
TBH: I did not even think of lists or something ... but now that you mention it ...
But as you say: a list here would nourish the expectation that e.g. the %\_cover\_type% would also get a list. But then what about height and width? How would one know which belongs to which?
I see the problem. And for the time being I would be satisfied if I could filter for the description with the same basic function as I could filter for the %\_cover\_type%.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [January 19, 2022, 4:48pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/5 "2022-01-19T16:48:00Z")
> [@ohrenkino](#):
>
> I mean, right now the filter with
> %\_cover\_type% HAS back
> also produces results even though the column for %\_cover\_type% shows only the type of the first cover (which is usually "front") and I have to check what the back cover looks like.
I think this only works if the first cover that fills the `%_cover_type%` information field is the back cover.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 19, 2022, 4:53pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/6 "2022-01-19T16:53:40Z")
Dammit. 😉 You are right, of course. I probably mixed that with
NOT %\_cover\_type% HAS Front
which produced all covers of the type Other which was once the fasion in podcasts.
But ... i certainly would have liked such a function. Just like the filter that works with just a single word and then you see all the files where that word appears anywhere in the metadata. This would also be nice for the picture description.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [February 13, 2022, 4:21pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/7 "2022-02-13T16:21:07Z")
I've added the `%_cover_description%` field with [Mp3tag v3.12a](https://community.mp3tag.de/t/455) and it provides the description of the first cover art in the tag of the file.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [February 13, 2022, 5:03pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/8 "2022-02-13T17:03:20Z")
Thank you for this addition @florian.
Just as a reminder for myself when I look for it later:
`%_cover_description%` is one more **information field**
_(like the other 6 already existing cover information fields about height, width, type, size... or any other information field starting with an underline after the % character.)_
Therefore I can not use it in a user-defined column (or in the tag panel) to directly change the content. Such an information field always **only show** the content.
To mass change such a Cover Description with an action, we can use the action type
"Set cover properties":
This action can also be used to delete every existing Cover Description content for all selected tracks. Just leave the text input field empty.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [March 15, 2022, 5:03pm UTC](https://community.mp3tag.de/t/feature-request-please-show-picture-cover-art-description-as-new-information-field/55952/9 "2022-03-15T17:03:35Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.