I had a look but couldn't find a ticket which really covers this sufficiently. I dunno if I've just completely overlooked something, I know it's come up a bunch of times...

The problem:
Data tracks are ignored for the purposes of calculating a disc ID.
When a release has a disc ID, we force the tracklist to have the same number of tracks as the TOC.
Some CD releases are enhanced CDs with a data track containing extra content.
Since the data track is not part of the tracklist, this extra content cannot be included properly in the tracklist.

The current options:

• Ignore the data track entirely. This is what we've historically done, but it's been a long time since MusicBrainz was just a way of getting a tracklist when looking up a CD and it's hard to argue that we shouldn't be trying to track that information these days.
• Add the tracks to the tracklist anyway. This makes it impossible to add a disc ID, which means a duplicate release needs to be added without the data track in order to add the disc ID.
• Add standalone recordings, link them from the annotation. This works reasonably well if there's only one song in the data track, it's more annoying if there are multiple songs and either way it means the data track content isn't properly linked to the medium.
• Add a separate release for the data track, link it from the annotation. This works reasonably well if there's multiple songs in the data track, it's more annoying if there's only one and either way it means the data track content isn't properly linked to the medium.
• Add a separate medium to the release. This does get the contents of the data track included in the tracklist, but incorrectly part of a different medium, giving the release an incorrect number of mediums in total, making the positions of any later mediums incorrect and we don't even have an agreed upon (let alone unambiguous) way to mark a medium as being a data track.

None of those options work well at all, so how can we fix it? I can only think of a few things which don't involve schema changes:

• Drop the requirement for releases to have the same number of tracks as the TOC. A variant of this is probably the only reasonable way we can implement it, but without a schema change we have no reliable way of marking a track as being part of the data track, and if we don't know which part is the data track, that breaks stuff for disc IDs.
• Drop disc IDs entirely. That would be... drastic. It might be a solution for this problem, but would break everything that uses our disc IDs.

So the only option I can think of is some sort of schema change. The idea I've had in mind is an extra column on the track table which tracks whether a track should be considered for disc ID purposes and then any tracks at the end of a CD which aren't part of the disc ID are in the data track. The webservice could then quite easily move the excluded tracks into a new section to avoid backwards compatibility problems, like I proposed for pre-gap tracks in MBS-967.

As far as UI goes, I'm not too sure what the best option for editing in the release editor is. We could model it like a separate medium with its own track parser and add track functionality, we could treat it as completely normal tracks for the same medium (but then how does the user mark which bit is the data track?), or we could multiple sections in a single medium, one for the main audio part, one for the data track. One thing that does come to mind is that we could add enhanced CD (or whatever we want to call it) as a separate format which would imply a data track - that would probably make sense anyway for cases where we know there's a data track even if we don't know what's actually contained in it. Either way we should probably limit data track support to formats which can have data tracks. We can probably use the existing medium_format.has_discids for that, if not, I guess we'd need a new column on there.