#musicbrainz

sorry

My code looks for artist by GID. It keeps finding 2 artists for one track.

number 5

it really doesn't like id'ing this track

night!

'night

I can't believe that the same MP3 file should not return the same TRM every time. I think we may have a fairly important tagger bug here.

rjmunro: its not a tagger bug.

Its an unfortunate sideeffect of some TRMs.

TRM == black magic

But the linux tagger gives the same result every time?

and black magic is not always deterministic.

Err, TRM tool, not tagger...

rjmunro: yes, every time

Hmmm. I didn't realize that.

Ok, can you please mail me the track and I'll have a look?

the tagger seems to have latched on to one trm now, but it's different from the linux one, and different from the one I submitted to the database earlier

another silly quiz for people with nothing better to do: when looking at everyone's passwords, and seeing which ones are most often used, how many of the top ten passwords can you guess? :-)

qwerty

asdfgh

melange: #3

12345678

password

#1!

password

musicbrainz

#4

blah

nope

god

sex

no, no

whatever

oh, sorry. melange: 12345678 = #8

what is #2 and #5 ?

ok, here are the top 10, in order.

password. 123456. qwerty.

musicbrainz. 12345.

regarding different guids for the same mp3, the only reason that should happen is that somebody else tagged something between the times you queried, and it matches the new track "better"

1234. music. 12345678.

and rounding it out: trustno1. letmein.

heh "trustno1"

if you get that without a time space between queries, that _would_ be a bug =)

actually, less than 1% for all of those.

at least now I know what my next password will be

" password" = 207 users, of 26161 total.

I'm pretty surprised by that, actually.

I thought it would have been nearer 10%

I think you need to add a "your password has expired, please change it" feature for everyone whose password is in the top 10.

:-) not a bad idea!

and give them a drop down list of the other nine ;)

number 6

I get a new trm if I quit the tagger and open it up fresh

then load this track

ruaok: priv me your email address ..

on it's way

thanks.

wtf?

# 7?

linux tagger suddenly decided to give me another trm

go figure

that makes me less worried now. :-)

after giving me the same one 20 times in a row

does it depend on which way the wind is blowing or something?

:)

bloody voodoo

You got it!

bloody voodoo!

it's consistently giving me this other trm now

melange: you better stop. it will drive you crazy. :-)

all I did when it changed was check another track's trm

argh!

maybe we need a way to flag some songs as "generates useless trms"

and I thought it was deterministic... shows what I know.

oooh

the linux and the windows tag match up

quick, export it to the database!

;)

melange: do you know anything about multidimensional pattern matching algorithms?

In this case 133 dimensions.

other than being a tongue twister, not the foggiest

I could attempt to explain what is going on and what you're doing, but...

I'm wondering .. it's pretty quiet for the first 25 seconds or so, and it's vbr, so it would be sampling at low bitrate ..

and as the trm only cares about the first 30 seconds ..

ARG!

You're giving it nothing to work with.

still, it managed to deal with a 9 second silent track consistently

The less signficant the data in the first 30 seconds, the less reliable the TRM will be.

But it should be constant with the same data, shouldn't it?

yes

yes and no.

Can you add the feature to the tagger that tells the server that the TRM is wrong?

Since there is so little significant data in this track the data values are likely to be small.

It would be good to see some stats on that.

And windows and linux have different rounding errors.

and the TRM algorithm will probably scale the small range of value to a large domain.

er range.

and thus the roundoff errors get exaggerated, which can account for different TRMs on different machines.

at different times of the day

even that I could explain

cosmic rays

the lookup 'dataset' probably gets influenced by other sketchy tracks being looked up.

and being inserted into the TRM system.

So if you were the only person using it, you'd get more consistent results.

hmm

I think "voodoo" was probably a good enough explanation

:D

I'm going to disappear for a bit. Back soon.

I wonder how you could determine if a track will produce TRMs like this that aren't useful?

without running the TRM generator over it many times, that is

I ran the "TRM collisions" report...

the top TRM had 48 tracks and no lookups

and of those 48, that's only over three artists

and lots of different songs.

So, I looked up which moderations those TRMs came from.

metallica is one of those, right?

guess what? all from the exact same moderation.

really? hmmm .. that is interesting

wow

are there any others like that?

dunno... I'll take a look.

I bet that metallica one is though

that trm has been removed from a number of songs since ..

it's only matching two now

unless you just went and removed it?

no

I'd advocate for those trms to be removed

especially the metallica one

yes, absolutely

I'm just wondering if there's some nice way to auto-find this stuff and maybe even auto-remove it

I'll hack on /showtrm.html and see if I can get it to only show each album once

I'm wondering how the tagger decided to use the same TRM for all those tracks within the one session?

I expect I'll end up seeing a few albums, each of which has all the tracks highlighted

Don't know. I would have thought that would be quite hard to do by mistake.

but there's no accounting for folk... someone will find a way to do it by accident.

was there any bugs with the tagger back in 10.1?

maybe the tagger could detect/warn if a single TRM is trying to be matched to more than one track at a time. i.e. by the same user

none that I know would do this.