hawke1: it seems much less of an explosion than with physical releases.
hawke1
kuno: Is it?
CallerNo6
oops, "the same on one level"
hibiscuskazeneko joined the channel
kuno
hawke1: with physical releases you have all these different regions and such, whereas in most cases if you download a release from iTunes the files will be exactly the same regardless of whether you purchased that release in the US, DE, FR, whatever iTunes region.
CallerNo6
so kuno, if a label assings a catno to the digital edition and a vendor then makes that edition available in different encodings, what happens to the catno? is it still valid?
grr, typos
hawke1
kuno: we might be talking about different things then...
kuno
CallerNo6: different encodings to me means the audio is actually different. So, for me that is similar as giving the same catno to the CD and SACD release or something like that.
hawke1
kuno: does that apply with different lossless formats?
kuno
hawke1: not unless the files are different in some other meaningful way
hawke1
anyway, bandcamp alone has MP3, FLAC, ALAC (Apple Lossless), AAC, Ogg Vorbis, WAV and AIFF -- that's a multiplier of 7 on every release they have.
that seems like a huge explosion of effort
darwin
(sigh, ftr, I agree with hawke every time this comes up)
(no, there is no reason for every encoding to be considered a different recording)
kuno
hawke1: I'm OK with treating all those as equivalent, because if you purchase one of them you get access to all of them and can pick which of them you'd like to download. So your purchase includes all of them (and it seems silly to add all of them as separate discs to the release).
hawke1: on bleep though better quality files are more expensive, so on bleep they seem like separate releases.
aron_kexp joined the channel
hibiscuskazeneko has quit
hawke1: I can see some value in being more practical than I personally think we should be, so I wouldn't oppose a guideline for MB to consider certain things equivalent which I personally think should be kept separate.
CallerNo6
kuno, would it serve the same purpose to have field for "available in the following encodings" or something?
kuno
CallerNo6: for digital releases I think it makes sense to model them a bit differently as physical releases
CallerNo6: it's not just about encodings though, for the same release the .mp3s you buy from boomkat are not bitwise equivalent to those bought from bleep.
hawke1
kuno: the other half is inexpert people trying to determine which release they have, plus youtube rips, plus god knows what else
kuno
CallerNo6: if as a music purchaser for some reason I prefer those from bleep (maybe because boomkat tags in such a way that it crashes my android phone or some nonsense like that), it would be useful to know who actually did the encoding, not just what the encoding is.
ofcourse distinguishing between MP3 retailers which do their own encoding and those which re-sell encodings made by 7digital or someone else is probably just as arcane as caring about attaching the correct label to a release ;)
reosarevok
Of course you should be substituting those tags with MB ones anyway :D
CallerNo6
the one true tags
kuno
reosarevok: there is atleast one release on bleep where the MP3 version has per-track cover art, that's not something picard can do.
reosarevok
yet. I hope
But yeah
aron_kexp has quit
aron_kexp joined the channel
CallerNo6
it might seem like I'm wasting time repeating arguments about labels when I should be thinking about areas.
actually,I think it's a similar problem. so I'm doing both.
drsaunde
yes areas please
CallerNo6
hi!
to paraphrase... position one: "that's not a real word because it's not in the dictionary!"
position two: "of course it's a word. I said it, my listeners understood it. that's all that matters."
position three: "I edit dictionaries, and I'd love to include everything but I can't."
hawke1 has quit
hawke1 joined the channel
hawke1
CallerNo6: why should you be thinking about areas? :-)
CallerNo6
because when there was a call for a volunteer, everybody else took one step backwards
hawke1
a volunteer to think about areas?
CallerNo6
yes. I am the area thinker-abouter.
hawke1
nice. :-D
So what do you think about areas?
CallerNo6
nice places to visit. wouldn't wan to live there!
hawke1
Good one!
So what is it about areas that needs thought? How to deal with the historical area mess?
Greg__ joined the channel
CallerNo6
a few things.
Greg__ has left the channel
hawke1
like such as? The Iraq?
CallerNo6
1. should editing be opened up to more/all editors?
2. should mb-areas be more descriptive or more prescriptive?
3. Is there a way to return to a bot-centric system?
4. how can we make everybody happy?
hawke1
1. maybe. 2. what? 3. yes. 4. you can't.
CallerNo6
5. how can we avoid having a dataset that's out of sync with other external resources?
4.but, but, but
hawke1
3 relates to the sort of mess around the wikidata bot, right?
CallerNo6
yeah
drsaunde
one thing i'll say...we should only care about areas that we need for artists in our database...we don't need to be complete with all the towns in the world...just the ones we need
CallerNo6
an example of 2 would be districts and neighborhoods. how granular should we be? and what if there's no real-world consensus on boundaries for things like neighborhoods?
drsaunde
if a neighbourhood is significant enough that an artist would say he is from there...that should be enough
CallerNo6: IMO the way to do it would be to have the bot continue to import ~country or ~state level entities completely (because we'll need all of those for sure.
CallerNo6
6. is the box-in-a-box model of areas viable?
drsaunde
bot hasn't imported anything in years
hawke1
drsaunde: OK, import/sync then.
drsaunde
CallerNo6: also you are wrong to say nobody volunteered to take over areas
CallerNo6
s/continue/resume/ ?
hawke1
Anyway -- and then allow people to import other entities by pasting a wikipedia page -> pull in the wikidata entry -> add it to the list of stuff to be synced.
CallerNo6: yeah. Whatever the situation is. :-)
CallerNo6
drsaunde: sorry, I was only referring to a specific conversation.
hawke1
CallerNo6: that's my opinion on the extent of 1, 3, and 5.
I don't really get #2 -- how would we be either descriptive or prescriptive, on areas?
reosarevok
Well, I guess that kinda applies to stuff like the neighbourhoods. Also to stuff like Crimea
CallerNo6
hawke1: "descriptive" would be "if an artist says she's from <foo>, then <foo> is a place"
"prescriptive" would be "if a reputable external source (like e.g. geonames) says <foo> is an area, then it is"
an editor might ask "well, crap, if she says she's from <foo>, I want to record that /somewhere/. I should be able to."
another editor might say "what good is our area data if it's not linked 1:1 with an external source?"
hawke1
Got it.
Then I would 100% say "descriptive but with reference to a suitably liberal external source such as wikidata"
CallerNo6
I thought you might :-)
drsaunde
i would agree
w/hawk
e1
CallerNo6
the box-in-a-box problem is the one that really gets me down.
hawke1
Is that one, "is every area we might want to use contained within some other area"?
CallerNo6
yeah, one and only one
reosarevok
To which the answer is already no, though, with multy-county American cities
The_Freso joined the channel
So I guess the right question is "wtf do we do with those"
darwin: well we know there are exceptions, we want to find how to reach a display that can work for the general cases, ideally without breaking horribly on exceptions :p
darwin
most specifically refer to "addresses" not so much regions, but some ("multiple towns with the same name in the same country") do apply
reosarevok
I mean, we don't need them to be unique
The_Freso joined the channel
Areas *do* have disambiguation comments
So if we have a few cases where the search would display the same, it's always possible to add a disambiguation
But I really need to sleep now so I'll let you all discuss this :)
CallerNo6: if I remember correctly, we have a database view that does area containment and that's what we use for display. You might want to search for the sql for that view as a start
Freso has quit
The_Freso is now known as Freso
(well, that's the basis of what we use, anyway :p)