# Please support the iTunes variant extension "M4P". **URL:** https://community.mp3tag.de/t/please-support-the-itunes-variant-extension-m4p/16993 **Category:** General Discussion **Created:** [June 24, 2015, 2:39pm UTC](https://community.mp3tag.de/t/please-support-the-itunes-variant-extension-m4p/16993 "2015-06-24T14:39:41Z") **Posts on this page:** 1 **Showing post:** 6
### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino) #### Post date: [June 25, 2015, 3:45am UTC](https://community.mp3tag.de/t/please-support-the-itunes-variant-extension-m4p/16993/6 "2015-06-25T03:45:57Z")
> [@poster](#): > > If you do this Mp3Tag is able to show files with the m4p-suffix but you cannot write tags to these files. This would be interesting: as teh m4p-type is not supported natively, any added extension is treated as "not known" - but if it is a known extension (i.e. rename the file), MP3tag tries to open it with the algorithm for that particular file extension. I wrote a thread in the German section [/t/16918/1](https://community.mp3tag.de/t/16918/1) that described MP3tag's behaviour: if you modify an extension from e.g. mp3 to flac, you see no tags as apparentyl flac tags are expected. Any attempt to write flac tags then fails. Coming back to the original post: if MP3tag can read the tags after the m4p file has been renamed to mp4 then the situation is different as the OP is quite right: the extension m4p should be added to the known extensions and the tag-reading done accordingly. Or the internal computing in MP3tag has to be changed to read the file data instead of relying only on the correctness of the extension in the filename. As the OP found that other programs cannot cope with m4p as well and he found a workaround, it looks to me as though it is not a pressing problem. --- _[View the full topic](https://community.mp3tag.de/t/please-support-the-itunes-variant-extension-m4p/16993)._