Re: [mb-style] Transparency and Duplication of Tracklists
On 06/13/2012 08:31 AM, lixobix wrote: Could work. We do currently have data quality for releases, but it's not very obvious. Yeah, I know we have one but it sucks and has unwelcome side effects for voting. I think something more along the lines of a warning if trying to collaterally edit a track list with high data quality, rather than preventing it outright. A high quality track list could still contain small errors. That could work. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
Andii Hughes wrote On 10 June 2012 16:29, Nicolás Tamargo de Eguren lt;reosarevok@gt; wrote: On Sun, Jun 10, 2012 at 3:46 PM, lixobix lt;pz57fiwef6cde65@gt; wrote: If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? DiscIDs are not attached to several tracklists but several *mediums* IIRC. They ignore tracklists completely. What's the difference? The fact is that if a tracklist is shared between multiple releases, and I go to set the track times from the disc ID, all releases are affected and there is no option to instead make the changes on a new clone of the tracklist, as happens with edit release. Yes, is there a reason why we presume disc ids should apply to several mediums whilst track lists should not? -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635843.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On Mon, Jun 11, 2012 at 2:45 PM, lixobix pz57fiwef6cd...@jetable.org wrote: Andii Hughes wrote On 10 June 2012 16:29, Nicolás Tamargo de Eguren lt;reosarevok@gt; wrote: On Sun, Jun 10, 2012 at 3:46 PM, lixobix lt;pz57fiwef6cde65@gt; wrote: If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? DiscIDs are not attached to several tracklists but several *mediums* IIRC. They ignore tracklists completely. What's the difference? The fact is that if a tracklist is shared between multiple releases, and I go to set the track times from the disc ID, all releases are affected and there is no option to instead make the changes on a new clone of the tracklist, as happens with edit release. Yes, is there a reason why we presume disc ids should apply to several mediums whilst track lists should not? No, there is not, and the discID affecting all releases thing sounds like a data-loss bug that should be fixed. Or a data-loss design, which is even worse. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635843.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
Nicolás Tamargo de Eguren wrote On Mon, Jun 11, 2012 at 2:45 PM, lixobix lt;pz57fiwef6cde65@gt; wrote: Andii Hughes wrote On 10 June 2012 16:29, Nicolás Tamargo de Eguren lt;reosarevok@gt; wrote: On Sun, Jun 10, 2012 at 3:46 PM, lixobix lt;pz57fiwef6cde65@gt; wrote: If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? DiscIDs are not attached to several tracklists but several *mediums* IIRC. They ignore tracklists completely. What's the difference? The fact is that if a tracklist is shared between multiple releases, and I go to set the track times from the disc ID, all releases are affected and there is no option to instead make the changes on a new clone of the tracklist, as happens with edit release. Yes, is there a reason why we presume disc ids should apply to several mediums whilst track lists should not? No, there is not, and the discID affecting all releases thing sounds like a data-loss bug that should be fixed. Or a data-loss design, which is even worse. That seems to be the case, but I don't know if this is affecting all releases or just those that share a disc id. If the latter, perhaps some releases have the wrong disc id attached. If not, it clearly needs fixing. Back to the other issue, is there a reason why we don't want users to update multiple track lists with a single edit? We allow users to update recordings from a single track list edit and that doesn't seem to have caused many problems. Even if some mistakes are made, it's a worthwhile trade off against forcing multiple edits of the same mistake (e.g. moving feat. to artist credits). Is there a different logic here? -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635847.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 06/10/2012 07:46 AM, lixobix wrote: If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? That’s a bug: http://tickets.musicbrainz.org/browse/MBS-3936 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 06/11/2012 07:53 AM, lixobix wrote: If the latter, perhaps some releases have the wrong disc id attached. If not, it clearly needs fixing. That’s certainly the case, due to the way discIDs were migrated during the NGS switchover. Pre-NGS, a release was likely to have many discIDs, due to the “release events” system. For the migration, all discIDs from a release were copied to all new NGS releases, which were generated came from the release events. So this means there are a lot of MB releases which have the wrong discID. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
David Gasaway wrote On Thu, Jun 7, 2012 at 2:09 PM, Andii Hughes lt;gnu_andrew@.fsfgt; wrote: It also means they no longer share a tracklist: No longer sharing a tracklist is not an issue in itself. In fact, it sounds a lot like copy-on-write to me. That is, conceptually, releases all have individual tracklists; shared tracklists are merely an optimized implementation of that concept (which probably shouldn't be visible to the end user). You are free to disagree with the concept, of course. But some of your arguments seem to be coming at it from the wrong angle. -- -:-:- David K. Gasaway -:-:- Email: dave@ ___ MusicBrainz-style mailing list MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635736.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On Sun, Jun 10, 2012 at 3:46 PM, lixobix pz57fiwef6cd...@jetable.org wrote: David Gasaway wrote On Thu, Jun 7, 2012 at 2:09 PM, Andii Hughes lt;gnu_andrew@.fsfgt; wrote: It also means they no longer share a tracklist: No longer sharing a tracklist is not an issue in itself. In fact, it sounds a lot like copy-on-write to me. That is, conceptually, releases all have individual tracklists; shared tracklists are merely an optimized implementation of that concept (which probably shouldn't be visible to the end user). You are free to disagree with the concept, of course. But some of your arguments seem to be coming at it from the wrong angle. -- -:-:- David K. Gasaway -:-:- Email: dave@ ___ MusicBrainz-style mailing list MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? DiscIDs are not attached to several tracklists but several *mediums* IIRC. They ignore tracklists completely. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635736.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 10 June 2012 16:29, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Sun, Jun 10, 2012 at 3:46 PM, lixobix pz57fiwef6cd...@jetable.org wrote: David Gasaway wrote On Thu, Jun 7, 2012 at 2:09 PM, Andii Hughes lt;gnu_andrew@.fsfgt; wrote: It also means they no longer share a tracklist: No longer sharing a tracklist is not an issue in itself. In fact, it sounds a lot like copy-on-write to me. That is, conceptually, releases all have individual tracklists; shared tracklists are merely an optimized implementation of that concept (which probably shouldn't be visible to the end user). You are free to disagree with the concept, of course. But some of your arguments seem to be coming at it from the wrong angle. -- -:-:- David K. Gasaway -:-:- Email: dave@ ___ MusicBrainz-style mailing list MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style If all track lists are independent, how does setting track lengths from disc id affect multiple track lists? Why is the behaviour of that edit different to others? DiscIDs are not attached to several tracklists but several *mediums* IIRC. They ignore tracklists completely. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635736.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style What's the difference? The fact is that if a tracklist is shared between multiple releases, and I go to set the track times from the disc ID, all releases are affected and there is no option to instead make the changes on a new clone of the tracklist, as happens with edit release. -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 8 June 2012 17:43, David Gasaway d...@gasaway.org wrote: On Fri, Jun 8, 2012 at 7:18 AM, Andii Hughes gnu_and...@member.fsf.org wrote: I don't see what you disagree with here. That's because I didn't actually disagree with you. :) Ok :-) I didn't say that the copy-on-write (COW) technique didn't work in some situations. This bug and discussion is about controlling its use, which is inconsistent between release editing (always COW) and disc ID changes (never COW). All I was trying to say is that you seem to disagree with the concept that all releases have independent tracklists. They don't; that's not a disagreement, it's just a fact. If you really do disagree with that, then first convince people it is wrong. Then we can talk about the COW (which is just an artifact of an optimization of the original concept anyway - a feature, if you will). That optimisation would be nice, but the main issue is the duplicated work done by the user rather than the wasted space server-side. Exactly. It's about *this*, not about shared track lists and COW. Yes, and I mentioned that originally and in the bug report. The efficiency savings are just an additional pro. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On Thu, Jun 7, 2012 at 2:09 PM, Andii Hughes gnu_and...@member.fsf.org wrote: It also means they no longer share a tracklist: No longer sharing a tracklist is not an issue in itself. In fact, it sounds a lot like copy-on-write to me. That is, conceptually, releases all have individual tracklists; shared tracklists are merely an optimized implementation of that concept (which probably shouldn't be visible to the end user). You are free to disagree with the concept, of course. But some of your arguments seem to be coming at it from the wrong angle. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
As pointed out by Andii during the ticket discussion, a similar feature already exists in relation to tracks and recordings. Has that caused problems or confusion? Most users would have the sense not to use such a feature unless they were fairly sure. Even if all track lists are conceptually separate, there is something to be gained by linking them. In most cases you would want to copy an edit across all similar releases. I did also discuss the idea of making track lists a usable object, similar to recordings, so you could actively link releases to one track list or another. Obviously this would require a schema change, but could be useful. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Transparency-and-Duplication-of-Tracklists-tp4635450p4635564.html Sent from the MusicBrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 8 June 2012 07:41, David Gasaway d...@gasaway.org wrote: On Thu, Jun 7, 2012 at 2:09 PM, Andii Hughes gnu_and...@member.fsf.org wrote: It also means they no longer share a tracklist: No longer sharing a tracklist is not an issue in itself. In fact, it sounds a lot like copy-on-write to me. That is, conceptually, releases all have individual tracklists; shared tracklists are merely an optimized implementation of that concept (which probably shouldn't be visible to the end user). You are free to disagree with the concept, of course. But some of your arguments seem to be coming at it from the wrong angle. I don't see what you disagree with here. I didn't say that the copy-on-write (COW) technique didn't work in some situations. This bug and discussion is about controlling its use, which is inconsistent between release editing (always COW) and disc ID changes (never COW). There's currently no way not to do COW on release edits, so you end breaking the sharing and making the same edits repeatedly to all the releases, resulting in three identical tracklists, as I pointed out in the last mail. There doesn't seem to be any optimisation to coalesce identical tracklists back into one shared list. That optimisation would be nice, but the main issue is the duplicated work done by the user rather than the wasted space server-side. Whether they are shared or not does make a difference to the end user as without it, unwanted changes can be made to other releases (setting track times on e.g. a digital media release that a CD shares its tracklist with) and the user has to do duplicate work if an edit applies to all releases that share a tracklist. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On Fri, Jun 8, 2012 at 7:18 AM, Andii Hughes gnu_and...@member.fsf.org wrote: I don't see what you disagree with here. That's because I didn't actually disagree with you. :) I didn't say that the copy-on-write (COW) technique didn't work in some situations. This bug and discussion is about controlling its use, which is inconsistent between release editing (always COW) and disc ID changes (never COW). All I was trying to say is that you seem to disagree with the concept that all releases have independent tracklists. If you really do disagree with that, then first convince people it is wrong. Then we can talk about the COW (which is just an artifact of an optimization of the original concept anyway - a feature, if you will). That optimisation would be nice, but the main issue is the duplicated work done by the user rather than the wasted space server-side. Exactly. It's about *this*, not about shared track lists and COW. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Transparency and Duplication of Tracklists
I've opened a bug relating to this issue here: http://tickets.musicbrainz.org/browse/MBS-4785 but posting here is likely to get more comments/insight on the subject. Releases have a number of tracklists e.g. http://musicbrainz.org/tracklist/1266911 which in many cases are shared by multiple releases (e.g. because the release was added by being based on an existing release). At present, changes to this sharing are made silently and in different ways by two different features of the MusicBrainz server. 1. If you edit a release and make a change to a shared tracklist, a new tracklist is silently created with the edits and used solely by the release being edited. 2. If you set the times in a track list via disc ID, it alters the existing tracklist (with an appropriate warning that it will affect multiple releases). The problem with (1) is that in many cases an edit does apply to all the releases that share the tracklist. They are obviously very similar or they wouldn't have identical tracklists to begin with. As an example, changes to bring a release into line with the guidelines apply to all (e.g. feat. changes, capitalisation) as would correcting the use of an inaccurate artist credit. At present, the same changes have to be repeated over all releases and, in the process, duplicate tracklists are created in the database. With (2), there's no option but to alter track times on all releases. To get round this, the current hack involves using 1's behaviour to create a new tracklist (via entering a fake edit) and then reversing it after the disc ID update is done. See: http://musicbrainz.org/edit/17893494 http://musicbrainz.org/edit/17893495 http://musicbrainz.org/edit/17893499 for an example. I propose adding an option in both cases to allow the behaviour to be toggled, so that a shared tracklist can be edited in the release editor (with a warning as with disc IDs) and disc ID changes can be made to a new tracklist directly without the elaborate hack. The default could be the same as now to reduce the chance of accidental propagation through editing. Note that there's nothing to stop someone making changes to all involved releases now, except that it takes more time. Is it really worth safeguarding against something that is unlikely to happen and could easily be reversed, with the downside of making edits far more laborious for everyone? I think fixing 1 would go a long way to remove fears of multiple releases with little difference between them (e.g. just release date/country) experiencing massive divergence if one is edited. Fixing 2 is even more important, as currently track time data can be destroyed by those not aware of the hack to get round this. Comments welcome. -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 06/07/2012 07:09 AM, Andii Hughes wrote: The default could be the same as now to reduce the chance of accidental propagation through editing. Note that there's nothing to stop someone making changes to all involved releases now, except that it takes more time. Is it really worth safeguarding against something that is unlikely to happen and could easily be reversed, with the downside of making edits far more laborious for everyone? Please no. Editing a release is complicated enough as it is without yet another option requiring that the editor understand and investigate the complete ramifications of their edit. I know it would make me afraid to touch a lot of things, and I think I’m a relatively experienced editor. I think fixing 1 would go a long way to remove fears of multiple releases with little difference between them (e.g. just release date/country) experiencing massive divergence if one is edited. Is this a big problem? Would adding that checkbox help anything, really? It’s just as likely that someone would say “well, I only know about my own release; I’ll just change this one” and the effect would be the same as you’re afraid of. Fixing 2 is even more important, as currently track time data can be destroyed by those not aware of the hack to get round this. +1 to this. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On 7 June 2012 14:19, Alex Mauer ha...@hawkesnest.net wrote: On 06/07/2012 07:09 AM, Andii Hughes wrote: The default could be the same as now to reduce the chance of accidental propagation through editing. Note that there's nothing to stop someone making changes to all involved releases now, except that it takes more time. Is it really worth safeguarding against something that is unlikely to happen and could easily be reversed, with the downside of making edits far more laborious for everyone? Please no. Editing a release is complicated enough as it is without yet another option requiring that the editor understand and investigate the complete ramifications of their edit. I know it would make me afraid to touch a lot of things, and I think I’m a relatively experienced editor. Then just don't touch it and all will remain as normal :-) It could even be hidden under an advanced tab or something. But it would save a heck of a lot of tedious editing, and would also make the database more efficient (assuming it does coalesce tracklists already) I think fixing 1 would go a long way to remove fears of multiple releases with little difference between them (e.g. just release date/country) experiencing massive divergence if one is edited. Is this a big problem? Would adding that checkbox help anything, really? It’s just as likely that someone would say “well, I only know about my own release; I’ll just change this one” and the effect would be the same as you’re afraid of. True, but that's no different to now. I know this would have come in usefully personally many times when I've had to alter feat. credits on releases. For example, take a look at: http://musicbrainz.org/edit/15591038 http://musicbrainz.org/edit/15591036 http://musicbrainz.org/edit/15591041 for example. Three identical edits which could have just propagated to one track list instead. It also means they no longer share a tracklist: http://musicbrainz.org/tracklist/1149810 http://musicbrainz.org/tracklist/1149809 http://musicbrainz.org/tracklist/603134 Fixing 2 is even more important, as currently track time data can be destroyed by those not aware of the hack to get round this. +1 to this. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
