Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
On Jan 17, 2008 6:26 AM, David K. Gasaway [EMAIL PROTECTED] wrote: On 9 Jan 2008 at 12:27, Bogdan Butnaru wrote: Isn't the main problem here the fact that Picard adds release-AR credits to files indistinguishable from track-ARs? The main problem is that file metadata formats and, even more importantly, media software/hardware players don't support the degree of structure represented by the musicbrainz database. Which is really okay with me. I don't expect 100% precision from my tags. Rather, I leave the chore to real database and use the tags as an overview, more or less. Actually, that's really an excellent point. I've long ago decided that the most important tags in a file are actually the MBID of the artist/album/track. Any media library that'd be smart enough to use all the info available in Musicbrainz should download it directly from there, using the MBIDs as keys. (There is no such application that I know of.) The rest of the file tags are just a caching mechanism, and should be treated as such. (I.e., almost never use tags as arguments for database design. That's what PicardQt's plugins are for.) -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
On 9 Jan 2008 at 12:27, Bogdan Butnaru wrote: Isn't the main problem here the fact that Picard adds release-AR credits to files indistinguishable from track-ARs? The main problem is that file metadata formats and, even more importantly, media software/hardware players don't support the degree of structure represented by the musicbrainz database. Which is really okay with me. I don't expect 100% precision from my tags. Rather, I leave the chore to real database and use the tags as an overview, more or less. -- -:-:- David K. Gasaway -:-:- Email: [EMAIL PROTECTED] -:-:- Web: dave.gasaway.org -:-:- MusicBrainz: dkg ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
On 4 Jan 2008 at 11:14, Chris B wrote: in any case, that's what i mean when i'm talking about inheritance vs propagation While inheritance is a closer approximation of the concept than propagation, it's still pretty wrong. :) Inheritance expresses a specificity relationship. For example, Abyssinian inherits from Cat inherits from Animal expresses that an Abyssinian is a Cat and a Cat is an Animal. I don't think anyone would argue that a Track is a Release. I'd say the closest common programmer-lingo analogue would be a cascade a la CSS. Now that I think about it, there are other aspects of this discussion that remind me of CSS, such as CSS properties do not cascade to contained elements (release ARs that should not cascade to tracks). -- -:-:- David K. Gasaway -:-:- Email: [EMAIL PROTECTED] -:-:- Web: dave.gasaway.org -:-:- MusicBrainz: dkg ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
Isn't the main problem here the fact that Picard adds release-AR credits to files indistinguishable from track-ARs? I mean, it seems quite clear to me that release credits and track credits are slightly different in meaning, and the two have been used on liner notes since forever without major issues. It's just when they're used in too-strong inferences that they become a problem (ie, they're inherited by tracks in file tags). My approach was always to enter precise credits on track level (eg, guitar on tracks 1–12 [on a 12-track album] by X) get entered for each track, since that's what it means, and generic ones (all guitars by X) gets entered at release-level (since there may be tracks without guitars). It's true that the credits may be wrong, but that can happen anyway, we can correct it if possible. As for Picard, on one hand it allows you to not add release-level ARs in tags, right? This at least allows accurate-though-possibly-incomplete tags. The correct improvement, I think, would be to change a bit the tags to allow distinguishing between release- and song-ARs. For instance, adding -release on each tag name derived from release ARs. This gives complete (all info gets in), accurate (it doesn't claim to be _sure_ that the credit applies to the track) and minimal-fuzziness tagging (it tells you which credits it's _sure_ about, as far as we trust the editors). On Jan 9, 2008 9:23 AM, David K. Gasaway [EMAIL PROTECTED] wrote: On 4 Jan 2008 at 11:14, Chris B wrote: in any case, that's what i mean when i'm talking about inheritance vs propagation While inheritance is a closer approximation of the concept than propagation, it's still pretty wrong. :) Inheritance expresses a specificity relationship. For example, Abyssinian inherits from Cat inherits from Animal expresses that an Abyssinian is a Cat and a Cat is an Animal. I don't think anyone would argue that a Track is a Release. I'd say the closest common programmer-lingo analogue would be a cascade a la CSS. Now that I think about it, there are other aspects of this discussion that remind me of CSS, such as CSS properties do not cascade to contained elements (release ARs that should not cascade to tracks). -- -:-:- David K. Gasaway -:-:- Email: [EMAIL PROTECTED] -:-:- Web: dave.gasaway.org -:-:- MusicBrainz: dkg ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
On Jan 4, 2008 1:17 AM, Brian Schweitzer [EMAIL PROTECTED] wrote: If we also can come up with a list of which ARs can't be non-fuzzy at the release level, or those which only should ever apply to release or tracks, we could also have it set so depending on the AR, either the non-fuzzy release checkbox or the tracks section could have the checkbox greyed out. Great, Brian. I think we're moving in the right direction. There is one point I'm unsure about, maybe there are some opinions: The more I think about it the more I'm sure that there should be no inheritance of ARs from release to track level at all. There are for sure ARs on release level that only apply to the release itself and others that do indeed have relevance on track level but have a slightly different meaning on the release level and can never be safely propagated downwards. Given that I wondered if we really need the explicit distinction between applies to the entire release and applies to some tracks, but I#m not sure which ones or if this is just an implicit distinction given by the chosen AR type. This, of course, need to be documented in the description of each AR. We would of course need the list Brian mentioned to do that and to specify the ARs that are only valid on release or on track level. Overall I believe this system will give us less fuzziness and better structured information on release and track level. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
On Jan 4, 2008 10:53 AM, Chris B [EMAIL PROTECTED] wrote: forgive me for sounding like a broken record, but inheritance (at least that proposed @ http://bugs.musicbrainz.org/ticket/3029 ) does not imply propagation. propagation implies that they get copied down the levels, but that is obviously incorrect as a fuzzy release level AR does not imply that that it is for EVERY track. eg, a liner note credit on an album of produced by X and Y is (excluding any other sources) a fuzzy AR as some tracks might be produced by X, some by Y, some or all by both, etc. whilst it wouldn't be right to propagate (copy) this AR down to all the tracks, it would be right to display this info at the track level (inherit). you could display the info at the track level to show that whilst X AND Y didn't necessarily produce this track, they did produce a release that contains it. it would be displayed in a manner that reflects this, rather than implies anything concrete. We're getting off-topic here, but what you are talking about is no inheritance. Inheritance would indeed mean that the release AR applies to the track itself as well. What you describe is an information in the form Some tracks on the release this track belongs to where produced by X, maybe including the track itself. Surely correct and good, but not inheritance. Propagation would be just the physical realization of a inheritance relation. i don't think ARs should ever be copied - they should always be applied at the lowest level that is practical. I completely agree on that :) -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
On 04/01/2008, Philipp Wolfer [EMAIL PROTECTED] wrote: On Jan 4, 2008 10:53 AM, Chris B [EMAIL PROTECTED] wrote: forgive me for sounding like a broken record, but inheritance (at least that proposed @ http://bugs.musicbrainz.org/ticket/3029 ) does not imply propagation. propagation implies that they get copied down the levels, but that is obviously incorrect as a fuzzy release level AR does not imply that that it is for EVERY track. eg, a liner note credit on an album of produced by X and Y is (excluding any other sources) a fuzzy AR as some tracks might be produced by X, some by Y, some or all by both, etc. whilst it wouldn't be right to propagate (copy) this AR down to all the tracks, it would be right to display this info at the track level (inherit). you could display the info at the track level to show that whilst X AND Y didn't necessarily produce this track, they did produce a release that contains it. it would be displayed in a manner that reflects this, rather than implies anything concrete. We're getting off-topic here, but what you are talking about is no inheritance. Inheritance would indeed mean that the release AR applies to the track itself as well. What you describe is an information in the form Some tracks on the release this track belongs to where produced by X, maybe including the track itself. Surely correct and good, but not inheritance. Propagation would be just the physical realization of a inheritance relation. hmm, well in the OO language i am familiar with (cache), these two are separate :) were these true inherited properties, one would be able to access release properties from the track level, but they would still only be stored at the release level, and just accesible at lower levels. however, unlike traditional usage of inheritance in OO programming, we would need to show the inherited properties apart from the native properties rather than being transparent, so the context is preserved. Eg I open a release object with property Producer: oRelease.Producer = Mr X Now I open a track that's part of that release. This track has a property Release which refers to an existing release, which in turn has property Producer oTrack.Release.Producer = Mr X you can only update Producer at the release level*. at the track level you can just access it, so it's not really propagated, but it is inherited. in any case, that's what i mean when i'm talking about inheritance vs propagation * actually, maybe you can update it, but in any case it would be updating the release. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12
That crashing noise was the sky falling after Brian and I just came to almost exactly the same conclusions. So +1 what he said above. No wonder it's so cold here... even the flames of hell have gone out! LOL Ok, here's just a thought on how we can do this, and at the same time, simplify the 2 AR pages in to one (I don't know how many times I've tried to walk people through how to even get to the batch AR page...). http://s2.photobucket.com/albums/y48/brianfreud/?action=viewcurrent=ARSuggestion.jpg Each of the three grey boxes is mutually exclusive, so you can only select This AR applies to the entire release (non-fuzzy release-level ARs) OR This AR applies to some tracks, but I'm not sure which ones (however we word it, for fuzzy release-level ARs) OR you can select 1 or more tracks - but you can't do any two or three at the same time. If we also can come up with a list of which ARs can't be non-fuzzy at the release level, or those which only should ever apply to release or tracks, we could also have it set so depending on the AR, either the non-fuzzy release checkbox or the tracks section could have the checkbox greyed out. Thoughts? Brian ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
