While submitting releases with quad or 5.1 tracks, I keep running into the same problem: Should the channel information be included in the track title, like appending “(5.1)”, or should this go into the recording disambiguation field?
There is no common practice at this time and arguments can be found for both approaches.
a) It certainly looks cleaner to have only recordings of the same title and add channel information to the recording disambiguation field.
b) There are releases which ONLY incorporate multichannel mixes, like some DVD-A or quad LPs and tapes. In this case, the release mix could be added both to the release disambiguation and to the recording disambiguation field.
c) My biggest problem are releases that feature stereo AND multichannel mixes of the same tracks, maybe even on the same medium. When using approach a) and then tagging files with Picard, the channel information is lost and all tracks look the same. That is why many editors prefer to write the channel information directly in the track title.
A solution for case c) could be an expansion of Picard options, or at least a script, to write release and/or recording disambiguations to album titles and/or track titles at the time of tagging. That would actually solve the practical problems and might go a long way towards uniting editors with different practices.
Is such a script possible and would someone knowledgeable volunteer some code?
It is very easy in MusicBrainz to add disambiguation to track titles. I’m not on the right computer to copy and paste the code, but as one of the premiere 5.1 title editors, that is the approach I take.
That does not work for me, you have the escape the brackets (and you don’t need replace IMO). Here’s what I do, because I prefer square brackets for disambiguation and round brackets for ETI:
$set(title,%title% [%_recordingcomment%])
If you want to have round brackets, you have to escape them:
I would vote to keep this in the track name until there is a way of storing that kind of data in its own field in the database. Until then don’t do edits to the database that will loose information for people using this database.
Ideally there would be way of adding number of channels to recordings as a data field. When\if that is possible, then I can see the logic of coming back to this debate.
The (4.0 mix) is an important difference and should be kept as part of the track title. Don’t forget that most people using MusicBrainz do so without extra scripts. Meaning the majority of users never see those Track and Recording disamigurations. Fire up a browser without the scripts and have a look what “normal” users see on MB.
Also remember that there are many users of this data who never see the database, but use external tools to lookup their music data. Not just Picard.
The suggestion for always adding disambiguration text to files using Picard will lead to all kinds of extra text that is not always wanted on the files. You’ll be asking users of the data to keep toggling this on and off.
Not everything is written into the guidelines, but I have seen the general practice for SACDs is to include the channel data in the track names. The tracks sound VERY different on four channels than two.
Floyd is even more relevant in this conversation as there are different multi-channel mixes that sounds different to each other depending on who and when they were done.
I totally agree that the number of channels is a very important piece of information that should be stored in the DB. But abusing the title for it is a suboptimal approach.
Such information should be kept as disambiguation as long as we don’t have extra fields for this. Releases and recordings can have these disambiguations which are visible on their respective pages, but unfortunately tracks do not have a disambiguation (and the recording disambiguation is not shown for tracks by default).
Therefore the main point of my edits is to change the recording titles, the change of the tracklist is just a side effect of a simplified workflow and I’m willing to cancel this edit: I simply moved the channel information from the ETI into disambiguation, because this seems to be a common agreement for many multi-channel releases. Please pay attention to the track titles and recording disambiguations (open the recording pages if you can’t see them) of the following examples:
I’ve also changed my above link to the edits, because I want votes on the recording edits too and not only on the medium edit which I’ll probably cancel anyway.
Yeah, I can maybe see the logic of having this in a Recording title and a clear disambiguration, but let some of the tickets get dealt with that put this data somewhere safe that it can be used.
This is still removing vital information for other users of the database. When was the last time you looked at those pages WITHOUT your userscripts enabled and LOGGED OUT?
I also worry as to how fragile disambiguration text is. What also concerns me are those people who merge on “title and length match”. And then they just blindly push the merge to the oldest item. In the process they loose the disambiguration text. (There are some heavy editors who do this rather too often )
Sorry - I am doing too many things at the same time here. I got confused with the Release page there. Using your example the disambiguarion is on the Recording page, but not the Release page.
The same holds true for different titles merged by the oldest MBID crew
That’s exactly the example I would go after: Disambiguate recordings and abuse ETI for the track titles because they have no track disambiguation field. When we finally have the correct field for channels this discussion will be garbage of course
So you know the people I mean. Trouble can be made worse as some merges can fly through within a day if they get the popularity votes. And then the channel data is lost… so their next merge will be to merge the multi-channel version into the stereo version…
I loose track of the tickets and don’t go there.
Maybe there is a ticket from 2012 to fix some of this. Or even a ticket to MERGE the disambiguration text when the target is blank…
All I am asking is wait. Wait for a time when data can’t be lost. At the moment I can’t really see a need for deleting this. I know if I was talking about these recordings to someone I would certainly mention the number of channels as part of the title.
I don’t understand why you are so concerned about losing data, because the only thing I did was to move 4.0 mix or quad mix from the recording title into the disambiguation:
This is exactly the same that was done for the WYWH SACD. Maybe I should just cancel this damn medium edit that seems to confuse everyone. This edit is the only one that would have “lost” data and I only kept it open for general discussion
Because once it is gone through an “Oldest MBID Merge” - it is gone.
But let other people answer. I am only one person. I have explained my main concerns above. I’ll step away now to let other people put in their points as I am often talking rubbish
Maybe the confusion here is the same I cleared up for myself on the testing server. We all agree that we want to keep the channel information in the track title. That is what this here thread is about.
Then there is the separate question of how to format the recording title. As I have verified on the testing server, changing the recording title - which initially has the same name as the track it is based upon - by moving the channel information to disambiguation will NOT affect the track title.
Addendum: OK, I didn’t get your concerns about disambiguation being prone to vanishing when merged with other recordings. I don’t have enough experience to chime in there.
It is normal that people make mistakes – in this case merges into the wrong direction. This is the reason why we have the voting system, you can vote against such edits that are destroying data. But you should not vote against edits that comply to both the guidelines and common sense only because someone in the future might destroy the resulting correct and well organised data.
Having information as ETI does not prevent people from merging into the wrong direction, I have witnessed that. So there’s no place for this data which is safer – some editors remember to adapt the target’s data during or after the merge, but some do not.
I know mistakes are made, but it is also impossible to catch every single edit. Some merge edits can happen very fast if there are a lot of votes. But this is an off topic tangent that should go into a different thread. Especially as I am having one of those days where I can’t write clearly. Sorry. I’ll delete the post is probably better. This is not suppsed to be a conversation about merging mistakes. All I was trying to do is highlight that data that ONLY lives in a disambiguration gets lost by accidental means.
Guidelines clearly state to keep ETI on names. Not sure why so many move to disambiguation, but it’s not correct according to guidelines. This doesn’t change because it’s a recording and not a track name. Especially when all associated tracks have the ETI in their name.
Please link the guideline that you are thinking about.
IMO, when it does not appear next to the track on printed tracklist, it should go to comment. Including in the cases of a title of a trackset, MBS-6680.
)
I got confused with the Release page there. Using your example the disambiguarion is on the Recording page, but not the Release page.
Trouble can be made worse as some merges can fly through within a day if they get the popularity votes. And then the channel data is lost… so their next merge will be to merge the multi-channel version into the stereo version…
