MP3 Tags not read for some files

Support
1

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:

     

2

Well this is strange:

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

3

Done: Gave you both an image of the screen where it works, and where it fails, with a description.

4

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.

5

Done: Both MP3 files, both detail images: One that works, one that does not. Same album, same directory, same SD card, same rip.

6

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.

7

Sorry my mistake: Requested images uploaded.

8

image
image1549×1516 75 KB

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
image1533×1520 80.8 KB

I’ll see if I can detect this case, but I doubt as V2 tags are always preferred since better.

9

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.

10

BTW checked the working one

image
image1546×1516 92.6 KB

And it does have the proper 2 version of the tags, so seems there was a bug in the ripping tool for some files.

11

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…

12

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.

13

Ok perfect then I have nothing to do as it would be too invasive to workaround.

14

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
That’s how I have mp3tag set up.

15

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?

16

I usually find Kid3 better to see the actual data, mp3tag hide too much things.

17

Will play with that over the weekend, and then report back here. thank you.

18

Kid3 solves the problem: Assumption would be that MP3Tag is messing it up…

19

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.