It basically displays a '-' if no artwork is present but if there is then it shows in the format 'Number of covers | Size KB'.
I have Numeric check-box 'unticked' as I feel it looks better that way. It's all down to personal preference and all that!...
And, the Sort by column sorts by the amount of covers followed by the size as shown in the attached screen-shots. You can change this around if your prefer sorting the other way around. The %title% then sorts them with there title. The option numerical [ ] box must be unchecked for this to take effect.
Filtering in kb
Now to filter them. Good thing to note is probably the reason some of your music players art doesn't show is because the file size is beyond its capability's and you should do some tests to prove it or consult with the manufacturer. I personally have an iPod Classic which has artwork on it up to 200kb without any problems. I haven't tested beyond this but most of my artwork is either 1000px or 500px sq. which should look good at 200kb either way.
Examples of filters are:Please note adding 'kb' is not documented in the help files but still works.
All files that do not contain cover art
%_covers%IS""All files with cover art larger than 200kb
"
$div(%_cover_size%,1024)"GREATER200'kb'
All files with cover art less than 50kb
"$div(%_cover_size%,1024)"LESS50'kb'
All files with cover art larger than 200kb OR All files with cover art less than 50kb
"$div(%_cover_size%,1024)"GREATER200'kb'OR"$div(%_cover_size%,1024)"LESS50'kb'
I hope you have picked up something useful here to use.
I think that is not correct syntax, but, due to the laxness of the filter expression interpreter, the given expression will be evaluated without error message.
Someone can write such erroneous filter expressions ...
"$div(%_cover_size%,1024)" GREATER 200kb
"$div(%_cover_size%,1024)" GREATER "200xxxxxxxxxxx"
... and Mp3tag will use it internally as written in correct syntax ...
"$div(%_cover_size%,1024)" GREATER 200
The filter operator GREATER accepts as its argument an integer value.
The filter operator GREATER is not designed for the comparison of alphanumeric string values.
Yes, I'm aware of that but its just an added visual reference for the user to know exactly what size in relation to its units of measurement of cover art he/she may be dealing with.
Anyway, It's still nice to know it's possible to do such a thing.
My formula displays nothing if cover size is zero, and does not pad the value with zeros. I prefer to suppress entries that show "0 kb" because I like to make records that lack cover art easy to spot.
Name : Covers/Size
Value : [%_covers%' / '$fmtnum($div(%_cover_size%,1024))' KB']
Field :
Sort by: %_cover_size%
Numeric: yes
DD.20120620.1720.CEST
Another proposal ...
Name : Covers/Size
Value : [%_covers%' / '$fmtnum($div(%_cover_size%,1024))' KB']
Field :
Sort by: $right($repeat('0',2)%_covers%,2)$right($repeat('0',9)%_cover_size%,9)
Numeric: no
You should not publish this piece of Mp3tag filter scripting code, because the appended 'kb' is misleading all users of Mp3tag, who rely on and trust necessary for correct syntax.
Because in this case the column sort is not numerical, I assume, that there will be happen a left adjusted alphabetical sort.
Just to avoid surprises, I make the two numerical parts of equal length and did use a delimiter character, that will not occur in the given data.
Note: Due to the equal sized values (leading zero number strings) the delimiter is not really necessary, so I removed it.
BTW: I can demonstrate that the sort expression "%_covers% %_cover_size%" does not sort correctly.
It will sort ... with Mp3tag Options for Natural Sort set to off ...
Covers CoverSize
1 10035
1 101002
1 10138
1 109280
1 10935
So would it not be best using a similar sort method to the one we have to display the values in the first place? And not have any unwanted problems? And with maybe adding '%title%' at the end and with the numercal check-box then is sorts like attached.