Tag editing problems

[hh]

As long as this problem persists, I can't sync the files, that I sync from my PC to my phone, back to my PC. It would destroy tag integrity among files and remove information. Unfortunately, the problems also exist when just rating a file; so, I can't currently write ratings with GMMP.

I know of your Trello issue about total-discs support. But the problem actually lies deeper. GMMP shouldn't assume data formats when displaying tag fields in the tag editor or when writing them back to the file. (To what degree is Taglib to blame?)

My Previous Examination of the Problem

Foobar2000 has the field "Total Tracks" (complementing "Track Number"). It writes this into the "TRCK" ID3v2 frame as well in the format "1/9". GMMP just removes the total-tracks information when tagging. This even happens when just rating a file.

Nothing should ever be silently removed, even if it's not supported. Is this regard, I'm glad GMMP keeps the free-form "TXXX" ID3v2 frames unknown to it. But it should generally never coerce tag data into fixed formats when it comes to anything other than providing %expansion_variables%. In the tag editor, just display what's in the tag field, even if it's in an unexpected format. When writing, always write back what was in the file before, if not explicitly changed by the user (based on the exact original data), and not a falsified version of it.

For purposes like item order, GMMP can still interpret (probably via %expansion_variables%). But never let those interpreted values find their way back into the file!

Sometimes, people write special text in fields, like letters in the date/year field (e.g., "März '98" [= March 1998]), and that shouldn't disappear, just because I rated a track with GMMP!

---

GMMP also adds a number of contentless ID3v2 frames. This just seems unnecessary; but it has some implications on other software: MediaMonkey for Windows unnecessarily shows "LYRICS" with an empty value in its property dialog. Unnecessary ID3v2 frames, as written by GMMP, taken from hex editor:

TCOM.......TXXX.......LYRICS.TSOP.......TSO2.......TSOA.......TSOP.......
For MP4 tags (like in .m4a files), GMMP in my test unnecessarily added the following empty fields: "©lyr", "©wrt", "soaa", "soal", "soar", "soco". For "trkn" (track number), it changes Foobar2000's

00 00 00 20 t r k n 00 00 00 18 d a t a 00 00 00 00 00 00 00 00 00 00 00 01 00 05 00 00
...to GMMP's

00 00 00 20 t r k n 00 00 00 18 d a t a 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00
...(missing the total-tracks value 5). Disc number and total discs will have the same problem. GMMP also adds a second "free" atom chunk that's meant for padding; the Foobar2000-written file already contained one with 0x00 bytes; GMMP adds another smaller one in front of the previous with 0x01 bytes; would seem smarter and with less possible implications for other software or even itself to reuse/rewrite the existing padding chunk.

[GoneMAD]

"Foobar2000 has the field "Total Tracks" (complementing "Track Number"). It writes this into the "TRCK" ID3v2 frame as well in the format "1/9". GMMP just removes the total-tracks information when tagging. This even happens when just rating a file."

GMMP doesnt explicitly remove total tracks.. it just says tag->setTrackNumber(whatever), taglib must be doing it on its end

I dont disagree that it write empty tags isnt desired, but its how it was implemented for simplicity. Sure you could say "hey only write a tag when its populated", but then you have to put in additional logic to determine whether or not the tag exist and if it needs to be deleted. You are the first to complain about the excess tags in the 11 years GMMP has been around, so the majority of people clearly dont mind. I honestly didnt even know this was done until you pointed it out.

I do have a new tagging lib im working on which should be a bit smarter and read/write any arbitrary tag, but like the new audioengine i dont konw when it will be finished and integrated. The current tagging library only handles a fixed set of tags and will read/write them regardless as you've found out

[MotleyGord]

Feb 4, 2022 3:21:49 GMT -5 hh said:

As long as this problem persists, I can't sync the files, that I sync from my PC to my phone, back to my PC. It would destroy tag integrity among files and remove information. Unfortunately, the problems also exist when just rating a file; so, I can't currently write ratings with GMMP.

I'm not arguing that this issue exists. But I would share that in my own use case I would be hesitant to sync my library both ways between the home PC and mobile device. There are so many things on the go that can possibly have a negative influence on this. I just can't bring myself to trust my phone files to write back to my very carefully curated home library. Geeky I know. 

Doing it this way doesn't help if you are hung up on keeping your ratings and play counts updated. What I can tell you is that there are a couple of other premium Android players out there, and they also struggle with this idea, and currently do NOT write these back to the actual files. They keep a separate local database file only, so these details are lost if syncing the files back to your home PC as well.

I'm not sure there is an ultimate solution out there today that does this well.

 

[hh]

As I see, TagLib handles year and track number as integers. That's of course a big limitation, at least in this part of the API.

I do have a new tagging lib im working on which should be a bit smarter and read/write any arbitrary tag

But I interpret this as you'll be able to get/set custom string values for these fields.

[hh]

I would be hesitant to sync my library both ways between the home PC and mobile device. [MotleyGord]

I'm doing big backups every few months, and I would configure the syncing to ignore deletes coming from my phone.

[GoneMAD]

Feb 4, 2022 10:54:27 GMT -5 hh said:

As I see, TagLib handles year and track number as integers. That's of course a big limitation, at least in this part of the API.

I do have a new tagging lib im working on which should be a bit smarter and read/write any arbitrary tag

But I interpret this as you'll be able to get/set custom string values for these fields.

yea their "high level" api just treats them as ints. You can technically access tags at a per tag/frame level for each tag type, but i only did that for the tags not supported via their high level api

The new library just deals with the low level fames and returns them as it to the app. I believe most frames are text based, so that text would be kept intact

"TRCK
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9"."

[MotleyGord]

Besides the integer limits for track [TRCK], (plus the "/" to denote "of" i.e. x/y) the same applies to Disc number.

From the id3v2.org spec;
[TPOS] The 'Part of a set' frame is a numeric string that describes which part of a set the audio came from. This frame is used if the source described in the "TALB" frame is divided into several mediums, e.g. a double CD. The value may be extended with a "/" character and a numeric string containing the total number of parts in the set. E.g. "1/2".

There is further restriction for a valid year tag, an integer with 4 digits (at least for another 7,978 years or so);
[TYER] The 'Year' frame is a numeric string with a year of the recording. This frames is always four characters long (until the year 10000).

Some tag editors allow other text to be written to these frames, but they are outside of the spec and may result in some player devices showing incorrect information, or none at all.