-
New Feature
-
Resolution: Fixed
-
High
-
None
-
None
Before NGS a track could only ever be on one release, so the Track Id uniquely identified a track on a particulr release. With NGS tracks (now known as recordings) can be on multiple releases so the recording id (replacing the track id) no longer identifies a recording on a release.
To do that you now need to store the recordingid and releaseid, and then iterate through the tracks on the release to find where it on the release, but this is a bit of a pain.
Alternatively you need to store the trackno as well, the disadvantage of this is that whilst end user applications making use of Musicbrainz can hide the recordingid and releaseid the trackno is normally visible to the user, hence it can be modified breaking the link to Musicbrainz.
Another issue is finding of duplicates, now looking for duplicates purely by trackid/recordingid would delete the same song on two different releases which probably is not what users would normally want.
Both of these problems are easy enough to work round, but it would be alot easier if the track on a release could be allocated a trackid, and I wonder if there are situations whereby the lack of a trackid is really going to cause some headaches.
- is a dependency of
-
MBS-3815 Implement audio scrobbling natively into MusicBrainz
- Closed
-
MBS-6269 Expose track identifiers in the webservice
- Closed
-
MBS-6270 Expose track identifiers on the website
- Closed
-
SEARCH-285 Support for TrackIds in forthcoming Schema Release
- Closed
-
MBS-6023 Track MBID UI changes
- Closed
-
MBS-6069 Track MBID webservice changes
- Closed