#musicbrainz-devel

hello!

hello!

(just before I go to bed)

warp: cheer for sorting out test.mb yesterday :)

cheers*

np

goodnight everyone who still is in friday

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-4e... definitely had art, as I'm part way through mass-ARing it

refreshed today and it seems to be gone... unless i'm dreaming :(

I have no idea, ocharles would be the person to ask about cover art.

fair enough; thought you may have stumbled across the script at some point :)

on an unrelated note, why the hell is it so slow copying stuff to a Galaxy Tab 10.1 cf a USB key :/

30 minutes to do 6.8GB is preposterous... that's only 4MB/s

</rant> :)

one of the highlights of today was hearing the that warner music and emi's data departments use musicbrainz to look up stuff.

lol

ruaok: awesome

:-)

uploading cover art on test is somewhat fixed

just a thought nikki don't we need medium front/back for vinyl ?

want? perhaps. I don't really care what happens with these types now because they're just a pain in the arse

niiki, you sound quite annoyed

with the types, yes (and with my mac for that matter)

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

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

ijabz: you could just use medium-1, medium-2 for the first disc and medium-3, medium-4 for the second.

warp, while I agree

Does that mean for a 2xCD we should use medium 1 and medium 3?

reosarevok: is that danish humour ?

spanish

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

reosarevok: I think most people wouldn't scan the data side of a cd, so no.

warp: you haven't met people :P

nikki: "most"

:)

warp, sure, most people wouldn't

But if not, it feels kinda arbitrary

"we'll use 2 for different things in each case"

the types are just intended to give a broad indication of the contents of the file, the numbers provide a sequence of images

the numbers are not intended to match disc numbers, or page numbers of a booklet, etc..

Hmm

Dunno

I think the numbers can be more confusing than useful then

But maybe that's just me

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.

reosarevok: we just need _some_ way to store multiple images of a certain type, we've chosen to number them.

Would u have a relationship for each piece of artwork in a release then, or just one

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

ijabz: they're not relationships

nikki: the types are useful to make the coverartarchive.org webservice simple to use

ijabz: see warp's link for example - http://test.musicbrainz.org/release/b98a299e-8b...

warp: perhaps you'd like to define the list of types then

nikki: they're sufficient for many use cases, just not for the us musicbrainz OCD people :)

heh. the first cd I tried to define ended up with half the images under other :P

and that was just a normal jewel case

nikki, I can't see where the information about the cover art is actually stored

nikki: haha, wtf, what kind of images are those?

ijabz: we're not (yet) storing any information "about" the cover art.

ijabz: for now we're just storing cover art.

I don't remember exactly. it got a lot worse when I tried to do a slim jewel case and a digipak

Right, so what do you mean when you say 'we should capture interesting data about the images in musicbrainz itself.'

nikki: anyway, I can give defining those types a try. what do you have right now?

ijabz: I mean that we should do that in the future :)

one step at a time.

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

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

With types we should concentrate on that 95% and forget about the remaining 5%

Well, and "obi" because it'd be a shame not to use the only one we have a description for :p

we're going to do a server release on monday, right?

I'm not sure when we would use 'box' as a type.

We don't have so many boxes

sure a box also has front, back and spine images.

And it sounds confusing

surely

when a box collects a bunch of CD jewel cases

Either we use "box front" "box back" (which is still confusing, because hey, a jewel case *is a box* - especially for a non-native)

when a box collects a bunch of CD jewel cases, where should the front/back covers of the individual mediums go?

Or we use "other"

Or... dunno

:/

nikki: why does a box not have a spine?

how do you decide which of the sides is a spine?

boxes kinda work whichever way you put then :/

a jewel case is a box

whichever side is the flattest :)

nikki: my quick attempt: http://wiki.musicbrainz.org/User:kuno/Cover_Art...

warp: do we duplicate images when the booklet is part of the front or back packaging?

and I still don't understand sleeve

"For compact discs the spine is usually part of the back cover scan, and should not be uploaded separately"

Then for what should it be?

:/

For boxsets?

warp: and where do scans of the piece of card in a slim jewel case go?

warp: and digipaks?

reosarevok: "usually"

reosarevok: so spine is for the other cases :)

nikki: what about digipaks?

where do scans of those go?

all under "other"? :P

which part of a digipack?

well I would expect people to just unfold it and scan the entire thing

a digipack has a front cover, back cover and spines.

they have flaps and trays and stuff too

I wouldn't :). if it folds out more than once it already doesn't fit on a typical scanner.

oh, and dvds

keep cases are just a single piece of paper

right, so we basically need a type for front and back cover combined (or just one of the existing types for that)

+use

does anyone know if there's a way to get the number of matched tracks on a disc in picard?

$matchedtracks() seems to only be the entire release

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

Please

Someone who actually knows what (s)he is talking about

Go update http://wiki.musicbrainz.org/Web_Service