# \[X\] \_cover\_size not returning the correct value
**URL:** https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306
**Category:** No Bugs
**Created:** [January 9, 2007, 12:50pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306 "2007-01-09T12:50:04Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Logan](https://community.mp3tag.de/u/Logan)
#### Post date: [January 9, 2007, 12:50pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/1 "2007-01-09T12:50:04Z")
%\_cover\_size% is reporting the correct size when a track has a single image embedded, however when a second image is added the value does not change.
Example:
Img1: front.jpg 147059
Img2: back.jpg 236003
1. Img1 Only: \_cover\_size = 143kb
2. Img2 Only: \_cover\_size = 230kb
3. Img1+Img2: \_cover\_size = 143kb
In example 3 the value always reprents the first cover added.
---
### Author:  [@Sebastian\_Mares](https://community.mp3tag.de/u/Sebastian_Mares)
#### Post date: [January 9, 2007, 2:21pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/2 "2007-01-09T14:21:19Z")
I think this is not a bug, but a limitation of the feature. The MIME type (%\_cover\_mimetype%) is also returned for the first cover only.
---
### Author:  [@Logan](https://community.mp3tag.de/u/Logan)
#### Post date: [January 9, 2007, 5:44pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/3 "2007-01-09T17:44:45Z")
Understood - however when this is used alongside %\_covers% it misrepresents what the results are.
Along that line, %\_cover\_mimetype% does not work for mp4 tags, but %\_covers% and %\_cover\_size% do.
---
### Author:  [@Logan](https://community.mp3tag.de/u/Logan)
#### Post date: [January 15, 2007, 2:40am UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/4 "2007-01-15T02:40:48Z")
Sebastion -
Does my response impact the 'not a bug' assessment?
---
### Author:  [@Sebastian\_Mares](https://community.mp3tag.de/u/Sebastian_Mares)
#### Post date: [January 15, 2007, 5:21pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/5 "2007-01-15T17:21:26Z")
As I already stated, it's not a bug, but a limitation of the feature. Maybe Florian can change this and introduce something like %\_cover\_size%[0], %\_cover\_size%[1]... for individual covers and change the behavior of %\_cover\_size% to reflect the size of all covers.
Edit: Added missing word.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [January 15, 2007, 6:08pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/6 "2007-01-15T18:08:02Z")
No, these placeholders will only support the first cover for now.
Kind regards,
Florian
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 28, 2018, 2:18pm UTC](https://community.mp3tag.de/t/x-cover-size-not-returning-the-correct-value/4306/7 "2018-12-28T14:18:38Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.