Good call. I added RETRO FUTURE GIRLS as an example. (Aside: for track artists especially I’m trying to pick examples where we have all the cover art in MusicBrainz since it’s the best source to verify.) I also added a link to this page in Talk since it feels a bit meta for the page itself.
1 Like
I recently made an edit for this album because only 2/10 track titles were in Japanese, the rest were in English. But I‘m starting to doubt if this is the right thing to do for doujin albums.
In most cases I think it would be the correct thing to do, as per the style guidelines:
If several languages are used in the titles, choose the most common language. For releases where there’s an equal mix of two or more languages and hence no obvious answer, ‘Multiple Languages’ may be the best choice. But remember that it is quite common for languages to borrow words and phrases, and so “Je ne sais quoi” in an English title does not make something multiple languages, nor do a few English words in a foreign language title. (Some languages borrow quite extensively, and especially for Japanese, unless most of the titles are in other languages, Japanese is probably the best choice.)
But by changing it to English, I‘m pretty sure that would mean the track titles would have to follow English style guidelines, right? Which means the titles would have to have to follow proper English title rules (capitalization, spacing etc.) But I‘m not sure that should be the case for Japanese releases, even if all the titles are in English. But this would go against the current style guidelines.
What do you guys think? Whatever the case, it should probably be reflected on the newly created wiki page.
2 Likes
I don’t particularly have strong opinions on the language/script data of releases. I also assumed previously that the script of accompanying data such as the booklet would be taken into consideration here, but according the the style guidelines it should not be, so 
. To me, your edit looks correct.
No, I don’t think doujin releases need special treatment here.
1 Like
Another question: for Touhou doujin albums in particular, I often see ZUN being credited as the composer for derivative works, even though he is already credited in the original works for which the derivative works are arrangements of / based on.
This is an error, right? I just want to make sure I haven’t been messing up releases this whole time by removing ZUN from the derivative works. So far I haven’t received any complaints about it, but it almost seems intentional with how often he is credited in derivative works, even though albums usually make it clear on the cover art that he composed the original work.
1 Like
I would say so, yes. There is no reason for the derivative work to give any credit to the original work’s composer outside of the work relationship, unless they directly contributed to the derivative. That said, I haven’t dealt with Touhou-related releases in quite a while and am definitely not on top of any current or recent standards.
2 Likes
In most cases, this is because the derivative works explicitly credit ZUN as the composer. It’s also pragmatic; Picard for example will not follow the derivative work or arrangement of relations to fill in the composer field when tagging.
Releases credit ZUN, but in a way that makes it clear they mean for the original works. Typically you see it in the tracklist with the original works beside each track, and then ZUN will either be credited beside each original work, or credited once somewhere on the cover art, usually on the back or in the booklet.
Hierarchically speaking, it makes sense not to include ZUN in the derivative works. What if a derivative work has additional composition on top of the original? How do we differentiate who is the original composer and who is the new one in any given work when we put them both in the derivative work?
Picard not recursively following works is an application thing, not a database one. The database shouldn’t be structured to compensate for something that can be solved at the software level, e.g. plugins. I’m pretty sure there’s a plugin for classical music that does what you describe.
2 Likes
Right now we seem to be collecting Noah’s CD releases under the ExistRuth artist.
As far as I can tell, while RemyWiki says that ExistRuth is a project, to me, it doesn’t seem like it serves as anything more than his own circle/label meant for publishing his own music. Notice how the albums/EPs listed in the wiki page came out after ExistRuth being started in 2017.
Noah’s digital releases on Bandcamp seems to also match with what Melonbooks sells for ExistRuth.
I’m not sure what the best approach here is, should we merge two artists together? because it doesn’t make sense that digital releases and CD releases are being collected under two separate artists, something I’ve noted here when adding Reverie, the new album he just put out.
Style does not exclude composers from from derivative works, and most derivative if not all works will credit ZUN with composition like you said above.
If you want to be able to differentiate original composers, you should vote for STYLE-2513.
Link me to the official style guideline, not a thread post from 5 years ago that no new user is going to be expected to see without digging through the forums.
There’s clearly no guideline saying we should not enter data - which means the usual editing standard applies and we should enter data. Why would we have a guideline saying to do the usual thing?
I’m not against entering data. I’m against entering data when the data is already present, and furthermore I’m against entering data where it doesn’t belong.
ZUN did not sit down with these doujin circles and compose music for them to arrange and perform. He composed music for his games. This is what he is credited for on releases, and what he is already credited for in the original works on MusicBrainz. There is no reason to make it any more complicated.
I understand why circles put him on their releases. Because they are legally obligated to, that makes sense. What doesn’t make sense is why we’re considering a complex solution to a problem that doesn’t exist, especially when we have the advantage of having powerful relationships that many other services do not. This is why work-work relationships exist, so we don’t have to duplicate credits like this and bloat up the database with information that can be inferred.
I have yet to be informed as to why this is a good idea. The database should not have to suffer bloat to compensate for something that is clearly a missing software / API feature, only for it to inevitably be reverted if or when the ability to recursively traverse the heirarchy of works is added. Plugins like this prove it can be done.
It is not at all just a “missing software / API feature”. I personally would very much prefer not to implement inheritance, because it’s a lot less obvious than what you make it sound. For example, there’s no guarantee at all that every credit on a work actually applies to every version of it. It can drop part or all of the lyrics and have some or all lyricists no longer apply, it can change the music but keep the lyrics and have the composers no longer apply. Rather than adding all sorts of switches to the system to turn inheritance on or off on specific relationships, it’s significantly simpler and easier to understand to just… add all that applies wherever it actually applies.
Nothing claims that he sat down with them to compose. Obviously, if I make a modern arrangement of a Mozart piece, Mozart is not sitting down with me to work on it. That doesn’t mean Mozart didn’t compose the piece and should be credited as its composer. Having to figure out if someone did or not in fact sit down to work on a piece all together is, indeed, what would make things a lot more complicated.
4 Likes
Now we’re getting somewhere.
I see your point about original credits not always being applicable in later versions, and that’s valid. But I disagree about inheritance not being simpler, at least in the long term. It would actually be great if one could link two works together and have a separate “inherited relationships“ section where you could simply toggle credits from the inherited work. Maybe have a few attributes for edge cases like “partial” to indicate that the associated credit is only partially inherited.
This would nullify the need for tickets like this and other future tickets because the inheritence itself establishes the difference between new and original. And why limit this to just works? It would be nice to inherit the performers in a remixed song, to indicate that their performances are still present while also indicating that they originate from the original recording, alongside any new performances.
By having to manually add original credits directly to the derivatives, we have to come up with a way to also manually differentiate them. With inheritence this would be done automatically in a self-sustaining way—if someone comes along and adds missing performances to a recording, it would be updated in the other linked recordings too. Maybe program it to be smart so that it wont automatically inherit vocalists to a karaoke / instrumental recording, for example.
1 Like
In touhou releases, track artist credits confuse me a little. They should be added when they are credited (usually on the back cover). There however, they are usually credited as “arrangers”.
MB has a relation “arranger” for recordings/works. Wouldn’t it be more suitable? Or should both “arranger” and “track artist” be used?
I only assign track artists if they are clearly stated. If the tracklist on the cover art only provides relationship credits (e.g. arranger, lyricist, performers etc.) then I use the release artist. I did this for an album a while back and it sparked some debate, especially since there were multiple arrangers. In this particular case, there are only relationship credits, and the previous track artists used fabricated join phrases.
1 Like
I’m wondering how I should handle the release group/track artist credits for Scaenae Quartet3, a Revue Starlight doujin album. The rear cover lists 不自然なカルテット and にしこ under “presented by,” while the metadata from the digital download on Booth only mentions 不自然なカルテット. I believe にしこ is a member of 不自然なカルテット, so this may be redundant. Should I use the circle name as the release/track artist credit, or would it make more sense to use 不自然なカルテット (and maybe にしこ)?
FWIW, I credited a previous album (Scaenae Quartet) to the circle as there weren’t any other credits on the back of the cover.
Release group artist credits don’t look redundant to me, the rear might have credited them separately to emphasize the role of にしこ on the release. Either way, the rear is a more reliable source than the retailer so I’d leave it as is.
I am not so sure if track/recording artist credits should be given to the arrangers or follow the release group. The classical music guideline has this to say, tho would it apply to doujin releases as well?
> The Recording Artist field should contain the most important performers who appear on that specific recording
If someone knows more, please correct me!
(edit) After having read a thread discussing what is considered classical music I figured that classical style guidelines wouldn’t apply to this release or doujin music that has “classical influences”, it’s still primarily doujin music, my bad!
Thanks for the reply. I have another question regarding the previous release (Scaenae Quartet). I contacted にしこ and they confirmed that 不自然なカルテット performed the instruments on the album. Should I credit them as a release artist or should I add instrument credits on each track?