I know the cover art script is broken at the moment, but am I correct that it may be actively removing art from releases that previously had it? A few days ago http://musicbrainz.org/release/673fa8b8-3142-4e12… definitely had art, as I'm part way through mass-ARing it
2011-11-12 31602, 2011
voiceinsideyou1
refreshed today and it seems to be gone... unless i'm dreaming :(
2011-11-12 31629, 2011
warp
I have no idea, ocharles would be the person to ask about cover art.
2011-11-12 31647, 2011
voiceinsideyou1
fair enough; thought you may have stumbled across the script at some point :)
2011-11-12 31621, 2011
voiceinsideyou1
on an unrelated note, why the hell is it so slow copying stuff to a Galaxy Tab 10.1 cf a USB key :/
2011-11-12 31629, 2011
voiceinsideyou1
30 minutes to do 6.8GB is preposterous... that's only 4MB/s
2011-11-12 31658, 2011
voiceinsideyou1
</rant> :)
2011-11-12 31631, 2011
muesli joined the channel
2011-11-12 31657, 2011
ruaok pops his head in
2011-11-12 31658, 2011
ruaok
one of the highlights of today was hearing the that warner music and emi's data departments use musicbrainz to look up stuff.
just a thought nikki don't we need medium front/back for vinyl ?
2011-11-12 31626, 2011
nikki
need? probably not, "medium" works :P
2011-11-12 31600, 2011
nikki
want? perhaps. I don't really care what happens with these types now because they're just a pain in the arse
2011-11-12 31638, 2011
ijabz
niiki, you sound quite annoyed
2011-11-12 31658, 2011
nikki
with the types, yes (and with my mac for that matter)
2011-11-12 31636, 2011
ijabz
but really I think for doing vinyl you would want to scan both sides of the medium, not just one, and hence medium_front and medium_back would be more useful then just having medium
2011-11-12 31617, 2011
nikki
I spent far too much time thinking about it and it doesn't work, there's just too many types of packaging and too many different combinations of ways to scan things to come up with a well-defined list of types that's not too long
2011-11-12 31615, 2011
warp
ijabz: you could just use medium-1, medium-2 for the first disc and medium-3, medium-4 for the second.
2011-11-12 31615, 2011
ijabz can't think of any mediums consisting of more than two sides in any meaningful way
2011-11-12 31621, 2011
reosarevok
warp, while I agree
2011-11-12 31634, 2011
reosarevok
Does that mean for a 2xCD we should use medium 1 and medium 3?
2011-11-12 31658, 2011
ijabz
reosarevok: is that danish humour ?
2011-11-12 31602, 2011
ijabz
spanish
2011-11-12 31609, 2011
nikki
at the very least we'd need to be able to select multiple types and multiple page numbers per image, but then we can't use them in the url
2011-11-12 31610, 2011
warp
reosarevok: I think most people wouldn't scan the data side of a cd, so no.
2011-11-12 31621, 2011
nikki
warp: you haven't met people :P
2011-11-12 31628, 2011
warp
nikki: "most"
2011-11-12 31635, 2011
warp
:)
2011-11-12 31658, 2011
reosarevok
warp, sure, most people wouldn't
2011-11-12 31603, 2011
reosarevok
But if not, it feels kinda arbitrary
2011-11-12 31615, 2011
reosarevok
"we'll use 2 for different things in each case"
2011-11-12 31631, 2011
warp
the types are just intended to give a broad indication of the contents of the file, the numbers provide a sequence of images
2011-11-12 31647, 2011
warp
the numbers are not intended to match disc numbers, or page numbers of a booklet, etc..
2011-11-12 31602, 2011
reosarevok
Hmm
2011-11-12 31604, 2011
reosarevok
Dunno
2011-11-12 31615, 2011
reosarevok
I think the numbers can be more confusing than useful then
2011-11-12 31618, 2011
reosarevok
But maybe that's just me
2011-11-12 31623, 2011
warp
don't try to put too much weight into the semantics of the file name. we should capture interesting data about the images in musicbrainz itself.
2011-11-12 31601, 2011
warp
reosarevok: we just need _some_ way to store multiple images of a certain type, we've chosen to number them.
2011-11-12 31603, 2011
ijabz
Would u have a relationship for each piece of artwork in a release then, or just one
2011-11-12 31626, 2011
nikki
warp: so let's just get rid of types in the file name :P if the information in the filename is vague anyway we might as well just have one name that's guaranteed to be the front cover and just number the rest :P
2011-11-12 31634, 2011
nikki
ijabz: they're not relationships
2011-11-12 31609, 2011
warp
nikki: the types are useful to make the coverartarchive.org webservice simple to use
warp: perhaps you'd like to define the list of types then
2011-11-12 31642, 2011
warp
nikki: they're sufficient for many use cases, just not for the us musicbrainz OCD people :)
2011-11-12 31627, 2011
nikki
heh. the first cd I tried to define ended up with half the images under other :P
2011-11-12 31635, 2011
nikki
and that was just a normal jewel case
2011-11-12 31621, 2011
ijabz
nikki, I can't see where the information about the cover art is actually stored
2011-11-12 31639, 2011
warp
nikki: haha, wtf, what kind of images are those?
2011-11-12 31617, 2011
warp
ijabz: we're not (yet) storing any information "about" the cover art.
2011-11-12 31623, 2011
warp
ijabz: for now we're just storing cover art.
2011-11-12 31625, 2011
nikki
I don't remember exactly. it got a lot worse when I tried to do a slim jewel case and a digipak
2011-11-12 31659, 2011
ijabz
Right, so what do you mean when you say 'we should capture interesting data about the images in musicbrainz itself.'
2011-11-12 31605, 2011
warp
nikki: anyway, I can give defining those types a try. what do you have right now?
2011-11-12 31622, 2011
warp
ijabz: I mean that we should do that in the future :)
2011-11-12 31633, 2011
warp
one step at a time.
2011-11-12 31622, 2011
nikki
warp: an obi is a strip of paper around the spine (or occasionally one of the other edges of the packaging). I don't have a good definition of anything else
2011-11-12 31632, 2011
ijabz
so thats not really an answer to reosarevok , we really do needs the types, and if the types are incomplete then numbers wil have to come into play
2011-11-12 31643, 2011
ijabz
With types we should concentrate on that 95% and forget about the remaining 5%
2011-11-12 31645, 2011
reosarevok has nothing against having a lot of "other"
warp: do we duplicate images when the booklet is part of the front or back packaging?
2011-11-12 31600, 2011
nikki
and I still don't understand sleeve
2011-11-12 31656, 2011
reosarevok
"For compact discs the spine is usually part of the back cover scan, and should not be uploaded separately"
2011-11-12 31601, 2011
reosarevok
Then for what should it be?
2011-11-12 31602, 2011
reosarevok
:/
2011-11-12 31609, 2011
reosarevok
For boxsets?
2011-11-12 31653, 2011
nikki
warp: and where do scans of the piece of card in a slim jewel case go?
2011-11-12 31656, 2011
nikki
warp: and digipaks?
2011-11-12 31616, 2011
warp
reosarevok: "usually"
2011-11-12 31631, 2011
warp
reosarevok: so spine is for the other cases :)
2011-11-12 31647, 2011
warp
nikki: what about digipaks?
2011-11-12 31657, 2011
nikki
where do scans of those go?
2011-11-12 31615, 2011
nikki
all under "other"? :P
2011-11-12 31619, 2011
warp
which part of a digipack?
2011-11-12 31641, 2011
nikki
well I would expect people to just unfold it and scan the entire thing
2011-11-12 31648, 2011
warp
a digipack has a front cover, back cover and spines.
2011-11-12 31601, 2011
nikki
they have flaps and trays and stuff too
2011-11-12 31610, 2011
warp
I wouldn't :). if it folds out more than once it already doesn't fit on a typical scanner.
2011-11-12 31649, 2011
nikki
oh, and dvds
2011-11-12 31609, 2011
nikki
keep cases are just a single piece of paper
2011-11-12 31648, 2011
warp
right, so we basically need a type for front and back cover combined (or just one of the existing types for that)
2011-11-12 31607, 2011
warp
+use
2011-11-12 31633, 2011
nikki
does anyone know if there's a way to get the number of matched tracks on a disc in picard?
2011-11-12 31652, 2011
nikki
$matchedtracks() seems to only be the entire release
2011-11-12 31607, 2011
warp does not know.
2011-11-12 31627, 2011
nikki
I realised it would be a lot easier for me to to just compare %totaltracks% (which is the number of tracks on the disc) with the number of matched tracks on the disc, than to use the new %_totalalbumtracks% and come up with some complicated way of excluding bonus dvds from it
2011-11-12 31624, 2011
reosarevok
Please
2011-11-12 31636, 2011
reosarevok
Someone who actually knows what (s)he is talking about
