The obvious implementation would be to make track.position a text field. Do you know of any releases where normal alphabetical sorting would put things in the wrong order?

(Not that I oppose the solution offered by nikki mind, just considering alternatives for the sake of it

If track numbers are a text field, it won't be long before someone enters a release using "i ii iii iv v", "one two three four five" or "一 二 三 四 五" or something which wouldn't sort properly. That's not specifically vinyl-style track numbers, but if we make it possible then it's bound to happen at some point.

And free text fields are horrible to parse... I keep updating my discogs import greasemonkey because of that, to handle each and every different notation used

A summary of my thoughts on the issue:
Have new "Side" sub-objects within the "Disc" objects.
Each "Side" would have two properties: "Title" and "Track Number Prefix"

By default, a disc would contain one side with no title and no track number prefix set. This would behave the same as current NGS.

If a "Track Number Prefix" is set on a side, e.g. "A", it would be prepended to the track number of each track on that side, leading to numbering like "A1", "A2", etc. The numbers would still be automatically generated based on the track order. This might be a free text field, or maybe a drop-down list of options?
If a "Title" is set, it would be shown in a header above the tracks on that side.

I'd personally prefer to not change track.position to a text field, but instead add an additional field with the textual track number, as nikki suggested. We should have a strict validation of the textual track numbers though.

I'd like the "side" idea, but I'd like to add that:

Sides would be better as "parts", to fit releases (mostly digital releases) which have groupings which are not physically sides.

Arbitrary track numbering would be good, to fit releases which continue track numbers across discs, as
disc 1
track 1
track 2
disc 2
track 3
track 4

or (mostly vinyl) releases intended to be played and flipped as a stack:

disc 1
side 1
track 1
track 2
side 4
track 7
track 8
disc 2
side 2
track 3
track 4
side 3
track 5
track 6

To amend my previous comment:
I don't think it's absolutely necessary to have a more complicated medium-parts system right away; better track numbering is a good start, and can probably get us more than half way there

And a few more points:
1. Any time we might refer to 'sides' in MB, it's probably better to refer to 'parts' or something more generic, unless it's referring to a specific medium type that does have sides.

2. I agree with strict validation for these track numbers, and propose some guidelines for various medium types.

• All: prefix A or B for side, for media that have a real side.
• DVD: [title].[chapter]-[ audio track # (128, 129, 160, etc) ]
• CD: [track].[index] (index is 1 if unspecified)

Questions:

• Do we need to standardize on A and B? What about releases with "A and AA" (and even AAA)?
• What about releases with no real side order (e.g. early singles)? do we use A and B anyway, or just give them no track numbers at all?
• For DualDisc (DVD on one side, CD on the other): is CD side A or is DVD side A? I suggest CD first, but it should be standardized.
• Once this is implemented, should the "real" track numbers be hidden, or should they be copied to free-form track numbers? Or should both be given equal weight?

(Ignore this comment, it's wrong)

warp: As per http://blog.musicbrainz.org/?p=1301 having the ticket assigned to you makes you the champion of the ticket. If you're good with that, then all is well. If not, you might want to unassign this ticket.

rob: yes, that is intentional

'Once this is implemented, should the "real" track numbers be hidden, or should they be copied to free-form track numbers? Or should both be given equal weight?'

Do you mean existing track numbers ?

I think its imperative that both are displayed, and would prefer that the sequential numbering is shown first. Think of it like a spreadsheet where we always display the row numbers to the left regardless of what data is in the spreadsheet, and it's critical that these
track numbers are returned in the webservice as they currently are.

This ticket is under consideration for the May 15h schema change release. Please do the following:

• Specify exactly what the user interface changes will be. Mock ups would be great. Due date: April 2
• Specify exactly what the database changes will be. We will need to have an exact database table change proposal. Exactly which columns will be added/removed/modified and what new tables will be created. Due date: March 26

If Paul is suggesting that we should display both the position and the number on the website, I disagree. MusicBrainz isn't a spreadsheet. The position defines the order of the tracks and you can see that order by looking at the tracklist.

I do agree that it's important to return both in the webservice.

reosarevok wants me to add that he agrees with me.

This will be implemented as a free text field.

I'd like to implement this as a VARCHAR(255), to make sure there is enough room for weird edge cases.
ocharles prefers a much smaller field, e.g. VARCHAR(20).

I'd like to ask the community what the weirdest edge cases would be for this field?
What is the longest custom track number you know of?

Responding to Warp's open request for oddball track numbering, I submit

http://www.discogs.com/Mike-Patton-The-Solitude-Of-Prime-Numbers-Music-From-The-Film-And-Inspired-By-The-Book/release/3231490

(prime numbers only)

discussion @ http://musicbrainz.org/edit/15702456

This ticket is in danger of being rejected from the upcoming schema change release. Please provide UI mock-ups today.

This ticket is already in progress, so I suggest it is not rejected

I think the changes to our web services need to be discussed. Is this going to be stored in a new attribute or element? Will the integer track number be shown, or is that now just to imply ordering (but not position)?

The changes to the webservice have already been discussed on IRC. To not break /ws/2 clients no changes to existing elements will be made, so <track><position /></track> remains an integer and will not be removed from the output. A <number/> element will be added containing the new free-text track number.

Re "What is the longest custom track number you know of?"

I've seen 1a - 565j on a Sony production music DVD release.