The following question arose in the context of Mopidy-Local-SQLIte, but since it applies to Mopidy’s data model in general, it may be of interest for other backend developers, too:
mopidy.models.Album contains the properties num_discs and num_tracks. The documentation for num_tracks states: “The number of tracks in the album.”
If I understand this correctly, this means the total number of tracks in an album spanning multiple discs. For example, if I have a dual-disc album with 11 and 14 tracks on each disc, respectively, the correct value of the album’s num_tracks would be 25. Yes?
Now, in the context of Mopidy-Local-SQLite (or any local library for that matter), where num_tracks is extracted from the media files meta data (i.e. GST_TAG_TRACK_COUNT), the value of track.album.num_tracks often gives the number of tracks in the respective disc, not in the whole album. I checked with multi-disc albums purchased from Amazon, Google Play and iTunes, and all report the number of tracks of the disc (as given by track.disc_no) when imported via mopidy local scan.
So, how is a local library, or in fact any backend that supports multi-disc “album” models, really supposed to handle this correctly?
The use of “album” over “disc” here isn’t intentional, we just didn’t think much about albums with multiple discs. I’m very open to adjusting the definitions here. What do you think would be a good and complete enough model?
@jodal: Well, I don’t have a solution to this yet, that’s why I brought it up for discussion. We’re pretty much limited here with what we get from gstreamer, and what the various file metdata schemes (IDvX, VORBIS comments, etc.) define, and I’m no expert on that subject. So I’d welcome any suggestions, e.g. by examples of how other media applications handle this mess.
BTW: This popped up just recently, since I usually use beets to manage my local media, which assigns tags to multi-disc releases just like I think Mopidy (or Mopidy-Local-SQLite) expects them: num_tracks becomes the total number of tracks, track_no becomes the track number within the “album” (MusicBrainz release), and disc_no is “for information only”, but doesn’t affect anything else…
I tend to err towards follow what Musicbrainz does as I don’t have any strong opinion about this I would rather we not repeat mistakes others have made before us.
After pondering this for a while, I think what really gives me troubles in the context of Mopidy-Local-SQLite is that num_tracks is a property of Album, while disc_no is a property of Track.
Since I don’t know whether a track’s num_tracks tag refers to the whole album/MusicBrainz release (as when tagged with beets) or refers to the disc the track belongs to (as it seems to be the case with tracks from iTunes, Amazon, etc.), I cannot properly determine Album.num_tracks (which I think should reflect the total number of tracks across discs) from that information.
So, at least for Mopidy-Local-SQLite, it might make more sense to keep num_tracks with the track information, and not store a num_tracks for multi-disc albums at all. Will have to do some prototyping to see how this turns out, though.
Support for multidisc was definitively an after thought and doesn’t quite fit in how we have modeled things. Which is probably why we ended up repeating a mistake I’m sure others have made before us. One of the things “blocking” a 1.0 in my head is adding our “magical” lookup API that “fixes” mistakes like this by providing a better metadata model.
So in short I don’t have any good answer for this currently
