musicbrainz-userscripts
musicbrainz-userscripts copied to clipboard
murdos
Discogs importer does not handle grouped tracks properly
An example is the last four tracks of this Discogs entry:
https://www.discogs.com/Empire-Brass-Mozart-For-Brass/release/1996829
The musicbrainz entry for this is here:
https://musicbrainz.org/release/e82a4889-74af-48f1-8c08-366820b6915a
Is there actually 18 tracks ? If you have the CD can you provide the discid ?
I ask that because sometimes "grouped tracks" are splitted in tracklist but not on the CD, and since MusicBrainz doesn't support subtracks yet, titles (and durations) are joined to match the discid.
The main problem here is to distinguish the two cases from discogs listing. Can someone very used to discogs provides links to releases covering the two cases ?
Definitely 18 tracks:
e90f0612 18 150 20075 34508 41238 55323 63048 77148 100010 118963 138223 150115 167110 188578 196733 208633 234195 261535 270988 3848
I can only assume the tracks are marked as grouped in the discogs entry in order to avoid duplicating the piece title in each track. So far I've found several other similar entries with these grouped tracks, and in every case I've seen so far they have been real separate tracks.
In any case, even if it turns out that there isn't a fool-proof way to determine for sure that the grouped tracks are always really separate tracks, it seems a lot safer to err on the side of treating them as separate tracks, since it would be much easier to delete potentially extra tracks than to have to go manually create them and manually enter all the details (the track name, artist, etc).
I agree, this doesn't work at all: the release which was motivating the move appears to be in the same case, it has 12 tracks per disk, but importer join subtracks, creating only 4 tracks.
References: https://github.com/murdos/musicbrainz-userscripts/commit/45c0216ea060ea2dde3b821cb54e9428619869d4 https://www.discogs.com/release/5880212 https://musicbrainz.org/release/cd7ee0c3-ae2b-4d5e-b81d-12f7ac96185e/discids
https://github.com/murdos/musicbrainz-userscripts/commit/adf6c4fdca93e9f3cca647ebbbb7600310868091 https://www.discogs.com/release/1156598
I'll try to fix this mess as soon i have time for it if no one makes a PR for that before.
Same problem here with tracks 2-02a, 2-02b, 2-25a and 2-25b. https://musicbrainz.org/edit/54204039
Hey guys, is this bug not a resurgence of https://github.com/murdos/musicbrainz-userscripts/issues/31 (on which I just commented)? Anyway, it's quite an old one, and I'd love to see it fixed. :)
There is a fix #281 PR.
But it seems that, in Discogs, we will always have grouped tracks that should be 1 CD track and grouped tracks that should be several CD tracks.
I don't know if there is a guideline to differentiate the two cases over there. So we could stick to this definition, even if it is not always followed in practice?
Or if not, maybe we should have the option in the importer by having 2 import buttons?
Import as 12 tracks / Import as 18 tracks
@hirokobayashi, the patcher, is well aware of the 2 cases and even found a Discogs reference doc about it, so let's test their patch on both cases. 🤗
If a good heuristic can't be found to differentiate when subtracks should be separate or together, then I feel it should always assume they are separate, since it is much easier to delete/combine the extra tracks than add them back in if they are missing.
An option allowing the user the choice of which way to import probably be preferable, if it can be done cleanly/easily.
It's just that on a CD, tracks are digits. If you have digits.digits, it should be one track as it's track.index.
But if there is a header followed by simple digits, it's several tracks.
I've fixed this for classical albums in a really hacked together fork here: https://github.com/kaysond/musicbrainz-userscripts/blob/discogs-classical/discogs_importer.user.js
