# Request For Comments: Standard for MultiDisc Track Numbering
**URL:** https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956
**Category:** General Discussion
**Created:** [July 31, 2014, 10:26am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956 "2014-07-31T10:26:50Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Nature](https://community.mp3tag.de/u/Nature)
#### Post date: [July 31, 2014, 10:26am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/1 "2014-07-31T10:26:50Z")
**1. Motivations for this proposal**
1.1. The need for a _short_ numbering system (especially useful on MP3 devices), that will allow:
a. Sorting without the need for an extra field/tag (DiscNumber) which is not available on most hardware MP3 devices.
b. Files from the same Album to _always_ be on the same folder (whether it's MultiDisc or not).
1.2. Simplification of the process of identifying tracks, since it requires one less field/tag
to understand if the track is from CD 1, 2 or whatever.
**2. Purposed Method**
2.1. Tag Names:
Dsc# = Discnumber
Trk# = Track Number
Max = Constant (default=20) holding the Maximum number of tracks considered to pertain to the same CD/Album.
NewTrk# = The Track number according to this new purposed format.
The tag used for this will be the standard tag:
ID3(MP3)=TRCK, Vorbis(FLAC)=TRACKNUMBER.
2.2. For a Maximum of 20 tracks per DISC ==\> **Max=20**
**NewTrk# = [(Dsc# - 1) \* Max] + Trk#**
2.3. Examples:
**For Disc 1 (no changes, so it doesn't affect ONE disc albums):**
Trk# = 7, Dsc# = 1 ==\> [(1-1)\*20] + 7 = 0 + 7 ==\> NewTrk# = 7
Trk# = 15, Dsc# = 1 ==\> [(1-1)\*20] + 15 = 0 + 15 ==\> NewTrk# = 15
Trk# = 20, Dsc# = 1 ==\> [(1-1)\*20] + 20 = 0 + 20 ==\> NewTrk# = 20
**For Disc 2:**
Trk# = 7, Dsc# = 2 ==\> [(2-1)\*20] + 7 = 1 \* 20 + 7 ==\> NewTrk# = **27**
Trk# = 15, Dsc# = 2 ==\> [(2-1)\*20] + 15 = 1 \* 20 + 15 ==\> NewTrk# = **35**
Trk# = 20, Dsc# = 2 ==\> [(2-1)\*20] + 20 = 1 \* 20 + 20 ==\> NewTrk# = **40**
**For Disc 3:**
Trk# = 7, Dsc# = 3 ==\> [(3-1)\*20] + 7 = 2 \* 20 + 7 ==\> NewTrk# = **47**
Trk# = 15, Dsc# = 3 ==\> [(3-1)\*20] + 15 = 2 \* 20 + 15 ==\> NewTrk# = **55**
Trk# = 20, Dsc# = 3 ==\> [(3-1)\*20] + 20 = 2 \* 20 + 20 ==\> NewTrk# = **60**
**In Practice**
Just add 20 to the real track number, starting on the second CD:
CD 1: tracks 1-20 ==\> No changes, so CD 1 couldn't be simpler 🙂
CD 2: tracks 21-40 ==\> Just added 20 to the real track number.
CD 3: tracks 41-60 ==\> Added another 20... and so on...
This will support up to 5 CD volumes.
**Attached File**
For Advantages, Disadvantages and technical details, please download the attached text file with the full proposal text.
**Goals**
I intend to create two Actions to deal with this:
First: Transform the current Track number system into this new numbering system.
Second: An Action to revert it back, just in case there are exceptions not considered now.
I also intend to transform _all_ my (non-classical) music collection into this format, so it will have to be robust.
Since this might also be useful to other people, I thought about asking for your comments on this.
Do you agree or disagree?
Are there any other disadvantages besides the ones I already mentioned?
Do you know any modern music _Multi-Disc_ album that has more than 20 tracks on a single CD?
Any comments will be appreciated.
[PROPOSAL\_\_\_Standard\_For\_MultiDisc\_Track\_Numbering\_v1.1\_\_2014\_07\_31\_.txt](https://community.mp3tag.de/uploads/default/original/2X/7/795184b566b8ceb5f282a5efe35ff7a9b7abffe3.txt) (5.13 KB)
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [July 31, 2014, 10:54am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/2 "2014-07-31T10:54:08Z")
> [@Nature](#):
>
> ... Any comments would be appreciated.
Which tag type does support such a DiscNr/TrackNr encoding?
DD.20140731.1454.CEST
---
### Author:  [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [July 31, 2014, 10:58am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/3 "2014-07-31T10:58:40Z")
> [@Nature](#):
>
> ... Any comments would be appreciated.
What's about using an already established numbering system, ...
... allowing tracks from 1 to 99 for each data volume from 1 to 99:
## vvtt
0101
0102
..
0198
0199
0201
0202
..
0298
0299
... and so on ... until ...
9991
9992
..
9998
9999
DD.20140731.1458.CEST
See also ... [http://id3.org/id3v2.4.0-frames](http://id3.org/id3v2.4.0-frames)
> [@](#):
>
> 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 number of tracks/elements on the original
> recording. E.g. "4/9".
>
> 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".
Be aware of the Windows Explorer bug regarding the case of track number looks like an Octal Number.
DD.20140824.1106.CEST
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [July 31, 2014, 3:36pm UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/4 "2014-07-31T15:36:52Z")
> [@Nature](#):
>
> ...
> Trk# = 7, Dsc# = 2 ==\> [(2-1)\*20] + 7 = 1 \* 20 + 7 ==\> NewTrk# = **27**
> ...Any comments would be appreciated.
It looks to me as though the problem with this scheme would be that you cannot tell anymore whether you see a "real" 27 or a calculated one.
The whole business is awkward anyway even with DetlevD's numbering scheme (which I would prefer) that you once you have started with it, you have to apply it to every album:
Otherwise you have a lot of track that huddle up in the lower ranges of the decimal system (for 1-cd-albums) and others that always start above 101. This just looks strange if you have fairly ordinary numbers and also those big ones.
---
### Author:  [@flaminio](https://community.mp3tag.de/u/flaminio)
#### Post date: [August 3, 2014, 11:08pm UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/5 "2014-08-03T23:08:37Z")
Looks over complicated, but an interesting idea.
For my purposes, I ignore disc #s as simply an artifact of the recording media, and just number the tracks from 1 to N where N is the last track on the last disc.
---
### Author:  [@Nature](https://community.mp3tag.de/u/Nature)
#### Post date: [August 4, 2014, 9:11am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/6 "2014-08-04T09:11:24Z")
> [@DetlevD](#):
>
> 1. Which tag type does support such a DiscNr/TrackNr encoding?
>
> 2. What's about using an already established numbering system, ...
> ... allowing tracks from 1 to 99 for each data volume from 1 to 99:
>
> vvtt
DetlevD,
Thank you for your comments.
I took the liberty of numbering your questions for easier reading. I hope you don't mind. 🙂
1. Well, I meant the standard tag for storing the Track Number (On ID3 it's TRCK, on Vorbis it's TRACKNUMBER). The "encoding" is just a sum you do "manually", or better, using an Action, which is why they exist and Mp3Tag is so great. 😉
I'm sorry if that wasn't obvious. But I'll add that now.
2. I'm not sure if I know what "established system" you are speaking about.
a) Is it the one where we prefix the track number with the discnumber, as in:
Disc=1, CDTrack=4 ==\> TrackNumber=104 and
Disc=2, CDTrack=13 ==\> TrackNumber=213 ?
Actually it's the system I'm using right now, but it takes too much precious visual space.
It always requires at least 3 characters and sometimes as much as four(!).
Add to that a dot and a space as separators from the title and you end up with 5/6 characters, just for the track number(!).
I think that is a waste of precious visual space, especially in a tiny MP3 player's screen.
That is exactly why I thought about a different approach to replace that one.
🕶 If what you're speaking about is not that system, then please give me some guidance. 🙂
Is there any place where I can read about its specification and where is it being used?
---
### Author:  [@Nature](https://community.mp3tag.de/u/Nature)
#### Post date: [August 4, 2014, 9:50am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/7 "2014-08-04T09:50:08Z")
> [@ohrenkino](#):
>
> It looks to me as though the problem with this scheme would be that you cannot tell anymore whether you see a "real" 27 or a calculated one. [...]
Hi Ohrenkino!
Thank you for your comment.
The assumption is simple: there are (virtually) no Multi-Disc CDs with more than 20 tracks on each one. Assuming this, you can safely renumber every track on blocks of 20 (for each CD).
The explanation with technical details is on the attached text file.
I didn't put it here to not make the post too long. But you've got the explanation for why that is true, there. 😉
Perhaps the system is more easily understood in the following way:
Tracks ranges according to CD number:
CD 1: 1-20
CD 2: 21-40 ==\> just added 20 to the real track number. 🙂
CD 3: 41-60 ==\> just added another 20 to the real track number. and so on...
This will support up to 5 CD volumes.
However, as I state on the details (which you should read) this is only for Multi-Disc on Non-Classical music. Classical music groups pieces by Category: Orchestral (Symphony, Concerto, etc), Chamber (Duo, Trio, etc.), and so on.
This can easily allow a group of hundreds of pieces, like Haydn Symphonies, for instance (414 movements in all his 108 known symphonies!).
Nothing like this happens on modern music though, because it's usually is grouped by CD, which usually holds has between 8 to 14 tracks (the limit depends on time/length and not the actual number of tracks).
---
### Author:  [@Nature](https://community.mp3tag.de/u/Nature)
#### Post date: [August 4, 2014, 10:08am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/8 "2014-08-04T10:08:51Z")
> [@flaminio](#):
>
> Looks over complicated, but an interesting idea.
>
> For my purposes, I ignore disc #s as simply an artifact of the recording media, and just number the tracks from 1 to N where N is the last track on the last disc.
Thanks for you comment, Flaminio.
I already tried that and in most cases it would be the better system.
The only problem happens if you ever need to reorganise the tracks by their original order, and therefore need to restore the original track number.
With that method you simply loose that information, so it's a one way journey. ☹
I try to avoid those solutions, because you never know how tomorrow will be, what technologies will come up, trends, etc. Besides all that, you can always change you mind too! eheheh And that system won't allow a come back.
Of course you could save the original information on a backup tag, but that would require a second tag, which goes against my goal, of using just _one_ tag for the new system but always allowing a possible restore of the original values.
Please take a note on the new "In Practice" Section on my original post, which I just added, based on my answer to Ohrenkino. Perhaps it will make things clearer and less "mathematical". 🙂
I think this system, being different, requires some time to get used to it, as all things in life.
That's why it might sound weird at first. . .
I remember when the Euro currency came into circulation, many people thought it was awful. But it was just different! After a little time to get used, no one wanted to go back.
But there will always be a first time... and it will always look weird.
So I would ask people to try not to think about it being different, but rather if it can actually be useful or not, as you just did. Thank you! 🙂
---
### Author:  [@Scott85730](https://community.mp3tag.de/u/Scott85730)
#### Post date: [August 23, 2014, 8:10pm UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/9 "2014-08-23T20:10:21Z")
This is exactly what I'm looking for - and why I just joined this forum.
Any hope for this additional format term to be added to the scripting language?
s
> [@DetlevD](#):
>
> What's about using an already established numbering system, ...
> ... allowing tracks from 1 to 99 for each data volume from 1 to 99:
>
> ## vvtt
>
> 0101
> 0102
> ..
> 0198
> 0199
> 0201
> 0202
> ..
> 0298
> 0299
> ... and so on ... until ...
> 9991
> 9992
> ..
> 9998
> 9999
>
> DD.20140731.1458.CEST
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [August 24, 2014, 6:42am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/10 "2014-08-24T06:42:16Z")
> [@Scott85730](#):
>
> This is exactly what I'm looking for - and why I just joined this forum.
>
> Any hope for this additional format term to be added to the scripting language?
>
> s
I would think that this is already there:
Action of the type "format value" for TRACK
Format string: $num(%discnumber$,2)$num(%track%,2)
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [August 24, 2014, 6:52am UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/11 "2014-08-24T06:52:19Z")
> [@Nature](#):
>
> ...The assumption is simple: there are (virtually) no Multi-Disc CDs with more than 20 tracks on each one. ...
This assumption does not carry very far to my observation. It would fail frequently for audio books or audio plays. And even popular music does not comply, see for instance:
[http://www.discogs.com/Elvis-The-King-Of-R.../release/975793](http://www.discogs.com/Elvis-The-King-Of-Rock-N-Roll-The-Complete-50s-Masters/release/975793)
So, all in all I would say: there is no standard or the standard would be that players show the field discnumber.
If you have to misuse the track number, then everyone is down to one's own preferences.
Me, personally, I would hate to do mathematics to deduct the discnumber (here: divide by 20). But that is down to personal taste.
---
### Author:  [@Nature](https://community.mp3tag.de/u/Nature)
#### Post date: [August 25, 2014, 10:08pm UTC](https://community.mp3tag.de/t/request-for-comments-standard-for-multidisc-track-numbering/15956/12 "2014-08-25T22:08:57Z")
> [@ohrenkino](#):
>
> This assumption does not carry very far to my observation. It would fail frequently for audio books or audio plays. And even popular music does not comply [...]
>
> Me, personally, I would hate to do mathematics to deduct the discnumber (here: divide by 20). But that is down to personal taste.
Hi ohrenkino.
Perhaps I didn't make myself clear, but as I said in my first post, the system is only needed when there are more _than one_ CD on an Album, and of course, only for modern music, not classical, and much less audio books, which are not even music and therefore follow a completely different structure.
I presume you haven't read the attached file, because I explain it there exactly why I made that statement. 😉
Anyway, you wouldn't have to divide, but just _subtract_, which is quite simpler. 🙂
But I sure agree with you, that in the end, this is also a matter of personal preference.
That is why I'm trying to put my personal preference to second plan, otherwise I would stay with what I'm using (the same system DetLevd mentioned but with one less digit for Discnumber).
But I'm still not sure... eheheheh
That's why I need someone to really convince me of clear advantages of one or another "format", so that I can make up my mind. 🙂
But I do have another concern, which has to do with the global system that I'm creating for my personal use, in which I create a TrackID, that should identify each track uniquely. It is a number "concatenated" based on other data, such as the track number (ArtistID+AlbumId+TrackId). So, the less digits tracknumber has, the better. That is the other reason for me to want a shorter track number. 😉
Thanks for your help.