Given that my elaborations are not making things more clear, I will try one last time to make things more clear. But before I go on, remember that there are bugs in the system right now. What I am going to explain is NOT how its currently working. If you observe behavior that is different from what I am saying, its BECAUSE THE SYSTEM ISN’T WORKING PROPERLY YET! If you’re confused and don’t understand, stop using Picard 0.7.0.
Music analysis vs fingerprinting:
There are two processes that MusicIP makes available. Fingerprinting and music analysis. Let’s touch on music analysis first — this is the process that takes a while (Yes, I know its slow. Yes, I know its going to take days to analyze your collection. Please stop telling me that!) The process of doing music analysis examines up to 10 minutes of a track and examines all sorts of things I know nothing about. All I know is that in order to generate a new PUID, you must analyze a track fully. This full data collection portion is what allows the MusicIP mixer to generate playlists of similar music. This is the secret sauce that makes MusicIP tick and thus this is not going to be open sourced, no matter how much we ask.
Fingerprinting is much smaller process — it only analyzes about 2 minutes of the track. You cannot generate a new PUID to insert into the database from the fingerprinting process. There is not enough information in this process. There is enough information to create a PUID that is suitable for doing an identification, but not for submission. This works a lot different than TRM — this system doesn’t create rampant amounts of useless fingerprints that will never be used.
Submitting PUID’s from Picard:
When the process works, you do a full music analysis on a track and the system generates a PUID for you within 24 hours. But this is not working right now, so Picard will not likely prompt you to submit PUIDs. This means the submit button stays greyed out.
Why can’t we have Picard generate PUIDs?
Because we don’t have that code. Please stop asking for ponies — we’re fresh out and you can’t have one. Telling us that this sucks won’t make it any better. Please keep your comments to constructive criticism.
I don’t understand — its not working as you say it should:
Did I mention that there are some bugs? If it doesn’t work for you, stop using it. We’ll fix it.
Rude comments:
“Reading up on good interface design would also be a suggestion Just google good user interface design” — Please tell me where your FREE software is so I can download it and insult your hard work. I’m sorry that this FREE program isn’t working for you.
Technorati Tags: musicbrainz, picard
MetaBrainz Blog 
Well, it’s helpful to understand that there’s a difference between fingerprinting and analysis. I do have some questions about the difference, though.
Is the idea that with the fingerprint data generated by libofa, you can only do a “lookup” on the MusicDNS web-service, which may (or may not) return a PUID if a sufficiently close match has already been submitted via the closed-source MusicIP Mixer?
When the submission process “works” (in the fullness of time) how will you get the PUID to submit? Will it be taken from the tags written by the MusicIP Mixer?
At any rate, thanks for the helpful clarification that allowed me to at least pose these questions, which I think I know the answers to.
@alex
I’ll second alex’s questions and ask a few more.
So Picard can generate a fingerprint. Does it then query MusicDNS for a PUID whose deep analysis is consistent with the fingerprint (given user-specified closeness parameters) – or does it algorithmically generate a ‘candidate PUID’ from the fingerprint and then ask MusicDNS to match it to a reference PUID which was created from the deep analysis? Or neither of the above?
In either case, it seems like anyone who wants to support MB by creating ids that others can use for identification will always be required to use the MusicIPMixer – that is what you’re saying, right?
Generated fingerprints are sent to MusicDNS in order to access a PUID. If a PUID is available, then it will be returned.
Currently, new PUID’s are only generated when using MusicIP Mixer. I’m working on a “genpuid” program which can be used to generate and submit the appropriate info to create a puid. This will mean you can either use MusicIP Mixer, or genpuid to put new puid’s into the system.
We should be back into a 24 hour cycle by the end of today, and we’ll be working hard to (A) guarantee that minimum turnaround and (B) shorten it where possible.
Forgive me for dumb question. At the top we just said there wasn’t going to be an open source PUID generator, now you say you’re writing genpuid. Is this contradictory, or is genpuid going to be closed source? I assume therefore that you have either signed an NDA or work for musicip?
Being closed source is no biggie as far as I’m concerned (other than potential support / longevity issues). After all, until someone puts in the (no doubt considerable) time to come up with a better solution, it’s by far the best we’ve got (seems much better than TRM to me), and one has little sympathy with all those people shouting at you to write something for them for free…
I love Picard and MusicBrainz and am extremely grateful for all the hard work you guys are putting into it.
Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! 😀
Max: Yep, I’m one of the MusicIP developers. The genpuid program will be closed source. I’m working on it right now, in fact. Once I get the basic functionality working, I’ll be looking for feedback on making sure it covers everybody’s needs as best as possible (without taking up a lot of dev time on my side).
We’ll probably be doing most of the discussion on the MusicDNS portion of the MusicIP forums.
I’m about sick of the spoiled brat whiners too. Bravo.
And at further risk of sounding like a kiss-ass: Thank you, to all the devs who are working so hard on this project.
I still have problems to understand the meaning of the button “send tagged information to MB”.
If I analyze some MP3s, they are first copied to the “ungrouped files” section. Pressing the “analyse” button, lot of them are copied to the “album” section, but some stay again in the “ungrouped file” section. If I put them manually to the “album” section using drag & drop, I finally get the opportunity to use the “send tagged information” button. The status bar says “sending PUID information”, but why, if it is said not to be possible to generate PUIDs with Picards built-in analyzer?
Furthermore: I used the same MP3s some days ago with beta 1. Then, the files had a very bad recognition value (<10 percent, although the album was in the MB-db). Then, I used the “send tagged information to MB” button. Today with beta 2, all songs are said to have a 100% recognition, although still some of them stay in the “ungrouped file” section.
It would be great if someone could clarify this as I want to write an article on MP3 tagging and would really like to understand this open source idea of fingerprint-supported tagging.
On the new PUID generation problem:
The obvious solution is to request a command-line program that generates PUIDs. This program can then be called from Picard. This avoids GPL problems, while still allowing excellent integration. I might worry about the performance issues of creating a new process to identify each track, but if it’s taking several minutes then who cares about the process overhead.
Incredible.