Cover type impacts file size?

I had some .m4a files that grew larger than I was expecting, and my debug seems to reveal that changing the cover type from Front Cover to Back Cover causes the file size to grow by 2x the size of the cover graphic. Is this expected for some strange reason?

Here's an example:

  • I start with an .m4a file of 1,606 KB with no graphic

  • I add a 551 KB graphic as a Front Cover type, and the file increases to 2,157 KB (seems normal)

  • I change the cover type from Front Cover to Back Cover, and the file size increases to 2,709 KB (not what I'd expect--it seems to be the original 1,606 KB file plus 2x the 551 KB graphic)

  • If I change the cover type back to front cover and resave, the file goes back to 2,157 KB (as I'd expect)

So far this seems quite reproducible, so is this expected due to some tagging specification, or have my files hit some strange boundary case?

In case it matters, I'm using MP3TAG v2.72 on a Windows 8.1 64-bit system.

I tried that for several MP3 files (not m4a) and could not reproduce that behaviour in any file.
I tried it via the tag panel and with the extended tags dialogue.
I tried it for several cover types, not just front and back - the file has always the same size, only the "modified" date changed.
Could it be that you have several tag versions in the files (although I do not know if that is possible for m4a)?

There is only one Bit resp. one Byte to change in the tag-data from type "Front Cover" to "Back Cover" .

Please explain step by step what you are doing to get this result.

Hmm, just an idea ... because file type .m4a is a container format, maybe there happens something like re-packaging???


I can confirm this behaviour with m4a.
It only happens when changing to back cover, not to any other cover-type.
Changing the back-cover-type to any other cover-type after that reduces the size again.

So it seems to be a bug for me.

I can reproduce the increased file size as reported.
Using Exiftool, it is possible to investigate what happens when Mp3tag saves covers for M4A files.

When a cover is saved to an M4A file using type "Front Cover", there is only one new field added to the Quicktime tag section: CoverArt
Also, even though all cover types are available (eg. Media, Other, Icon etc.) only "Front Cover" or "Back Cover" will persist after saving.
Any other selected cover type will be saved as "Front Cover"

This is in contrast to an MP3 file, where 4 new fields are added for each cover: PictureMimeType, PictureType, PictureDescription and Picture
Any selected cover type will persist after saving an MP3 file.

Now the interesting part:
When a cover is saved as type "Back Cover", Mp3tag creates a new tag section called "Audible" and copies all existing user editable metadata to that section, except for existing covers.
4 new fields are also created: CreatorTool, CoverArtType, CoverArt and ChapterNumber.
This occurs in addition to adding another CoverArt field to the Quicktime tag section.
Therefore, embedded back covers are duplicated in the file, and the duplication is not reported when counting covers.

I can think of 2 reasons for this behaviour.

  1. A bug: The "Audible" section is an intermediate step that should be deleted but is not.
  2. This is a work-around to allow "Back Cover" to be used as cover type which is maybe not accomodated in the usual Quicktime tag section. The trade-off is the larger file size that we observe. Presumably, there would have to be a copy for every other cover type, if Mp3tag supported them for M4A files.