# Google Play Music not recognizing embedded cover art
**URL:** https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651
**Category:** Support
**Created:** [June 10, 2019, 6:33am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651 "2019-06-10T06:33:54Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@xpadrex](https://community.mp3tag.de/u/xpadrex)
#### Post date: [June 10, 2019, 6:33am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/1 "2019-06-10T06:33:54Z")
For about a year now, any mp3 files I upload into Google Play Music that I have edited with MP3Tag do not show any artwork. I have to go manually add the artwork. It used to work fine. I thought maybe it was something on the Google side, but then I found out mp4 files DO display the embedded cover. I just downloaded tag & rename to do a test, and sure enough, the files edited with T&R showed the cover art in GPM just fine. Is this unique to me? Is there a setting I need to adjust? I don't want to go back to T&R.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 10, 2019, 7:09am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/2 "2019-06-10T07:09:29Z")
The easiest way would be to compare the files that show cover art and those that don't.
Use the extended tags dialogue for that (alt-T)
and pay particular attention to the tag versions that you find, read, write and delete.
You can filter for the property of embedded pictures with
%\_covers% MISSING
which shows all files that do not have embedded covers or with
%\_covers% PRESENT
for files that have embedded covers.
---
### Author:  [@xpadrex](https://community.mp3tag.de/u/xpadrex)
#### Post date: [June 11, 2019, 4:31am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/3 "2019-06-11T04:31:53Z")
When I compare the ones that upload the art successfully, the cover type is set to "Other". The ones that do not upload successfully are set to "Front Cover". However, if I cange the type from "Front Cover" to "Other", it just reverts back to "Front Cover" when I save. I cannot seem to save a change of cover type.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 11, 2019, 4:49am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/4 "2019-06-11T04:49:55Z")
I cannot reproduce this. I can change the cover type to any typ I like including "Other".
But as "Front cover" is a valid attribute for embedded covers in MP3 files, I think that this is a bug in the player.
Or your files are somehow up the spout and it would be worthwhile to check them.
See [How to check files for errors?](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633)
Which tag types have you got in the files? ID3? APE?
---
### Author:  [@xpadrex](https://community.mp3tag.de/u/xpadrex)
#### Post date: [June 11, 2019, 5:38am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/5 "2019-06-11T05:38:08Z")
Definitely not the files. Literally 1000's of them would have to be bad.
Tags in files say APEv2 (ID3v1 ID3v2.4 APEv2). Is that too complicated?
---
### Author:  [@xpadrex](https://community.mp3tag.de/u/xpadrex)
#### Post date: [June 11, 2019, 5:39am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/6 "2019-06-11T05:39:31Z")
I just saw another thread saying APE tags can be an issue. I'm gonna mess around with that. I'll let you know what happens.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 11, 2019, 5:48am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/7 "2019-06-11T05:48:28Z")
and another thing: at least Windows has a problem with V2.4 tags. It would be better to use V2.3 tags.
> [@xpadrex](#):
>
> Definitely not the files. Literally 1000's of them would have to be bad.
A quick check with the linked utility "mp3val" would have told you that there is garbage at the end of a file which is an indicator for APE tags....
---
### Author:  [@xpadrex](https://community.mp3tag.de/u/xpadrex)
#### Post date: [June 11, 2019, 6:00am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/8 "2019-06-11T06:00:23Z")
I'm just gonna state the obvious and say I'm too dumb to understand a lot of this, though I am making progress! So in the utility when it says "Wrong number of MPEG data bytes specified in Xing header (5482608 instead of 5480306)" is that the APE garbage?
I really appreciate your help with this.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 11, 2019, 6:11am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/9 "2019-06-11T06:11:22Z")
> [@xpadrex](#):
>
> Wrong number of MPEG data bytes specified in Xing header
No, this is an indicator that (perhaps during ripping) the header for the variable bitrate was not written correctly - a slight indicator that not really all files are OK.
---
### Author:  [@xpadrex](https://community.mp3tag.de/u/xpadrex)
#### Post date: [June 11, 2019, 6:11am UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/10 "2019-06-11T06:11:26Z")
You did it. It's working now. For anyone else who comes across this, Google Play Music wants ID3v2.3 tags. I used UTF-16 and cover art is now showing. All credit to ohrenkino!
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:28pm UTC](https://community.mp3tag.de/t/google-play-music-not-recognizing-embedded-cover-art/45651/11 "2026-02-09T12:28:07Z")