#musicbrainz

thanks warp

welcoem back btw

welcome even

beyond that I live very frugally

oops

from 36% to 51% in 30 seconds!

\m/

"we can do like congress and have

ammendment of the ammendment of the ammendment"

https://github.com/ocharles/CAA-spec :)

The release editor loses track number changes when deleting a track. Is this a known problem?

Related: is there a way to apply track re-ordering without hitting Next and then Previous?

[hiphop] "new" DaVinci album is quite nice http://swtbrds.bandcamp.com/album/feast-or-famine

freebie too

yey freezing rain :/

Humm.. I have a song that I've written metadata to with picard, of type wma, but mutagen-inspect can't inspect it.... and yet picard uses mutagen?

What's up with that?

nano-: picard itself can read it?

yeah

old version of mutagen perhaps?

'ascii' codec can't decode byte 0xbc in position 0: ordinal not in range(128)

ii python-mutagen 1.19-2.1 audio metadata editing library

mutagen had a bug regarding saving cover art

it didn't contain coverart when that got printed though, but now i added the coverart plugin to picard and now it has coverart, still same error message though.

hm, now that I think about it, this might be a different issue

I remember mutagen-inspect having problem with printing the binary tags in wma

I think it had a binary tag before, think WM/MCDI is binary.

murdos: ping

hrglgrmpf: pong

I think I watched a MBID switch by chance last week or so

but I'm not sure, and I can't research it quite well

(regarding http://www.last.fm/mbid/<MBID>)

so a clarification would be great :-)

indeed :-)

murdos: Are there all that many cases of different recordings with the same ISRC?

murdos: (as in, in MB)

hawke_: more than 2000

Does that mean “at least 2000, but the number is unknown? or “not much more than 2000, but the precise number is unknown”?

wondering if anyone could shed some light on a problem I running into on setting up musicbrainz server

hawke_: it means I don't have the exact number in front of me

But somewhere around that?

hawke_: I think it was more around 3000, but my query is still not perfect and doesn't put aside recordings with multiple ISRCs

so the exact number of recordings to be merged is not yet determined ;-)

It’s a relatively small number though, considering the number of recordings in MB

a lot of merging has already been done

(based on ISRC I mean)

hawke_: however I think there's a need for frequent merging based on ISRC.

e.g. when I add a new release, I add new recordings by default, then add ISRCs. So I'm sure to not misuse one recording. But then some merging is needed.

I think there’s a need for frequent merging, period. :-p

For essentially the same reason you gave

It’s unfortunate that such merging is a gigantic pain

I just had to do that on (almost) the entire works of Jonathan Coulton, about 175 tracks

do you think automatic merging based on acoustid can be safe?

Not currently, and in general no.

it usually gives remasters the same acoustid as the originals

That, and there are too many recordings with wrong acoustIDs.

any ideas where this incorrect acoustIDs come from? is it because they were added based on an existing wrong recording-PUID mapping?

I believe so.

Many of them are easily detected by having completely wrong durations

Some of them are harder than that. :-)

e.g. http://acoustid.org/track/9555657 and http://acoustid.org/track/12375314

I’m fairly sure one of those is “Grease” and the other is “Grease (reprise)” but it’s not easy to tell by duration alone

but then http://acoustid.org/track/4825ae81-f70c-480f-92... is pretty easy.

some votes por favor http://musicbrainz.org/edit/16350679 ?

CatCat: Voted.

tackar

och nu, natti natti

murdos: Something else to consider with regard to acoustID/recordings/remasters, is how difficult it is to copy a existing release’s tracklist without copying the recordings too, when adding a remaster album

takk SultS stealth voting also

natta!