#musicbrainz

I am using beets :)

when this batch finishes importing I can try that chromaprint plugin

been having some funky issues with beets

can't figure out why

Hello:

Greetings:

hmm

can't import this release using that script

doesn't show on the page

the button

brb

changing nicks

back

sorry

so yeah, the import button doesn't show up

nmm

perhaps because it is a "mini-album"?

I've seen cases where it doesn't show up

in theory ppl here will address, I don't know where you are "sypposeD" to file the bug

probably on github. so I have to do it manually if that thing isn't working? daunting :X

just posted on github. will see what happens. will use the tags as is for now

anyone good with adding OSTs to MB? is there a well-added OST I can take as a example on how to add ARs for anime soundtracks?

sudormrf: I think it might be because of the weird tracks (10-31 and 32.*)

which means 21 [silence] tracks, then a track 32 named [silence] / Get Yourself Arrested (W.E. In The U.S. Are In Trouble Mix) / [silence] for MB

so, I'm *finally* starting to work on acoustid again

I'm thinking about adding a concept of "verified" mbid matches

similar to the unlinked matches, but the opposite meaning

so an user manually confirms an acoustid?

then I could write a bot that checks if such a verified match is also added to other fingerprints

and if there are other verified matches on that fingerprint, it would remove the unverified one (that is verified elsewhere)

pankkake: yes

perhaps with a note giving the source

I'm also thinking about changing how submissions from picard work

saving a file that was matched by acoustid would send "+1"

this kind of popularity voting could be another way to help unlinking wrong matches

how is "sources" increased currently?

only if you submit the fingerprint, which never really happens for existing fingerprints in picard

because it would not submit them in case it was able to use acoustid to find a match

so it's basically historical information only populated by acoustid fingerprinter users

do you think the manual verified matches are a good idea?

hawke1: I'd also like your opinion

oh right, it's annoying as I've probably submitted wrong acoustids with the fingerprinter, but could have +1ed many fingerprints after that

I like it but I'm not sure many users would do it

the +1 on picard save is probably the most useful

the worst part of acoustid are popular songs and I think for the popular songs it would be possible to have a good coverage

at least it could be seen as an easier way of cleaning up the database, you set the verified matches and the bot removes anyhing obviously wrong

i see, I wasn't thinking of those

for the long tail songs, it doesn't matter much, because the only have a single acoutid anyway

the main problem are two cross-linked popular songs

there are some cases I'd like to mark acoustids as confirmed though. my usual example is https://musicbrainz.org/artist/973dce81-f9ce-41... which has same acoustids for recordings that should not be merged because the lyrics are not the same

or perhaps add a note for acoustids from vinyl rips

I have found a very ugle case today http://acoustid.org/track/20304910

same song recorded with tens of different singers

lol

which of course all sound the same to acoustid

luks: there is also cases like http://musicbrainz.org/release/09186fe9-18af-47... , where acoustids match both CDs (see my annotation), not sure how we can handle those, but the same acoustid matches two different tracks, and it was manually verified (i initially thought about some mistake from me or a bug)

maybe refine the algorithm a bit to catch the vocals?

acoustid will have collissions, you are taking a large file with lots of data and rounding down the results so it is possible for two completely different songs to have the same id

Yeah. AcoustID isn't the end-all-be-all of audio fingerprinting, it's just the best alternative right now. :)

(And is much less bad than TRMs or PUIDs. And FOSS.)

catching the different vocals is really not worth the effort

that's not a large scale issue and very hard to solve, almost impossible without breaking backward compatibility

trying to catch incorrect submissions is a better issue to work on

I use an userscript to check them. can only disable the wrong ones though

I meant that for me :)

oh ;p

luks: IMO the way to do submissions would be to have the number be a count of the number of unique submitters. But that might increase the resource use too much.

(since Picard would need to either always-submit, meaning that there's more to process and possibly drop, or Picard would need to check if *this user* had already submitted it, so another round-trip and more querying etc.)

how about submit if there was no saved mbid?

Doesn't work if the music is already mb-tagged before being scanned.

I do kinda like the idea of 'verified' acoustIDs.

Probably have to verify them as belonging to a specific track MBID rather than a recording MBID

the problem I have with track IDs is that they seem hard to manage by people and therefore can easily disappear on basic release editing

but I agree that verification against a specific release makes more sense

I think it's hard to tell if it's actually a problem.

Yeah, people might have to re-submit after an edit, but I don't think that's a big deal.

(maybe it is for some stuff, I guess. Not sure)

and regarding picard, I was thinking about making picard always submit, but in case it's using an existing acoustid to save the file, it would just submit the acoustid-mbid pair

what I'd really like to do relatively soon is start collecting full fingerprints, not just the first 2 minutes

but I'm not sure how to update the current processes to that

the main problem is cleaning up the database though

and I'm afraid that can't be done manually, so I'm thinking how to help the automatic process with minimal manual work

luks: It seems like AcoustID has lately been having trouble with noticing merged recordings. Any idea what’s going on?

yes, I know about that, replication on one of the servers was stuck

MB replication

it's catching up now

luks: I know the beets 'chromaprint' plugin always submits. So it wouldn’t be too weird for Picard to do the same.

doesn't in the context of beets 'always' mean 'when importing'?

for picard it could mean "when saving"

O

oops

what I'm a little worried about is that if we have the number and taggers use number to select the primary match, then the top match will just keep increasing

even if it's possibly not correct

but I guess that's not such a big problem

does picard currently use the counts?

i think not, but it definitely should :)

it should, but what about the feedback loop?

could happen, yes. not sure how big an issue it is

luks: beets can automatically submit on import, but you can submit manually as well.

luks: But controlling that number is why I think it would make most sense to keep track of the number of distinct users that have submitted that acoustID/MBID.

(or I guess distinct API keys?)