STYLE-777 asks to make official what we already usually do: drop “(bonus track)” from the end of track titles, and remove, say, “(Queen cover)” from the end of a track like “Ogre Battle (Queen cover)”, replacing it with a cover relationship to the appropriate work. The first of these has already been enforced by Guess Case for basically forever, while the second is AFAICT generally understood as “not part of the title, just the best way this info can be printed in a release, but we can do better”. That said, before turning both into official guideline material, I thought I’d ask if someone thinks this is a terrible, terrible idea and we should always keep these bits if printed.
Is that ticket reference correct? I’m not understanding the connection.
2 Likes
I wonder if “(bonus track)” actually gives any valuable information.
Usually that’s an implicit reference to a previous release not having those, but which one… Typical case: a CD is released, the digital version has 2 bonus tracks on iTunes (compared to the CD), but only one on Bandcamp (compared to the CD release), etc… and then another CD is released, called “Deluxe” which includes 4 additionnal tracks, but those aren’t called “bonus tracks”, eventually that’s the original CD + a bonus CD, etc… Of course, bonus tracks aren’t always at the end, and sometimes bonus tracks are said so, but there’s no release without them.
Bonus track by itself doesn’t say much, for me that’s a marketing argument more than a real thing; so i’m perfectly fine removing it from title (“not part of the title”), and drop this information, as it doesn’t help much anyway.
For covers, the main issue for me is the following, see this example:
It isn’t really obvious this is a cover of Scorpions song “Still loving you”, because “Scorpions” doesn’t appear anywhere …
Also when adding a new track (and recording), one has eventually to create the matching “original” work (without having much information about it), to be able to set the cover relationship, that’s a long process.
I already met the case where artist was attributing the original song to incorrect artist: an artist A covers a song played by artist B, ignoring it is a cover of a song by artist C, you have “title (B cover)” where it should be “title (C cover)”. Always hard to sort out (because a cover of a cover is legit too…).
Perhaps an additionnal field is needed, to store such info, which isn’t the track title, not a disambiguation, nor something that can be stored in a relationship.
4 Likes
With the script called INLINE STUFF, the text in recording comment appears nicely in the release page.
Cover recording comments would be OK, but bonus track info rather belongs to release annotation, IMO.
1 Like
Whoops. Linked to the wrong one. Fixed!
1 Like
Surely that information is available on the work that is linked to. Or are you suggesting that there is a “cover of” relationship between two recordings rather than between recording and work? That would seem to be implied by the notion of “cover of a cover”.
In any case, I agree with the notion that “(Scorpions cover)” does not belong in a track/recording title.
Existing relationships are fine, it is more about the way we display things: (Scorpions cover) is more obvious than (a cover of a work composed by Rudolf Schenker) … click / search … found it is the guy from Scorpions…
2 Likes
But putting that into ETI, or a new field on the recording, seems to me more vulnerable to the type of misattribution you cited above; it’s an isolated piece of information on that recording.
(When Tom Petty recorded Little Red Rooster, was that a Grateful Dead cover, a Rolling Stones cover, or a Howlin’ Wolf cover?)
1 Like
I’m in favour of omitting “(bonus track)” designations from the tracklist. One day, it would be good to be able use a heading for bonus tracks, like is possible on Discogs (related ticket: MBS-6680).
3 Likes
I’m in favor of STYLE-777.
There’s also compound cases, e.g. “previously unreleased demo.” What should we do about those? Should we truncate it to just “demo”?
2 Likes
I wouldn’t mind keeping grey-area cases as-is
2 Likes
I totally agree with that. 
1 Like
Looks like I never submitted this reply…
With covers, there is also the point that it’s not always correct to link to the original artist.
Somewhere along the way, an artist may have significantly altered the song in their cover. Later artists could then be covering that version specifically. And there’s not always a separate work created in such a case.
1 Like
I am relatively new (a year) and just finished assigning/creating a RID for all my albums along with adding discids and isrcs. A lot of what I added were obscure compilations, 4/3/2-on-2/1 albums, complete output of a group that did not make it, and so on. I see a lot of “mono”, “45 single”, “45 mono single”, “single”, “stereo”, “demo”, “outtake”, “previously unreleased”, “bonus”, “bonus track”, and the list goes on with sometimes “demo1”, “demo2”, etc.
I agree with “trying” to be true to the package/release but a line needs to be drawn somewhere for consistency and understanding what the release is presenting or how we are presenting the release.
IMHO
“bonus” is for the annotations, that’s where I put it, I do not understand its value on the tracklist or recording, its about the package/release not the recording/track.
“cover” is trickier because it is about the recording or work, still if major modification has been done to the work and a new work has not been created that is not a valid reason to place it on the track/recording, just create the work.
Saying that I also have to look at what the tracklist may do or not do to a tagger, if that matters here. That may be a different topic. I mention it because I just added a 4-on-2 release where each of the 2 albums on medium1 had the exact same song, so the song appears twice on the medium with no differentiation (future cleanup I guess).
For single, mono, mono45, stereo, etc, I only add to the track if it is needed to differentiate another track of the same name, the rest generally goes in the annotation. Demo, demo1, demo2, unreleased, outtake, etc are more tricky tricky as the convey what may not have existed before. The list goes on.
Just my 2 cents.
1 Like