For those who don’t saw it in the blog already a reminder that we have put out a Picard release 2.1.0dev2 for general testing and help in finalizing translations. Our goal is to release a stable Picard 2.1 before end of year, which will provide a great amount of fixes and improvements over the current 2.0.4 release. Thanks for your help! More details in the blog post:
I’m checking out Version 2.1.0.dev2, and noticed something that seems odd.
I’m dragging album folders into the middle column, then I select all and “Cluster.” Select the clusters and “Lookup.” Some of my albums are showing a changed MusicBrainz Release Id. I was under the impression that the Release Id was like the primary key for a release, and was inviolate.
it seems odd that most of my test cases have done this., but this is the first time I’ve tried to cycle through my library after tagging for the first time, so this may be normal. Corrections to my thoughts on the Release Id are welcome.
If you are re-tagging your files you really should keep Options > General > “Ignore MBIDs when loading new files” disabled. If this is unchecked (default) Picard will automatically load added files ino the right pane based on the MusicBrainz Release Id and MusicBrainz Recording Id. Otherwise if you drag files from the right back to the middle column the assumption is that you want to do a fresh identification of those files, as the middle pane always holds untagged files.
I found a couple of issues when testing Picard 2.1.0 dev2.
After saving any track and refreshing its release in Picard, it indicates it has to be re-saved again (no green checkmark) despite there being no tag differences. Cover art is disabled (I also tried after enabling and downloading the cover art, same result). All scripts and plugins disabled. Screenshots here: https://imgur.com/a/bwBFALG.
There seems to be an issue with a multi-value TXXX:ARTISTS tag. After loading a file that has been tagged in Mp3Tag/Foobar into Picard, it shows the tag as empty. After saving it in Picard and loading it in Mp3Tag/Foobar again, the tag shows twice (e.g. tag with 2 values is showing as tag with 4 values now). Screenshots here: https://imgur.com/a/urlYauL
My custom file name for cover art doesn’t seem to work anymore. The string is “Cover\\$replace(%albumartist% - %album%$if(%date%, [%date%],),\\,_)” (minus the quotes). Debug logging shows the following error: https://pastebin.com/raw/g4XQT7mZ which I guess is just an invalid syntax in my script. As far as I remember the script worked in 1.4.2, so my guess is that something changed with the new python version and it should be modified now?
I can provide more information if needed. Also I will be frequenting IRC for a bit so you can message me there as well.
Thank you. As soon as I read that, A light went on in the dim recesses of my brain indicating that I knew this. It’s been a few months since I worked with Picard. I should have done a better job of documenting my process. (I was dragging from the left column.)
Cool. There is some logic in it. I am also pretty sure that the “merge” means any program that attempts to lookup that older MBID will still be directed to the correct record. One of the nice design features of the merge process.
I can reproduce this, I added a ticket and submitted a fix, see PICARD-1437
I cannot reproduce the behavior you described, but it must be related to the changes how we store artists in ID3. We used to store it as TXXX:Artists, but changed this to TXXX:ARTISTS for better compatibility across tools (including MP3Tag). Picard also updates tags, so this duplication should not happen. Do you have any scripts setting ID3 tags directly like e.g. $set(_id3:TXXX:artists,something)?
I can’t directly reproduce this, but I can see what happens: Somehow the file name ends up with a newline after the filename, which is not valid for a filename. We definitely need to clean this up. I’m still curious how you managed to get this in, I tried copy and pasting a line break explicitly in the cover art naming, but this did not carry over (it showed as whitespace in the options, though). Do you have any idea how this came to be? What Windows version do you use?
Update: Patch for the cover art issue is also coming, see PICARD-1439
Interestingly enough, after I checked “Clear existing tags” setting in Options/Tags and saved the file, Picard will show the checkmark for this file from now on even if I uncheck the setting afterwards. With more testing, I found out that if I removed “genre” and “albumartists” tags from my files, I got the checkmark again. I don’t populate the genre tag with mb data yet and albumartists tag is currently written as “TXXX:albumartists” instead of “TXXX:ALBUMARTISTS” and currently is not an official tag (shameless plug for https://tickets.metabrainz.org/browse/PICARD-700). So in conclusion, if there were any tags in your files that didn’t match their equivalent to mb data, the files didn’t receive the checkmark and would be re-saved again (we also have an issue for this here: https://tickets.metabrainz.org/browse/PICARD-300). Your fix might already make the checkmark to be be displayed again, I am mentioning this just in case.
I tested this a bit further and I found out that Mp3Tag indeed saved the tag as “artists” instead of “ARTISTS” but ONLY if I changed the tag in the main UI. If I changed them via the “Extended Tags…” function, they were correctly saved as “ARTISTS”. My guess is that I when I tagged my files in the past, I saved multi-value tags this way because the single-value tags in my files have the correct “ARTISTS” tag. So there is no bug with Picard I will report this bug to Mp3Tag forums momentarily.
It looks like my script got corrupted somehow and Picard.ini showed the following setting: cover_image_filename=“Cover\\$replace(%albumartist% - %album%$if(%date%, [%date%],),\\,_)\n” In the UI it was showing as a whitespace and after removing it everything works properly.
This addresses the issues reported here, so some feedback if everything is resolved is very welcomed. @culinko: I’m especially interested if the reload issue is fully fixed by this.
While the focus was on bugfixing and improving the build process, two new features also sneaked in. I expect this to be the last dev built before we release the final Picard 2.1.0.
Unfortunately we still have some trouble quickly updating the website, so no update notification as of now. But we’ll make sure to get everything in place for the final release. Thanks a lot for all your testing and feedback, it has been a big help so far.