Lukz is best to answer completely, but if you look here: https://acoustid.biz/, you will read that it is somewhat integrated to MusicBrainz, but is separate. At least that is my interpretation. A working relationship.
It is a separate project, created and maintained by @lukz, former MusicBrainz developer who worked on all different parts of MB.org And beside this the connection is of course that MusicBrainz and MusicBrainz Picard use AcoustId as a fingerprinting solution; and AcoustId makes use of MusicBrainz metadata.
Ah thanks for clearing that up.
So this is a known side effect (sacrifice) of efficiency, am I understanding correctly?
Do you think / see it possible that something might give some motivation to supply us with a new and revised (and perfected) acoustID system? The more I play with this, the more I like it… especially if there was a “proper” implementation to use. Not that it is entirely bad now, I am just agreeing that there are some issues.
Also, do you think there might be a utility made, or a function added to Picard, to allow for fingerprints to be generated, without having a lookup run to the MB database, and having the option to embed this data into the files themselves? Or even a reference file like extraction logs or dynamic range report logs? I could see this as an amazing tool for an end user. I wont clutter with my crazy imagination, but imagine if I had a player/software for my collection and when I add a new CD, it would look at my collection and identify via fingerprint which recordings are already in there. Or using it for a better tool, where I “shazam” a song I hear, it identifies it and knows the fingerprint, and tells me if I have that recording in my collection. I am getting excited. Call it “acoustify” instead of shazam.