Vinyl (and cassette) releases are typically numbered along the lines of A1, A2, B1, B2 or A1, A2, AA1, AA2, such as in http://www.discogs.com/release/39538 and http://www.discogs.com/release/34352 The letters mark the sides, which is something we're currently missing.
I would presume that we'd need to add another column to the track table to store these numbers in and then track.position would keep the integer number we currently have so that tracks are always in the right order.
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
or (mostly vinyl) releases intended to be played and flipped as a stack:
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.
(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:
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
(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.