# MP3 Tags not read for some files **URL:** \ **Category:** Support\ **Tags:** handled\ **Created:** [May 16, 2024, 3:38pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298 "2024-05-16T15:38:21Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 3:38pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/1 "2024-05-16T15:38:21Z")
## Issue description: Issue: Symfonium consistently does not read any of the MP3 tags, but consistently only for some files: e.g. Track number, Album, Artist Symfonium Version: 10.1.5B1 (12667) Also noted on the latest stable Synfonium release. Paid Environment: Samsung S10 Android. Also tried Samsung J8 Android, same issue Log File: Attached. Log covers a sync of the source, with only a single album loaded as an example, where it appears the MP3 file tag data is not being read Succeeded: 01 It seemed like a good idea at the time.mp3 Failed: 04 The ride to Agadir.mp3 Source: Local SD card. Identical issue noted with the same files read and not read when using WebDav alternative. Detail: The MP3 tags are not being read for a small percentage of files. The files were ripped by different methods (Windows Media Player, Audacity, and others), and some files within the same album are read, others not. The tags are definitely present, verified with MP3Tag, and Windows, and editing the tags does not change the issue. Accordingly the issue appears to be file related, since most files read consistently, as much as the files that don’t read fail consistently. Puzzling is that one cannot repair the issue by editing the tags with MP3Tag, or others. ## Logs: Upload description: redacted ## Additional information:     ## Reproduction steps:     ## Media provider: Local device ## Screenshots:       ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 16, 2024, 3:46pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/2 "2024-05-16T15:46:09Z")
Well this is strange: ```auto 2024-05-16 17:03:55.151 Verbose/TagParserWorker: Extracted tags for content://com.android.externalstorage.documents/tree/788A-8617%3AMusic/document/788A-8617%3AMusic%2FMike%20Batt%2FLady%20of%20the%20dawn%2F04%20The%20ride%20to%20Agadir.mp3 (audio/mpeg - content://com.android.externalstorage.documents/tree/788A-8617%3AMusic/document/788A-8617%3AMusic%2FMike%20Batt%2FLady%20of%20the%20dawn%2F04%20The%20ride%20to%20Agadir.mp3) ``` Can you show what the app displays for that song in the song list and when doing 3 dots then details? And can you upload that one to [https://upload.symfonium.app](https://upload.symfonium.app) ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 4:11pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/3 "2024-05-16T16:11:27Z")
Done: Gave you both an image of the screen where it works, and where it fails, with a description. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 16, 2024, 4:13pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/4 "2024-05-16T16:13:53Z")
I need the mp3 file and the details from when you browse inside the application in the song view and when doing 3 dots on that song then details. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 4:30pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/5 "2024-05-16T16:30:39Z")
Done: Both MP3 files, both detail images: One that works, one that does not. Same album, same directory, same SD card, same rip. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 16, 2024, 4:32pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/6 "2024-05-16T16:32:53Z")
Thanks but you uploaded the same images from the now playing not from 3 dots / details. Edit: No need I can reproduce with that 04 song will look into it. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 4:38pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/7 "2024-05-16T16:38:26Z")
Sorry my mistake: Requested images uploaded. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 16, 2024, 4:40pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/8 "2024-05-16T16:40:40Z")
![image](http://support.symfonium.app/uploads/default/original/2X/6/65d41304cef7fec611b2e16aaeacb51e091bdde6.png) The file have duplicated tags with the second being empty. Filling the second empty ID3 V2 tag with a copy of the V1 does fix this. ![image](http://support.symfonium.app/uploads/default/original/2X/c/c4b70d75f967266aee637eeb52397abc6efd6c23.png) I’ll see if I can detect this case, but I doubt as V2 tags are always preferred since better. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 4:46pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/9 "2024-05-16T16:46:01Z")
Interesting: In theory if I edit with MP3Tag and write both V1 and V2 it should read the V1 and overwrite the blank tag. Easy enough to batch that accros my whole folder tree. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 16, 2024, 4:47pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/10 "2024-05-16T16:47:47Z")
BTW checked the working one ![image](http://support.symfonium.app/uploads/default/original/2X/3/3eec9f76ca9698bd36145578b6759065d557ed5f.png) And it does have the proper 2 version of the tags, so seems there was a bug in the ripping tool for some files. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 4:48pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/11 "2024-05-16T16:48:11Z")
Almost sure that was written with MS Media Player perhaps 10 years ago: Quite likely a bug where it intermittently left the V2 tag blank… ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 16, 2024, 4:58pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/12 "2024-05-16T16:58:59Z")
Uploaded an MP3Tag settings image that fixes the file: Which proves you are 100% right. Thank you. Effectively this loads the V1 data, and overwrites the blank V2 data. ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 16, 2024, 5:00pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/13 "2024-05-16T17:00:53Z")
Ok perfect then I have nothing to do as it would be too invasive to workaround. ---
**Author:** ![655321](http://support.symfonium.app/user_avatar/support.symfonium.app/655321/32/1975_2.png) [@655321](http://support.symfonium.app/u/655321)\ **Post date:** [May 16, 2024, 5:27pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/14 "2024-05-16T17:27:00Z")
You might not even need a batch. If your mp3tag is set up correctly you should be able to simply: 1. Load all files that might have this problem into mp3tag (see if you can filter for it). 2. Select them. 3. right click → Remove tag 4. CTRL + Z or Edit → Undo Remove tag That should lead to mp3tag reading all supported existing tags, storing them internally when you delete them from the file and then rewriting them once you undo that step. I usually use this method when I encounter excess padding in mp3 files. Removing the tags and then letting mp3tag write them back often solves this. BEWARE tho that mp3tag for example does NOT support the dedicated SYLT frame where some mp3 software stores synced lyrics. I personally haven’t tested it but I would not be surprised if by removing and writing back the tags like I described, such lyrics would be lost. Or Florian anticipated this case and simply does not touch the SYLT frame. Only a test would tell but I don’t have mp3s with SYLT lyrics to test. Edit: forgot the image with my mp3tag settings for tag handling: ![mp3tag](http://support.symfonium.app/uploads/default/original/2X/b/b878069aa4924d9f4d1fc83a0553b99501d07f76.jpeg) That’s how I have mp3tag set up. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 17, 2024, 7:14am UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/15 "2024-05-17T07:14:31Z")
Perhaps not as easy as we thought… The track I tested on worked perfectly, using MP3Tag with the settings above, or the settings I used: The rest of the tracks mostly failed. MP3Tag reports (and reads) both a V1 and V2 tag, with populated data. I don’t know of another application that I can use to verify this. Writing back a V1, V2, or both tag does not solve the problem, or apparently change anything. Strangely if I add writing the APEv2 tag problem (apparently on my test sample) solved: So I yet (may) have a working solution. Difficult to know what to conclude: Perhaps MP3Tag leaves valid or invalid garbage? Or maybe the parser fails to read whatever mess Mp3Tag leaves behind? Any recommendations on another MP3 tag editor that may resolve where the fault lies? ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [May 17, 2024, 7:16am UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/16 "2024-05-17T07:16:53Z")
I usually find Kid3 better to see the actual data, mp3tag hide too much things. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 17, 2024, 8:19am UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/17 "2024-05-17T08:19:51Z")
Will play with that over the weekend, and then report back here. thank you. ---
**Author:** ![David](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/aeb1de/32.png) [@David](http://support.symfonium.app/u/David)\ **Post date:** [May 17, 2024, 9:15am UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/18 "2024-05-17T09:15:17Z")
Kid3 solves the problem: Assumption would be that MP3Tag is messing it up… ---
**Author:** ![655321](http://support.symfonium.app/user_avatar/support.symfonium.app/655321/32/1975_2.png) [@655321](http://support.symfonium.app/u/655321)\ **Post date:** [May 17, 2024, 1:44pm UTC](http://support.symfonium.app/t/mp3-tags-not-read-for-some-files/4298/19 "2024-05-17T13:44:17Z")
Interesting, I’d report that in the mp3tag forum if I were you. They’re usually very keen to find solutions, especially when messed up files are concerned.