UI: confirm Chroma is operational

[gwern]

The documentation for the chroma fingerprinting plugin specifically warns the user that it's tricky to set up and may not work correctly:

First, it can be trickier to set up than beets itself (you need to set up the native fingerprinting library, whereas all of the beets core is written in pure Python).

The complexity of the dependencies section which follows suggests this as well, and issue 885 warns me that the solution to it may also break chroma (or so I infer from the solution being to remove one version of the library when somone writes "We've seen some hangs when using both versions simultaneously, as can happen when the chroma plugin is also enabled.")

But while importing, there is no indication of whether the fingerprinting is working or if one is spending many hours doing tagging while crippled! A simple startup message like 'checking fingerprinting is working... fingerprinting seems to be working' would suffice.

(I've discovered that my chroma fingerprinting does seem to be working when I turn on debugging output like beet -v import but this is (1) not something users will think to do, and (2) makes the import interface much harder to use.)

[sampsyo]

Hmm; I'm not certain about an explicit test right at the beginning (I guess we would fingerprint some arbitrary audio file and hope it succeeds, false negatives due to broken audio and unsupported codecs be damned?). People do ask this a lot, though, so what do you think of the following?:

We currently display the "source" for a match in the existing UI: e.g., MusicBrainz, Discogs, etc. We could annotate this with a different source when the match is made by fingerprinting.

Two reasons this is a bad idea:

• It doesn't give feedback when fingerprinting just assisted the matching process rather than providing a wholly new match.
• We'd need to make the source field more complex to treat an MB-via-Acoustid match as an MB match for penalty purposes and an Acoustid match for display purposes.

Could be worthwhile anyway.

FWIW, usually the correct answer in the status quo is "check your CPU usage" :smiley:. Lots of cycles consumed are a surefire indication of chroma working.

[gwern]

Hmm; I'm not certain about an explicit test right at the beginning (I guess we would fingerprint some arbitrary audio file and hope it succeeds, false negatives due to broken audio and unsupported codecs be damned?).

That's not a bug, that's a feature: if audio is broken or one's music files are in unsupported codecs, the user wants to know that as soon as possible regardless of chroma's status!

Could be worthwhile anyway.

Maybe. I think an explicit check serves the purpose better, and such UI changes can be done later if they seem like a good idea still.

FWIW, usually the correct answer in the status quo is "check your CPU usage" :smiley:. Lots of cycles consumed are a surefire indication of chroma working.

That's fine if you're an experienced beets user. But everyone else will have read the manual where it says to expect a lot of CPU usage (and what's a lot?) regardless of whether chroma is being used. And IIRC, all the CPU time is used up by the beets process, so you don't learn much from watching top.

[sampsyo]

Thanks for following up. Even with a few ideas, we have no clear straightforward solution, so I'm going to leave this open for discussion for now.

Just checking up front still seems undesirable to me, because there's no reason the first (alphabetically) file you're importing should be representative at all. If we do want to provide feedback, we should do it on all music. (But this is technically tricky for multiple reasons; namely: plugin hooks for this kind of thing don't exist; fingerprinting happens on a different thread; fingerprinting failure modes are currently hidden behind several layers of abstraction.)

[otakucode]

How about instead of making it part of the import process, add a new supported command like "testchroma"? The user could run that on a track which they know is good and verify it worked correctly... or perhaps find a small openly-licensed audio file to include with beets that has a known fingerprint, and beets could just attempt using chroma on that and report whether it got the right result?

[sampsyo]

That is a good idea. In fact, we already have the fingerprint command—you can just give a single track to this command and see if it succeeds.

[azrdev]

I'd strongly favourite the idea making fingerprints an additional datasource, it seems to be the most straight-forward way to get "fingerprint assistance" into the UI.

[smichel17]

New beets user here.

I have a couple albums that have really bad metadata (eg, missing track names, just "Audiotrack 01", potentially multiple albums in the same directory, etc). I decided to use Acoustid to try to find metadata for these songs.

I enabled chroma and used beet fingerprint to (successfully) tag my library. Then I re-ran beets import to update the metadata now that everything is tagged... and I have no idea if it is working or not. It doesn't seem like I'm getting recommendations that are any different than before, but I have no idea if that's because I should be using a different set of option for import, or whether the fingerprints are not being used to find metadata.

I hope you'll reconsider how important this feature is; I consider it to be critical, as the chroma plugin is currently useless to me.

[sampsyo]

@smichel17, for your particular predicament, have you tried turning on verbose mode to confirm things are happening?

And just to be clear, we (the usual developers) do think it's important! We just can't do everything at once. If you're particularly interested in a feature, please consider pitching in.

[smichel17]

@smichel17, for your particular predicament, have you tried turning on verbose mode to confirm things are happening?

I hadn't; I'll try that and open an issue elsewhere if I can't figure it out from there, so I don't clog up this issue.

And just to be clear, we (the usual developers) do think it's important! We just can't do everything at once. If you're particularly interested in a feature, please consider pitching in.

I know how that goes. I just wanted to offer my perspective as a new user - that this was the first roadblock I encountered that felt like an error with the software rather than my own mistake*. I don't expect anything of you except that you'll read my feedback (and then heed or ignore it as you please).

I also have a million and one things on my list and -- just being honest -- getting familiar with the beets code base is not a high priority right now (it is on the list of things I'd like to do eventually). I can probably make a PR to the chroma documentation to include that tip about running in verbose mode, if you'd like.

*Aside: Imo, "user error" usually means "design has room for improvement", but things that feel like user error are still generally lower priority than those which feel like bugs.

[sampsyo]

Thanks for the feedback! And yeah, that seems like a good addition to the docs if you end up with an extra moment.

[smichel17]

Found my extra moment, just a couple years later. Slowest sentence I've ever written :)