Support release group types

[phw]

It would be good if providers could set the primary type and if this would be seeded when submitting to MB.

Not all providers will support this, but it is sometimes possible to at least detect singles and EPs. If in doubt a provider should likely keep this field empty.

Some notes on specific implementations:

1. iTunes: No specific support, but the suffixes - Single and - EP seem to be commonly added to singles / EPs. These should be stripped (see #9) and then can be used for seeding the primary type as well. a-tisket does this.
2. Spotify: Releases have the field album_type, which is one of album, single or compilation. Maybe it is too broad to use the album type (better leave it empty and have the user decide), but single and compilation should be fine to use.
3. Bandcamp: At least standalone tracks could be detected as "Single".
4. Tidal: no types specified
5. Guessing the release type from title might work in many cases. Most of the MB submission user scripts do this, see https://github.com/murdos/musicbrainz-userscripts/blob/master/lib/mbimport.js#L302-L325
6. For any provider making use of the MusicAlbum schema there is a MusicAlbumReleaseType. Theoretically this supports the types AlbumRelease, BroadcastRelease, EPRelease and SingleRelease. But e.g. Bandcamp does not make full use of this and seems to use AlbumRelease generally, except for standalone tracks it uses SingleRelease.

Generally it seems that if specific types, in particular single or EP, are detectable, this could be seeded. In most cases a source type of "album", if given, might be too unspecific and better kept out.

In the release editor the primary type can be seeded using the field type.

[kellnerd]

Thanks for your detailed thoughts, I agree with almost all of them. Since we likely also want to use "Compilation" and other secondary types, I would add an array/set property to HarmonyRelease which accepts both primary and secondary types and let the MB seeding code deal with the MB specific handling of these.

[phw]

"Live" is also something that could be potentially be detected. I haven's seen live tracks explicitly marked as such in APIs, but in many cases you find a suffix like "(live)" on the track or even release titles. If the release has this or if all the tracks have it then it seems safe to set the live type.

[phw]

I'll look into this one

[zas]

Some platforms use "Single" (iTunes I think) for what's clearly "EP".

Definitions of those are rather fuzzy but from my experience the most common cases are the following:

• 1 to 3 tracks with a duration < 10 minutes or single in the release's title, usually a single
• 1 to 6 tracks with a duration < 25 minutes or EP in the release's title, usually an EP
• more than 6 tracks and duration > 25 minutes or album|full length in the release's title, usually an album

Some cases are tricky:

• 1 long track of 20 minutes can be either a single or an EP, but almost never an album
• 1 long track of 45 minutes or more is usually an album

Number of tracks, duration of individual tracks, total duration, similar track titles give hints too.

title 4:00 title (remix) 5:32 title (edit) 4:05

would be a single (+remix) but:

titleA 4:00 titleB 5:32 titleC 4:05

more likely an EP.

Of course, since definitions of single/EP/album are not very clear, we cannot be sure in all cases. Sometimes that's what's the annotation says: On Bandcamp, we can often read annotations like: Our second studio album.... or First EP, and those doesn't always match the guess guidelines we have above. I saw bands calling EP an 10 tracks 1 hour long release, and Album a 2 tracks 10 minutes long release.

[phw]

@zas I think because EP is so vague the best rule of thumb for EPs is to only use it if the band or label explicitly call it an EP. Otherwise it is more likely a single or album. I'm not sure whether Harmony really should set a type guessed from track count and length.

IMHO it is better to not preset a type at all in those cases and have the user choose themselves. Maybe one way would be to use the track count / length as indicators, but only to unset the type if it does not seem to match.

titleA 4:00 titleB 5:32 titleC 4:05

more likely an EP.

Not sure about this rule, really. I have seen singles that had, two or even three extra tracks. Often one of thee tracks at least is some kind of variation (remix, instrumental version, orchestral version etc.) of the main track, but not always. Hence I think it is then more about presentation. If it is marketed as a single and e.g. is named after the single track on the cover, maybe with a sticker that it contains "bonus tracks" then I would go with single. If it has a name distinct from the individual song titles and more looks like a small album it probably is indeed an EP.

[zas]

I think because EP is so vague the best rule of thumb for EPs is to only use it if the band or label explicitly call it an EP.

Actually all definitions of "release group type" are rather "fuzzy", not only EP (https://musicbrainz.org/doc/Release_Group/Type).

I agree, but we'll likely end with a lot of empty release group types. That's always a dilemma, if we prefill a field, it might be incorrect, if not, users will forget to set it even if there's an obvious value.

A typical case for me is when the title do not show "EP" on digital stores but it appears clearly on the cover art. Guessing "EP" based on durations/number of tracks works more often it doesn't.

Not sure about this rule, really. I have seen singles that had, two or even three extra tracks.

That's not a "rule", but rather an observation, and I posted another example with same durations but different titles which is a single, so I agree with you.

[kellnerd]

@phw Have you already started working on this? I am implementing a MusicBrainz provider (#49) where it would make sense to prepopulate the RG types, but I can also skip this for now if you have already prepared something.

[phw]

@kellnerd I do. I can also open a draft PR with what I have and have this for discussion and coordination with your work.

Out of interest: Is the MB provider also considered the solution for finding existing MB releases, so the user can be notified that a release already exists?

[kellnerd]

A draft PR would be nice to see, although I just realized that I will probably let the MB provider set the RG MBID rather than the RG types 😇 It would still be useful to show the RG types, but that can easily be done as a second step once you are ready (or once I am ready, I haven't yet decided how big the scope of my MB provider branch will be).

Is the MB provider also considered the solution for finding existing MB releases, so the user can be notified that a release already exists?

That's the idea, at least for the GTIN this should work without additional effort. I haven't yet decided whether I want to also do MB lookups for the external links of the other providers like a-tisket does it. The more providers are used for the combined lookup, the more potentially useless requests would be sent to the MB API. Especially since most of the time people will probably import a specific release which is missing on MB rather than trying to import a release which may already exist on MB.