I found this topic, but I'm not totally agreeing with what got mentioned there.
This is with regards to MP3 and the use of ID3v4
When you define a column, the field list shows TOTALDISCS and DISCNUMBER as available fields.
This raises the expectation that each will always retrieve the corresponding value. No matter if they're stored as combo in a TPOS frame, or only DISCNUMBER in the TPOS frame and TOTALDISCS in a TXXX frame (which should only exist if TOTALDISCS was entered before the TPOS frame existed)
I noticed there's a difference here in how MP3Tag and Foobar2000 handles these.
In MP3Tag, if I have defined columns with these fields and manually enter data in both, DISCNUMBER gets stored in a TPOS frame, but the TOTALDISCS gets stored in a TXXX frame even if theTPOS frame is already present and filled.
This is contrary to how Foobar2000 handles this, which stores TOTALDISCS also in a TPOS frame in the format disc#/discs (e.g. 1/4) if the TPOS frame is present.
The only way in MP3Tag to get the TOTALDISCS value stored together with DISCNUMBER in a TPOS frame is to use the Auto-numbering Wizard. And here's the rub. If I use the wizard, MP3Tag shows the DISCNUMBER column as disc#/disc and the TOTALDISCS column stays empty. Foobar2000 however just shows only the DISCNUMBER when asked for %discnumber% and only shows TOTALDISCS if asked for %totaldiscs%, it never shows them as x/y unless you specifically format a column to do so.
So, there is inconsistent behavior in filling TOTALDISCS via a column vs having that value entered via the wizard.
I could get around the display of disc#/disc in MP3Tag with some formatting, but that doesn't solve the issue of the same values ending up in two different frames when entered manually vs when entered through the wizard.
@Florian Is there a specific reason to have these values treated different depending on how you enter them? Any chance we can get the DISCNUMBER column to just show the DISCNUMBER and have TOTALDISCS retrieve it from either the TPOS frame or TXXX frame (whichever of the two exists)? And of course have TOTALDISCS stored in the TPOS frame if it exists and is entered manually?
Consequently, if the TOTALDISCS value is currently stored in a TXXX frame, and you write out the tags again, it should store it in the TPOS frame if DISCNUMBER is present and remove the TXXX frame.
The difference is in the format specifications between the different file types. As you have pointed out, the ID3 standard for mp3 files uses a single field with track/totaltracks and the same for the disc count. Other formats like FLAC, m4a, etc use distinct separate fields.
For users with libraries that have a mix of formats, how would one distinguish between those with separate tags and those that are combined?
That would be determined by the specs of the respectives formats. but that is not the issue, the issue here is the difference in behavior when using the auto numbering wizard vs manual entry.
I assume the auto-numbering wizard takes different formats into account, so individual columns could/should do the same thing, besides that, there's the User-defined mapping option for formats that don't specify a particular way these values should be stored. Foobar2000 can handle it perfectly, so there shouldn't be a problem for MP3Tag to do likewise (especially given that @Florian is a mod in the Foobar2000 forums and knows how Foobar2000 handles it).
EDIT: Besides that, there is no reason to deviate from the standard for MP3 when dealing with MP3 for the sake of other formats. Each format should be treated according to the standard defined for that format, and for MP3 that is to store TOTALDISCS in the TPOS frame if it exists
I know, but @Florian said there is no automatic splitting when writing the values, and this is how it should be. But that does not mean it should also apply to reading the values.
And that still leaves the difference in behavior between the two ways you can enter TOTALDISCS
EDIT: How it looks on the front end should be consistent, regardless how it is handled internally.
If a column defined as TOTALDISCS is read for one format, it should be used for other formats to, regardless of how that information is stored in the actual file.
Also, that topic is from 2019, before there even was an ID3v3 or ID3v4. Things have changed since then
If you work with the default list of fields, then there is no TOTALDISCS.
TOTALDISCS looks like a user-defined field to me which is added to the list of fields once the user has entered it as field name.
is another indicator for a user-defined field.
Users who add TRACK and DISCNUMBER to their columns see all the data in these fields, the current item and the totals, if set.
The comparison to foobar2000 is not really valid, I would think.
If you enter a disc number like 1/3 (not disc number and total discs separately), then the display in foobar stays like that until you press OK or Apply. When you review the data, the data is split into disc number and total discs.
If you look at that file in MP3tag then the discnumber displays as 1/3 which is accurate and according to standard.
Coming back to the TOTALDISCS field: there is no link between a user-defined field and a standard field.
Similar names in MP3tag and Foobar2000 are coincidental, IMHO.
THis is not quite correct: if you set the values in the field DISCNUMBER according to standard, you also see the total number of discs.
Any user-defined field called TOTALDISCS does not get updated, though - as there is no relation.
I'm not sure where you are getting reference to ID3v3 or v4. I am not aware of anything to do with these. If what you are talking about is ID3v2.3 and ID3v2.4, these standards have been around since 1998 and 2000 respectively.
This is how mp3tag correctly handles the total count of tracks and discs. However note that you certainly can also create the user-defined fields of TOTALTRACKS and TOTALDISCS in mp3 ID3v2.3. I use an action for this to ensure all of my files are consistent for filtering, etc.
I don't have too many mp3 files left in my library now. I have ripped all of my CDs to lossless with separate tags. But for those that remain from some vinyl rips I have yet to update, I have used mp3tag to complete the spec compliant x/y info and then run an Action to format the total as well. I can dig that up and add it here. It is easy to do. But I don't think it is an assumed function that mp3tag should do in all cases.
TIL that I've been ignoring the id3 spec for decades by using DISCTOTAL instead of TOTALDISCS and TRACKTOTAL instead of TOTALTRACKS and always splitting the values of TRACK and DISCNUMBER, regardless of the format.
Anyhow: if you do want to populate the TOTALDISCS value I have an action that achieves that.
Action Type: Format value
Field:
This leaves TOTALDISCS alone if it's already populated and only populates it with the part behind the slash of DISCNUMBER. You can easily adjust it to do the same for TRACK and TOTALTRACKS.
If you (like I did unknowingly) want to go against spec you can also add a second action
Action Type: Format value
Field:
DISCNUMBER
Format string:
$num(%DISCNUMBER%,1)
That would remove the part after the slash and the slash and also remove zero padding.
Example:
DISCNUMBER = 3/4
TOTALDISCS unpopulated
Would become:
DISCNUMBER = 3
TOTALDISCS = 4
after running these two actions. Which in case of mp3 files would go against spec by storing the DISCNUMBER in the appropriate frame and the TOTALDISCS as TXXX.
This works in some cases. However you will find there are some player and library apps where this breaks.
IIRC iTunes was one of them at one point. Not sure if they ever bothered to fix it. One of the Android apps I reviewed here sometime ago also had an issue if the format wasn't x/y.
You know what they say about specifications…
…they are like any other rules and are meant to be broken!
I probably never noticed it because it breaks way before that for my files. When I started out 20ish years ago, the easiest way teenage me found to consistently get all players (software and hardware) to recognize multi disc albums was to simply append [Disc 1] or [CD 1] to the album tag. Which I still do (with an action) to this day for consistency reasons.
When getting an SSD that can fit my entire library without bankrupting me becomes an option I'll probably revert that step globally and also exchange DISCTOTAL for TOTALDISCS and TRACKTOTAL for TOTALTRACKS, among fixing a few other legacy tagging decisions made over the years.
And some broken things work well enough to remain broken for decades.
which translates TPOS (part of set) more or less literally as "Teil eines Satzes". So there is also not TOTALDISCS - which is no surprise as the Windows Explorer cannot deal with user-defined fields.
I think that Foobar has a problem with displaying the data accurately.
In MP3tag I set DISCNUMBER to 3/4 and added a field TOTALDISCS with the value 5.
That looks like this in MP3tag:
If I look at the same file in Foobar it looks like this:
Right now, I get 2 values for Total Discs - which is not what it is in a hex editor that clearly shows 4 and 5 in 2 fields - as entered by the user
So right now, I cannot find out whether I have a user-defined field or a standard field.
If I delete the 4 in Foobar, then the 5 is kept in the user-defined field which makes it even more puzzling for me as now 2 kinds of data format look the same in Foobar.
MP3tag still shows a DISCNUMBER, now stripped by the 4 and a user-definded field TOTALDICS with the value 5
To sum it up: I think the problem lies in Foobar.
You have both, but only you can tell which is the correct count, 4 or 5 discs.
What I do know is that FB2K will write TOTALDISCS as a TXXX field if there's no DISCNUMBER (TPOS) field and will write it as the /N part in TPOS if DISCNUMBER does exist. So if you first entered the TOTALDISCS value, without adding DISCNUMBER at the same time, it will create the TXXX field as in your screenshot, it won't remove it though if you later add DISCNUMBER.
However, if you modify the value of TOTALDISCS after DISCNUMBER exists, there's a chance it will write that new value to TPOS instead of updating the TXXX field (I haven't tested this but seeing the discrepancy this sounds like the most obvious)
If you now have both versions and they differ in what they contain, then the only way to get TOTALDISCS written to TPOS instead of TXXX, is to first delete TOTALDISCS, apply the change and then re-add it, since there is now also a DISCNUMBER (in TPOS) it will write it to this field as the /N part. Be advised that if you do this with MP3Tag, you'll re-introduce the TXXX field again...
