I noticed that the total time needed to match the tags is similar, about 1.5 hours in the two cases.
When I completely clear the tags using Mp3tag and when today I uploaded a catalog with my music without cleaning.
Is it normal?
15 days have passed.
-
Picard’s tagging efficiency - one album per second 5000 / 60 = 83 minutes (I guess the bandwidth doesn’t matter).
-
The result of 471 of standalone recordings remained (if I had cleared the tags before, the result would probably have been worse).
-
Picard was set to save cover art to tags. Despite this, it again saved over 4000 500x500 covers to the C:\Users\***\AppData\Local\Temp directory. When you turn off Picard they disappear. I thought it was a Windows utility cleanup.
- Why is an application restart required to change the language of the Picard interface? Other applications do this on the fly. After changing the language I have to wait again for my music catalog to load.
Yes, roughly. 1 request per second is the MB web service request limit. Loading a release takes 1 request (usually, releases with huge number of tracks can take additional requests).
Picard has to keep those loaded covers somewhere. It could keep them in memory only, but that can quickly mean gigabytes of RAM used.
It would require quite some effort to implement replacing all strings while the application is running, and all the dialogs would need to implement the code to listen for language change and update all the strings they are currently displaying. There are more important and interesting things to do.
You can also finish what you are doing and have the new language on the next restart. Beside both changing language and loading all files you have are both things you probably don’t do every time.
7 Likes
@outsidecontext and my first post?
Why does it take so long to reload a directory that hasn’t been cleaned up?
After all, the files already have tags saved in them.
And here it looks like Picard reconnects to his server for every song.
Yes, that’s what Picard does. If the files already have been tagged and have the recording and release MBID stored Picard automatically loads the files into the right pane with the release info from MB. That way you can update the tags.
You can disable this in Options > General > Ignore MBIDs. Then the files stay on the left. But of course you don’t get the updated metadata.
You can’t have updated metadata without loading it.
5 Likes
During normal use, I use Polish. For the purposes of the forum, I change the language to international.
So explain to me again.
Since Picard connects to its server regardless of whether the MP3 has tags or not (it takes the same amount of time), what difference does it make for Picard whether the music directory has tags cleared or not.
-
If the tags contain the release and recording MBID Picard can match the files to the exact release on loading. That means you can do the work of matching your files properly once, then load them into Picard to just update the tags any time without the need to do all the work to match them again.
-
If the files have reasonable correct tags (even if it is just artist and title, maybe with some typos) but no MBIDs Picard can use those existing tags to match the files. This of course is for “Lookup” (= metadata search), but it is also true for “Scan” (= acoustic fingerprinting), as the metadata then helps Picard decide for the proper release and for avoiding complete mismatches.
-
If the files have no tags at all the only thing you can do is use Scan or manually search and match (which might be more difficult for you as well without tags). If Scan delivers multiple recordings, each probably on multiple releases, Picard has no hint helping it to choose the proper one (except maybe your preferred release settings).
Note that by default Picard attempts to guess track title and artist from filename if those tags are empty, so at least those tags might be set when loading the files.
-
If files contain completely wrong tags, e.g. had been by mistake tagged as a different track, then this can mislead Picard to load the wrong recording or not match at all (because the matching is so bad it falls under the similarity threshold).
In this case it might actually be good to clear existing tags and rely only on acoustic fingerprinting to identify the song.
6 Likes
So the best solution is:
clear tags only once and then only update?
1 Like
Once you have identified a track, don’t clear tags. Just update.
When I scan I usually have files with tags from the ripping stage, but I still find sometimes a track is swapped to a different album. Once I fix that album error I’ll save the tags.
Now I have the MBIDs pointing to the correct release.
Next time I load the album into Picard it can go direct to that album via the MBID and find me any credit updates.
Personally I would never clear tags before a scan. I want to give Picard all the clues I can.
1 Like
I’m also interested in the “Clear existing tags” option in Picard.
At what point does this cleaning work?
Is there such an order? :
I open Picard
I check the option
I’m adding a directory
clears tags
I click Scan
I save my work
What happens if I forget to uncheck this option?
The next time I open Picard and add a directory, will it silently clear my tags and I will lose “my” work?
It works when writing the files. By default tags that do not get set in Picard but present in the tags will be kept. The tags will also show up in the metadata view at the bottom, but old and new value are the same.
If you have “clear existing tags” checked then Picard will completely clear all tags in the files and only write those that are explicitly set (i.e. those that got set from loading the release, by plugins or scripts or manually by you). In the metadata view those tags will also show up, but be marked for deletion.
Is this about individual tag fields?
Picard only fills in the missing fields?
And when does it correct incorrect fields?
It also updates existing fields. You can see in the bottom metadata view which tags get written and which get changed.
I’m interested in the song Focus - “Hocus Pocus”
I loaded the file into Picard
I checked the option in Picard “Clear tags”
Track number turned red.
I applied the changes.
When I reloaded the file into Picard Track the original value is still there.
Where is it stored if even Mp3tag doesn’t remove it?
In the file name. Track number is one of the tags Picard tries to guess from the filename if it is not set.
1 Like