in theory ppl here will address, I don't know where you are "sypposeD" to file the bug
2015-01-06 00630, 2015
sudormrf
probably on github. so I have to do it manually if that thing isn't working? daunting :X
2015-01-06 00618, 2015
sudormrf
just posted on github. will see what happens. will use the tags as is for now
2015-01-06 00630, 2015
zas joined the channel
2015-01-06 00630, 2015
Nyanko-sensei
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?
2015-01-06 00655, 2015
shredpub joined the channel
2015-01-06 00628, 2015
reosarevok joined the channel
2015-01-06 00624, 2015
yeeeargh joined the channel
2015-01-06 00609, 2015
hibiscuskazeneko joined the channel
2015-01-06 00615, 2015
pankkake
sudormrf: I think it might be because of the weird tracks (10-31 and 32.*)
2015-01-06 00613, 2015
pankkake
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
2015-01-06 00601, 2015
chungy joined the channel
2015-01-06 00634, 2015
luks
so, I'm *finally* starting to work on acoustid again
2015-01-06 00648, 2015
luks
I'm thinking about adding a concept of "verified" mbid matches
2015-01-06 00611, 2015
luks
similar to the unlinked matches, but the opposite meaning
2015-01-06 00632, 2015
pankkake
so an user manually confirms an acoustid?
2015-01-06 00633, 2015
luks
then I could write a bot that checks if such a verified match is also added to other fingerprints
2015-01-06 00602, 2015
luks
and if there are other verified matches on that fingerprint, it would remove the unverified one (that is verified elsewhere)
2015-01-06 00606, 2015
luks
pankkake: yes
2015-01-06 00617, 2015
pankkake
perhaps with a note giving the source
2015-01-06 00636, 2015
luks
I'm also thinking about changing how submissions from picard work
2015-01-06 00657, 2015
luks
saving a file that was matched by acoustid would send "+1"
2015-01-06 00630, 2015
luks
this kind of popularity voting could be another way to help unlinking wrong matches
2015-01-06 00643, 2015
pankkake
how is "sources" increased currently?
2015-01-06 00609, 2015
luks
only if you submit the fingerprint, which never really happens for existing fingerprints in picard
2015-01-06 00627, 2015
luks
because it would not submit them in case it was able to use acoustid to find a match
2015-01-06 00646, 2015
luks
so it's basically historical information only populated by acoustid fingerprinter users
2015-01-06 00616, 2015
luks
do you think the manual verified matches are a good idea?
2015-01-06 00625, 2015
luks
hawke1: I'd also like your opinion
2015-01-06 00628, 2015
pankkake
oh right, it's annoying as I've probably submitted wrong acoustids with the fingerprinter, but could have +1ed many fingerprints after that
2015-01-06 00654, 2015
pankkake
I like it but I'm not sure many users would do it
2015-01-06 00614, 2015
pankkake
the +1 on picard save is probably the most useful
2015-01-06 00625, 2015
luks
the worst part of acoustid are popular songs and I think for the popular songs it would be possible to have a good coverage
2015-01-06 00657, 2015
luks
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
2015-01-06 00610, 2015
pankkake
i see, I wasn't thinking of those
2015-01-06 00637, 2015
luks
for the long tail songs, it doesn't matter much, because the only have a single acoutid anyway
2015-01-06 00605, 2015
luks
the main problem are two cross-linked popular songs
2015-01-06 00610, 2015
pankkake
there are some cases I'd like to mark acoustids as confirmed though. my usual example is https://musicbrainz.org/artist/973dce81-f9ce-41c1… which has same acoustids for recordings that should not be merged because the lyrics are not the same
2015-01-06 00626, 2015
pankkake
or perhaps add a note for acoustids from vinyl rips
luks: there is also cases like http://musicbrainz.org/release/09186fe9-18af-47e5… , 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)
2015-01-06 00609, 2015
yml has left the channel
2015-01-06 00613, 2015
Nyanko-sensei
maybe refine the algorithm a bit to catch the vocals?
2015-01-06 00646, 2015
Nyanko-sensei checks if the karaoke versions of some songs have the same issue
2015-01-06 00657, 2015
dns53
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
2015-01-06 00634, 2015
Freso
Yeah. AcoustID isn't the end-all-be-all of audio fingerprinting, it's just the best alternative right now. :)
2015-01-06 00659, 2015
Freso
(And is much less bad than TRMs or PUIDs. And FOSS.)
2015-01-06 00653, 2015
rtv joined the channel
2015-01-06 00612, 2015
JoeLlama joined the channel
2015-01-06 00623, 2015
luks
catching the different vocals is really not worth the effort
2015-01-06 00654, 2015
luks
that's not a large scale issue and very hard to solve, almost impossible without breaking backward compatibility
2015-01-06 00619, 2015
luks
trying to catch incorrect submissions is a better issue to work on
2015-01-06 00624, 2015
Nyanko-sensei
I use an userscript to check them. can only disable the wrong ones though
2015-01-06 00606, 2015
luks
I meant that for me :)
2015-01-06 00647, 2015
djpretzel joined the channel
2015-01-06 00651, 2015
Nyanko-sensei
oh ;p
2015-01-06 00621, 2015
shredpub joined the channel
2015-01-06 00635, 2015
hawke
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.
2015-01-06 00621, 2015
ratsupremacy joined the channel
2015-01-06 00608, 2015
hawke
(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.)
2015-01-06 00616, 2015
pankkake
how about submit if there was no saved mbid?
2015-01-06 00624, 2015
hawke
Doesn't work if the music is already mb-tagged before being scanned.
2015-01-06 00623, 2015
hawke
I do kinda like the idea of 'verified' acoustIDs.
2015-01-06 00647, 2015
hawke
Probably have to verify them as belonging to a specific track MBID rather than a recording MBID
2015-01-06 00639, 2015
luks
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
2015-01-06 00601, 2015
luks
but I agree that verification against a specific release makes more sense
2015-01-06 00619, 2015
hawke
I think it's hard to tell if it's actually a problem.
2015-01-06 00630, 2015
hawke
Yeah, people might have to re-submit after an edit, but I don't think that's a big deal.
2015-01-06 00648, 2015
hawke
(maybe it is for some stuff, I guess. Not sure)
2015-01-06 00609, 2015
hawke will bbiab
2015-01-06 00610, 2015
luks
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
2015-01-06 00653, 2015
luks
what I'd really like to do relatively soon is start collecting full fingerprints, not just the first 2 minutes
2015-01-06 00607, 2015
luks
but I'm not sure how to update the current processes to that
2015-01-06 00601, 2015
luks
the main problem is cleaning up the database though
2015-01-06 00604, 2015
luks
and I'm afraid that can't be done manually, so I'm thinking how to help the automatic process with minimal manual work
2015-01-06 00659, 2015
outsidecontext joined the channel
2015-01-06 00642, 2015
hawke1
luks: It seems like AcoustID has lately been having trouble with noticing merged recordings. Any idea what’s going on?
2015-01-06 00605, 2015
kepstin-laptop joined the channel
2015-01-06 00636, 2015
luks
yes, I know about that, replication on one of the servers was stuck
2015-01-06 00642, 2015
luks
MB replication
2015-01-06 00652, 2015
luks
it's catching up now
2015-01-06 00626, 2015
hawke1
Oh, OK. Glad to hear that.
2015-01-06 00605, 2015
hawke1
luks: I know the beets 'chromaprint' plugin always submits. So it wouldn’t be too weird for Picard to do the same.
2015-01-06 00655, 2015
luks
doesn't in the context of beets 'always' mean 'when importing'?
2015-01-06 00634, 2015
JesseW joined the channel
2015-01-06 00643, 2015
outsidecontext
for picard it could mean "when saving"
2015-01-06 00611, 2015
luks
O
2015-01-06 00617, 2015
luks
oops
2015-01-06 00627, 2015
luks
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
2015-01-06 00633, 2015
luks
even if it's possibly not correct
2015-01-06 00610, 2015
luks
but I guess that's not such a big problem
2015-01-06 00603, 2015
outsidecontext
does picard currently use the counts?
2015-01-06 00642, 2015
outsidecontext
i think not, but it definitely should :)
2015-01-06 00630, 2015
luks
it should, but what about the feedback loop?
2015-01-06 00603, 2015
outsidecontext
could happen, yes. not sure how big an issue it is
2015-01-06 00609, 2015
Julior joined the channel
2015-01-06 00618, 2015
hawke1
luks: beets can automatically submit on import, but you can submit manually as well.
2015-01-06 00601, 2015
hawke1
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.
