#musicbrainz

hmm... can't remember if it was broadcasted in HD or not -___-;

the shows that were done digitially but predate HD are kinda annoying

no real way to e.g. rescan them to get a good upconvert

Sometimes they can rerender them though.

they had to redraw a good chunk of one piece for the HD re-broadcast

luks: hellu, are you here now ? i have an acoustid issue :)

jesus2099: Just write the issue then...

He'll see it when he's arond.

*around

ok cool :)

(i thought i was the only one like that)

hi Freso :)

the serial experiments lain one was neat, they included a booklet with an episode-by-episode discussion of the restoration process

restoration ?

for the blu-ray release

upsacling then ? :)

they rescanned the film, upscanned or redid the digital

restoration seems like it comes from old films with lots of scratches

recomposited a lot of cuts, sometimes with newly drawn mattes

lain was actually kinda lucky, it was just old enough that most of the show was recorded on film

luks wherever you are : the following “track” https://acoustid.org/track/ed43b283-b5fc-42fb-a... i have ear checked it on my CD it“s ”TIN MAN“. this “track” contains many “fingerprints” that aez very different… maybe htat explains the several mismatched MB recordings……

is there a way to know which fingerprint is our current sound file ?

because for instance https://acoustid.org/fingerprint/11458007 and https://acoustid.org/fingerprint/10904971 are very close to https://acoustid.org/fingerprint/30395796 from https://acoustid.org/track/6579443b-f187-4494-b...

Oh, jesus2099 btw. The "all links" thingy's search on WhoSampled doesn't seem to work anymore.

if i could know that my fingerprint is either 11458007 or 10904971 i could fix https://acoustid.org/track/6579443b-f187-4494-b... by unlinking OLD MAN TOOK

Freso: wow i just checked that a few days ago it was still ok ! (when i had to fix decoda)

jesus2099: Those fingerprints all look similar to me…

I mean the ones on https://acoustid.org/track/ed43b283-b5fc-42fb-a...

oh ? let me see again

if there are multiple fingerprints with the same acoustid, those fingerprints are by definition fairly similar

but not the same :/

that one is not same, is it ?

i know some variation is hopefully accepted but i mean there is one that seem to bump too much when i CTRL+TAB them all → https://acoustid.org/fingerprint/25570260

jesus2099: it is, just a time offset

set offset to 33

i never understood that compare page

jesus2099: The more black, the less difference.

yeah, offset 33 is pretty close

ah…

enough differences that it could sound somewhat different, but it's the same song at least

it’s not very intuitive as both compared stuff are black, when overlapping i didn’t understaood it should fill the white in black… (._.?)

And the start is chopped off from one of them.

thanks :)

jesus2099: the comparison is just an XOR, so it makes perfect sense.

… for who ?

 ;)

i mean there’s no such explanation over there :)

the idea is that you want to know if either both tracks have white or if both tracks have black in the same spot

and that calculation is what the XOR operation does

kepstin-laptop: I thought it was more white == better match until someone told me otherwise.

it returns 1 if the two are different, and 0 if they're the same

and 0 is black, 1 is white

transparancy, blending of two colours would be more intuitive for guys like me ;)

I mean, it would be trivial to use whatever colours you like

transparence isn't correct, because black+white and white+black are bad, and white+white and black+black are good

i said colours ;p

it could use green+red, aside from that not working for colour-blind people ;)

the colours are irrelevant really, it could be any two colours

kepstin-laptop: The point is though, there's nothing on the compare page to tell how to use the comparison. If you don't know that white is bad and black is good, or that it's an XOR comparison happening... how are you supposed to know?

yellow and blue make green seal!

Freso: you ask in the musicbrainz channel, and someone explains it to you

lol

hawke: only two colours.

there's no third colour

what is that, "wrong", "right" and "I don't even"?

kepstin-laptop: https://en.wikipedia.org/wiki/Color_mixing

kepstin-laptop: Sure. I could also go #git to ask questions about what parameters `git commit` takes.

And also https://www.youtube.com/watch?v=bDZze39mq5g

But it would be way faster and easier on everybody to just have `git commit -h` or `man git-commit` tell you that.

hawke: ... but the comparison operation has no relation to mixing at all

Freso: I agree that the comparison page could use some help, yeah

but you asked a factual question, so I gave a factual answer ;)

I never asked a factual question.

I asked a rhetorical question.

I should probably update http://wiki.musicbrainz.org/Guides/AcoustID to talk about the comparison page

Freso: and I gave a rhetorical answer ;)

kepstin-laptop: did you land on that page first time and immediately understood that “it’s a XOR compare.” without luks explaining ? if so, you’re a truly computer god !

I figured it out pretty quick after using offset adjustment on some acoustids that I knew were basically the same

then I looked at the code and saw "hey, it is literally just using xor"

you’re what i said : a KUMPUTER GOD !

ah ok…

you’re not, you watched the code, cheating ! :)

the only way to become a true computer god is to cheat your way there

Freso: should’t this explain appear right on the compare page directly ? is there a bug tracker ?

i have another issue https://acoustid.org/track/25447756 is not styling a:visited as darker as other links

jesus2099: there is a bug tracker.

jesus2099: Do you use beta?

jesus2099: I think there might be a tracker by its repository. I think luks is using Bitbucket.

jesus2099: the acoustid.org links all go to 'main' musicbrainz

Oh, perhaps I'm just not using the latest version of your script.

hawke: oh good point, i don’t use beta but i use HTTPS←that

oh but acoustid also uises HTTPS so it’s not the problem

Freso: you’re not, it works for me ;) → http://www.whosampled.com/search/artists/?h=1&a...

silly new h=1 parameter

It works for me with h=1 too.

ladys and gentlemen, i will be using the TOC + Release Duplicates tab for the first time since it is supposed to be fixced (not vanish yur TOC anylmore)

…uh oh.

jesus2099: hmm? if you're adding a new release via toc lookup, that was never fixed

yeah it seemed so indeed :)

i thought it was fixed

i thought i was too shy to try…

Some things have been fixed, what is this bug?

chirlu`: if you use picard, do a cd lookup, don't find the release so add a new one, then select an existing tracklist to reuse, it looses the disc id

loses*

when you submit a CD TOC and you create a new release, you can’t use the Existing releases tab, if you do so because you don’t want to type all tracks and then link them all to recordings one by one… you loose TOC in punition to your lazyness !

Ah yes, but there is a fix for that.

then you have to redo the lookup a second time and find the release you just added to actually associate the disc id

Not merged yet, though.

i thought it was still being discussed

New post: blog: More details for our 2014-05-15 schema change release <http://blog.musicbrainz.org/2014/03/24/more-det...;

chirlu`: huh? what's that? it looks unrelated

That’s the bug I thought you meant. :-)

Do you have a ticket for your issue?

this issue specifically affects that the disc id simply disappears completely from the release editor when you select an existing tracklist to reuse

or to be specific, the issue is that selecting an existing tracklist overrides the seeded media data, including the disc id

we have lost milliseconds support on recordings too… but i guess we don’t care since recordings lengths will soon completely disappear :)

We had milliseconds support on recordings?

yes :)

Hmm, never noticed. :-D

i showed them with a user script

they still show up but we cannot set them any more through APPLY TOC times to release then check the apply changes track→recordings

huh, I can't actually find a ticket for this issue

this last edit since new release editor only takes minutes and seconds

wow, 2301

I can’t see how milliseconds would be useful — heck, >1–2 seconds is barely relevant

that's way back

... it's closed

hawke: i wanted to make sure a recording had its time from a TOC (my TOC)

I guess we need to reopen it or file a new ticket

oh, it did get fixed

(not in production yet, obviously)

we need a "merged but not yet released" ticket state ;)

how did you find it was only on non-normal ? (beta ?)

jesus2099: the fix has been merged into master: https://bitbucket.org/metabrainz/musicbrainz-se...

oh, into beta

but has beta actually been updated to include that?

Yes, but possibly the new RE re-broke this.

this change is post-new-re