I usually generate the AcoustIDs once I match the tracks anyway (why not, more data for MB), so if I can save a few clicks per album while organizing my music folder, that’d be nice. Would that be possible with a userscript?
On a similar note, a script to generate disc IDs from the .log file in the album folder and submit that to the matched album would be useful, I think. EAC/XLD submits the data to CTDB which generates the disc ID anyway, right? So CTDB has a lot of info on albums that aren’t on MB yet. For example, this album has been ripped and submitted to CTDB via AccuRip, but it doesn’t have an MB page.
Personally I think it is better to keep the send fingerprint function split from scanning to avoid to many wrong sent (There are already a lot).
Same for the log part, you go to this URL when you know what you do, else by putting directly in Picard and we end up to have wrong discIDs (App not properly configured, copies on CD-R, personal compilation,…)
I agree with that. But the issue of more transparency and control over fingerprint submissions comes up frequently, we have a couple of related stories. My idea about this is that we should maybe have some kind of submission dialog, where the user can review the matched files that have some data to submit. Maybe there could be an option to automatically show this after saving. I’m not yet sure on the details and how to best show the information, but it could both make it easier to submit and more transparent what is being submitted. And we could include submission of other data, such as to AcousticBrainz (which we’ll have in Picard 2.7).
Not sure it really would lead to this. If someone wants to submit their home-burnt CD-R they can already do this with Picard anyway. I think submission by log would be ok. I think users dealing with this and having an EAC log as part of their ripping + tagging workflow are already rather advanced and care a lot about the data.
Theoretically I agree but in reality I guess you know how end up dialog boxes: users just click without looking.
May be more efficient to invest time in some controls to detect and remove wrong submissions (not speaking more about it as there is already a topic on this).
Or it would be even better (keeping this dialog box idea) to detect those at submission and display to user why they are rejected, then up to the user to review and resend them after corrections (ex: wrong length to edit in the release, relink to correct release,…) else nothing is recorded in the system. That would allow to prevent wrong submissions as improving knowledge of users.
With all the different topics around fingerprints those weeks/months (Bancamp upload, Errors detection, Issues with server,…) do you think something, even basic, could be done?
I agree but it ends up “advertising” this functionality, so the pool of users would definitely increase and potentially the errors. More than CD-Rs what I m worry is about DiscID attached to the wrong release and, compare to fingerprints, we do not see the number of users whom have sent it so would be really time consuming if not impossible to clean up.
This said it could be a function to activate in the parameters to be displayed but what will be the added value compare to what exists today? In other words developing it will cost time for no real gains except increasing the risk of wrong submissions
Ps: Regarding the burnt CD-Rs, not sure many people still do that today and the old ones are no more working now
I think a core problem is that the button just says ‘submit’, and is very accessible. Maybe it’s just me but if I was a new user I would be hitting that button for all kinds of things… But probably wouldn’t guess it’s to ‘submit an audio fingerprint for songs that have been matched in the right hand panel and have been scanned prior’.
AFAIK you should register on AcoustID and paste API key to Picard to submit fingerprints. Totally naive user will not do it and so can not submit fingerprints
This all stems from me just not wanting to submit logs-> MBIDs one by one using that online converter, especially when CTDB already has the MDBID for the CD anyway. If I could just do it from within Picard, that’d be convenient. I have the logs, CTDB has the logs, Freedb has the logs, everyone but MB has the logs.
I actually think there is not much Picard can do here. A significantly different length beyond the AcoustID limit of 30 seconds is actually the only hard criteria that I can think of. The other would be if Picard in general considers this file a bad match to the selected recording based on existing metadata, we could have a threshold here. But there are two downsides:
People also use Picard to tag mistagged files or with missing metadata. E.g. if a CD ripper could not identify the album you might end up with those dreaded “Artist”, “Album”, “Track01” tags. Let’s say you put those into Picard, try to identify via AcoustID without success, then painstakingly match this file to the proper recording. If Picard than just refuses to upload the fingerprint for this match we haven’t won much.
Once you have saved the difference in metadata is gone and you have a 100% perfect match.
IMHO AcoustID already has a solution in place for better quality, just it currently does not work very well in practice: AcoustID has submission counts, both for submitted fingerprints and for links to MB recordings. If this would be used properly you could get a good idea of which data is good and which is probably a bad submission. Tools using AcoustID to lookup can use these counts (and Picard does this). If you have enough submissions wrong submissions become basically meaningless and are easy to identify.
Now in many cases the counts are very low. I think one important reason for this is, that Picard (which probably is the most used client for AcoustID submission) does in many cases not submit the fingerprint again. Basically there are two scenarios:
If a user uses Scan in Picard and AcoustID gives a good result, then Picard matches the file to the found MB recording. But it keeps fingerprint submission disabled (unless the user matches it to a different recording manually). I think this is actually good, because would it enable the submission for the automatic result that would just emphasize the existing data, adding more confidence to a probably wrong result.
If a user does not use Scan to identify the audio via AcoustID but matches the file otherwise there is no submission. And Picard uses to make it very hard to submit AcoustIDs anyway. In older versions you had to move the files back, run Scan on them, match them to the proper recording again and then you could submit. In current versions there is a “Generate fingerprints” action, but I think only a few people actually make use of this properly.
The second case is where I think we could improve things, by guiding the users through the process of submitting data after they have finished their tagging. That would mean we would probably get more submissions. Something that let’s the user submit this data after they have finished tagging, with the user being able to review the submissions. That could also disable submissions for large differences in recording length.
The added value would be to support some users workflow. If you rip your CD with e.g. EAC, save the log and later want to tag with Picard against a release that exactly matches your disc ID (and if it doesn’t match any submit your disc ID) then currently you need to put the CD back in your drive. But often it is more convenient to first rip a bunch of CDs, put the CDs back to the shelf and later deal with tagging the digital files all in one go. If you can do the disc ID submission from the data collected by EAC this helps here. I don’t really see why this should increase the risk of wrong submissions.
I personally also don’t have any use of this workflow, though. If my CD ripper does not find the disc on MB I would submit the disc ID right away. And if it can find the matching release on MB than it will add the corresponding MBIDs to the files, so when I later tag these files with Picard they already match to exactly the release the CD ripper identified. @Tenome Doesn’t EAC offer disc ID submission to MB and adding MBIDs to ripped files?
The only MB feature that EAC offers is looking up the metadata (I assume it reads the disc TOC), but CTDB scrapes MB anyway so I just stick to CTDB in most cases. Otherwise all verifications are sent to CTDB via AccuRip’s plugin. Here’s a log from a 100% rip. The checks are at the bottom.
