This post pertains to the mapping feature in general, not just the specific fields discussed here,
and follows in a way this thread, which I wanted to stop hijacking.
I think I'm starting to get a handle on mapping, but recently came across MP3Tag behaviour I don't fully understand. I would like to use DISCTOTAL and TRACKTOTAL rather than TOTALDISCS and TOTALTRACKS, since these seem to becoming more of a defacto standard and they sort along with DISCNUMBER and TRACKNUMBER. When I create the former pair of fields, they appear to be internally mapped in MP3Tag, as I see my FLAC files are actually getting the the latter pair of field names. Question 1 - is that intended behaviour?
Side note - these are apparently undocumented on the mappings help pageSo of course, I go to the mappings feature and set up two rows for VorbisComment tags, the former pair as Source and the latter pair as Target respectively.
OK, so now the former pair of names should be what's actually written, but because of the internal mapping in combination with my user mapping, those names are now no longer available for me to use in the UI or formulas, right? (Question 2)
In other words I get the results I want in reality, but within the program I am forced to use the pair of names I don't want!
OK, not a big problem, can live with it in this case, however wrt general usage of the mapping feature, I've got to assume that this result is not what's intended? (Question 3)
So now I go check out the results in the actual FLAC files, and I see no such fields at all with either pair of names! Instead my DISCNUMBER and TRACKNUMBER fields are now formatted with the optional-in-ID3 spec of 1/17 and 1/2! Is that as intended? (Question 4)
I find this quite strange, as my understanding from the intertubes is that this convention, while the defacto standard for ID3, is quite unusual in the FLAC world - feedback please? (Question 5)
Another side note - this scenario gives another good example of why I think MP3Tag should give an option for users to see the actual native-format field names, not just the program's internal names - in this case MP3Tag is showing the data in separate columns for FLAC, but actually-as-stored for MP3. Again, most likely not intended, but I think feedback on the larger issue would be more useful (Question 6)However again, as long as it doesn't create problems with the various FLAC player/organizers out there (Question 7), for me personally this also isn't a big problem and I'm willing to adapt my personal tagging standards to fit with this behaviour.
If you've waded through all this thank you I hope it's all clear despite the multiple intertwined issues - I obviously don't expect full answers to all 7 questions, feel free to pick and choose those you feel are more important (or more relevant to your use case) than others.