FLAC Disc & Track numbering fields

Support
1

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 page
So 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.

2

As a workaround for the UI issue, in order to make MP3Tag display what's actually contained in my flac fields, I've defined columns as follows:

DISCNUMBER  | "Disc"  |  $if(%totaldiscs%,%discnumber%/%totaldiscs%,%discnumber%)
TRACKNUMBER | "Track" |  %track%/%totaltracks%

Note that the files themselves have no "TOTAL" fields at all, as a result of the following mapping table:

Tag              Source       Target
VorbisComment    DISCTOTAL    TOTALDISCS    
VorbisComment    TRACKTOTAL   TOTALTRACKS

As a side note these two match Foobar2000's mapping for converting to MP3

Tag              Source                  Target
VorbisComment    ORIGINAL RELEASE DATE   ORIGYEAR    
VorbisComment    CONTENT GROUP           CONTENTGROUP

while these of course are the shipping defaults:

Tag              Source         Target
VorbisComment    DATE           YEAR    
VorbisComment    ORGANIZATION   PUBLISHER    
VorbisComment    TRACKNUMBER    TRACK

Of course it's quite possible I still am very confused about how to use this feature properly, in which case I'd be very grateful for someone who knows more than I setting me straight so I stop confusing those even noobier than me.

3

There is no internal mapping of DISCTOTAL and TRACKTOTAL fields. I don't know how you come to this conclusion.

There also is no automatism that splits Track=1/3 in Tracknumber=1 and Tracktotal=3

So except for the mappings flac tags are processed literally.

4

Sorry if I wasn't clear - the "automatism" I'm seeing is the other way around - I am entering the data in separate fields as far as MP3Tag is concerned, but the actual tags in my FLAC files (which you have to use another program to view) is showing no "total" fields at all and the 1/3 syntax in the "number" fields. Perhaps this is coming from TOTALDISCS and TOTALTRACKS, which after all I have mapped to my preferred strings.

If you're saying what I'm reporting isn't happening, perhaps when I have time I'll start with a virgin install of MP3Tags and document my steps to reproduce what I saw.

To simplify the question, what I would like is to use DISCTOTAL and TRACKTOTAL as the actual tag strings in my FLAC files, and (ideally) also use these as field labels within the UI, scripting etc within MP3Tag for not only FLAC, but also the other file formats. My understanding is that is the purpose of the mapping feature, but I can't seem to be able to accomplish that (Question 2 above).

An alternative solution is to use the XX/YY syntax as spec'd for ID3 TRCK in TRACKNUMBER and DISCNUMBER, which is what is currently happening in my MP3Tag setup without my having intended that. In which case my question 7 pertains.