#musicbrainz-devel

yea, juno download has it cheaper, so i'll get it there

http://www.junodownload.com/products/the-advent... you might like it too

hm, seems too cheerful for the "dirty/heavy dubstep/grime" description juno files it under.

heh

yes, i wouldn't put it there

beatport calling it glitch hop seemed fine

:)

now I hopefully have a chance of passing the assignment due wednesday :)

heh, genres are hard

it's like a flashback to last weekend!

:p

But with less chocolate :(

Can I mark MBS-5523 as closed?

AFAICT, it's working on mb.o.

("Add missing "url" in JSON WS url-rels output.")

Ah well. I went and did it.

I imagine someone forgot to set the proper fix version and mark it as in beta testing

probably me

so yes, close it, set the fix version to 11-12

though I'll just get the fix version

unless it's done

it is!

and it's actually marked as 11-14, heh

:)

Isn't that the one it was supposed to be marked as?

yeah, that's correct

Oh, "set the fix version to 11-12".

it just used to be 11-12, since that was when that release was originally happening

Yeah.

That wasn't an option. ;)

exactly :P

Project musicbrainz-data build #38: SUCCESS in 2 min 18 sec: http://ci.musicbrainz.org/job/musicbrainz-data/38/

ollie: Added correct Bounded/enumFrom for Vote/EditStatus

Is VirtualBox generally the recommended virtualisation thing to use these days? I don't want to use VMware, and I'm not exactly sure how QEMU is the similar/different - and I don't know of other virtualisation stuff. :)

KVM is another at some level

and the one I've heard recommended most highly; qemu is a bit small, virtualbox is oracle and has weird issues

libvirt might be a thing related to kvm? unsure

kepstin does something with something in that vein

which was of course exceptionally vague, but :P

ollie: Rewrote relationship stuff to provide better compile warnings

Freso: "it depends'

mostly on what you're doing

VirtualBox is great consumer level virtualization, but I'm not sure it's suited for running something in a server

if you have a bunch of servers which need to run a bunch of vms, probably openvz or xen are more appropriate.

yeah, xen's pretty nice if you set it up right

server-wise

be careful though, it's a huge headache if you don't research options carefully

I'm just on the "consumer level". :)

project at my college vs. hoser (here) is night and day XD

the most impressive thing with openvz is that you can migrate a running vm to a different physical machine with no downtime.

ollie: Change Data.Relationship to be entirely endpoint-type independent

So probably either VirtalBox or QEMU/KVM.

I don't know if any other virtualization environments can do that.

(some quick wikipedia'ing shows that that is more common nowadays, and apparently supported by xen, virtualbox and a bunch more)

:)

vmware can do that, of course :)

504'ing on beta! \o/

504'ing here, 504'ing there, 504'ing everywhere!

ianmcorvidae ocharles warp: Did beta break?

I have a question about picard and cover art. the sony mp3 walkman comes with a few mp3 sample files. they have cover art embedded. if I open such file in picard it shows the picture. but appearently its not possible to "migrate" or preserve that image inside the mp3 file. if I lookup the info for the mp3 file the cover image is removed.

Project libmusicbrainz build #22: SUCCESS in 11 min: http://ci.musicbrainz.org/job/libmusicbrainz/22/

bug or feature?

olaf_: do you have it set to strip existing tags?

nikki: no

olaf_: Do you know how the image is stored in the sample file?

hawke_1: I have no idea. at least picard does not seem to show such info, other that some "artwork" is there, image is shown in the info menu

the tab, I mean

Project libmusicbrainz build #23: SUCCESS in 1 min 52 sec: http://ci.musicbrainz.org/job/libmusicbrainz/23/

olaf_: As far as I know, Picard doesn’t read existing embedded cover art — it can store new cover art and that’s all.

luks or bitmap might be able to answer that better.

I dont care so much about the sample files itself. but it would be nice if I can retag the mp3 albums I have and encode the image into the mp3 files so that all the albums have a picture instead of a gray box in the walkman.

What model is it?

hawke_1: it does a lookup, just the sample file I picked has no entry in data base. would be nice if it can reuse existing images

hawke_1: <Model>NWZ-E460 Series</Model>

is there any restriction in the cover art images, licenses, or can I go and find the missing images and upload them somewhere? I see the current mb database allows me to upload images. would picard find them?

Yes.

Well

not for standalone recordings

but if they’re part of an album, yes.

oh, it does. fine

just uploaded one yesterday and picard shows it.

:)

nikki: ^ is there one already?

interesting that Eliminator lacks coverart...

not that I know of

well, I still think that sa recordings should be promoted to some sort of release so we can record other data, like release dates etc.

+1 to that

kepstin-work: How about “single” ;-)

kepstin-work: Like, having dynamic attributes?

they're not quite singles, really :/

maybe add a new release group type, "standalone recording" ;)

kepstin-work: I still root for recordings being able to have CA though. I have entered at least one release, where I've later found "cover art" for each track.

*one digital (Bandcamp) release

I kind of think they are singles…at least, I can’t think of a difference between the two.

freso we have a 'track' cover art type

Freso: well, there is a "track" cover art type

I know there's a type for that in the CAA types.

common usage is to put the track number in the comment field on each piece of track art.

But it'd still be niftier to have it directly associated with the recording/track.

+1

I’m liking more and more the idea of track-as-entity.

(partly so that we could actually associate art with a track, but also for ARs.

I want arrangements, meatbags and a pony

:)

Meh. Screw ponies. I'm with the Canadianian - unicorns to the people!

That, or pegasi.

Pegasi would also be awesome.

Freso: it was having trouble earlier, hopefully back later