Go check it out!
12 Likes
In the release note it says:
āwith Picard 2.0, Picard Windows builds will be portable standalone binaries.ā
So to try it out, I ran it from another partition then where I have my Picard 1.4 installed.
But 2.0 seems to have adopted settings from my 1.4 installation without asking anything, or me doing anything.
So, contrary to what the release notes say, is 2.0 actually not āportableā?
5 Likes
We even have a warning about configuration files in the blog post. https://blog.musicbrainz.org/2018/07/19/picard-2-0-released/
By portable, I meant that Picard no longer needs to be installed and can be run as a one off binary.
Apart from warnings further down the road, the notes mention something about Picard 2.0 for Windows from now on being portable.
This is what is considered āportableā software:
āTo be considered for inclusion, an application must be executable on multiple computers from removable storage without installation, and without writing settings or data onto a computerās non-removable storage.ā
This Picard 2.0 release is not portable.
It seems to write to the system drive, and it removed settings from my installed Picard 1.4 release.
The description should really be changed to avoid confusion and prevent users misinterpreting what is actually meant here.
(an actual portable version would be great to have b.t.w.)
5 Likes
Quick edit to add - YAAY! for a new version. Keen to try it outā¦
@hiccup thank you from stopping me making a mistake and breaking my current setup. Totally agree that a āPortableā windows application means one that does not touch anything else on the PC. ESPECIALLY other installations of itself.
Where is Picard 2.0 storing its settings? If a portable app the settings should be ini files sitting next to the exe.
āPortableā means I can carry it on a flash drive, drag it from computer to computer, keeping all settings on the flash drive and leaving zero traces behind on the PCs.
Does this release change the old Picard 1.4 settings in %APPDATA%? I want to try out 2.0, but not change any of my 1.4 setup yet.
1 Like
Updated https://blog.musicbrainz.org/2018/07/21/picard-2-0-1-released-windows-and-macos-users-rejoice/
6 Likes
Thatās great.
Is there any chance of releasing a portable version?
That would be very helpful to make it possible to give 2.0 a try without breaking a carefully setup 1.4.
(personally I wonāt use an installed version of 2.0 until at least the Classical Extras plugin is updated to be compatible with it)
1 Like
Does that mean that we should UNinstall previous versions before using this one? I noticed it ran right from my downloads folder, and I used the .exe to overwrite the old one in my program files. But it doesnāt need all the extra program files anymore?
Edit: nevermind, I found the installable version now
Any chance of getting this addressed promptly?
https://tickets.metabrainz.org/browse/PICARD-1247
The change made breaks functionality that worked in 1.4 (but could be improved even from that)
Canāt seem to install any plugins on 2.0.1. 
finally itās not constantly crashing any more, nice!!
1 Like
Since it looks like MetaTunes is making nice progress with preparing his plugin for v2, I decided to already jump ship and install 2.0.
Until now itās running very well indeed, so thanks a lot for all the work that has gone into that.
(Itās not completely clear to me if this thread is strictly for announcing further developments and discussing specific issues, or that more general requests and observations are also welcome here.
So if the following is not considered appropriate for this thread, please let me know.)
.
One of the āuser experienceā improvements I was hoping for is this one:
After doing a lookup, Picard will show a large amount of tags in the bottom panel.
It is not clear to see from looking at the tag names under the āTagā column where those tags came from, and if they are prone to actions/changes.
Some will have been sourced from MusicBrainz, some will be sourced from the files, and some will be both.
Some may have a āPreserve this tagā setting applied, or have an āunsetā script active. Others are completely free for Picard to (over)write.
All the above is currently impossible to discern from looking at the first column only.
Also it is not possible (please correct me if I am wrong) to completely exclude specific tags from showing up in Picard.
For example, my files have a lot of custom created tags, and tags related to audio details of the files such as ReplayGain, ripper/encoder used, comments, etc. , that will never be sourced from the database, and have no actual use for Picard.
It would be great if something could be done to improve on the above.
Perhaps by means of colouring or differentiation in font, and by having a filter to prevent specific tags from showing up in Picard at all.
I think this could improve the user experience for Picard quite a lot.
.
.
edit:
Seeing that @samj1912 ālikedā this post, allow me to make my suggestion a bit more specific:
These are some categories of tags that I imagine could deserve some visual distinction in how Picard shows them in the bottom pane.
- tag frames that are currently present in the file and are fully protected from writing.
- tag frames that are currently present in the file and are protected only from over-writing.
- tag frames that are currently not present in the file and were retrieved from MusicBrainz.
- tag frames that are set to be hidden. (useful for tags such as ReplayGain tags, encoder, comments, occasion, or any tag the user is not much interested in to see in Picard)
These āhiddenā tags could be completely hidden from view, or perhaps assembled at the bottom of the list and greyed-out.
2 Likes
hiccup, be cautious with 2.0 because there was a change made that breaks the preserve tags functionality for custom tags already in the file in some circumstances (see the ticket I posted above). This makes it hard for me to tag right now because if Iām not watching super closely I will lose my custom tags from MusicBee.
5 Likes
Maybe I am performing some āillegalā action, but Picard hangs at, it so I thought to mention it here.
Suppose you have two very simple scripts:
- $unset(album)
- $unset(label)
- Activate (check) only the first script.
- Load one track from an album, perform āScanā.
- After the result is displayed in the right panel, drag the recognized track from the right panel back to āunclustered filesā in the left panel.
- Remove the album from the right panel.
- Deactivate script 1, activate script 2.
- Reselect the track under āunclustered filesā, click āScanā.
Nothing happens, Picard keeps saying āloading album informationā.
1 Like
Thanks for the warning psychoadept!
Thatās indeed a very serious and relevant issue to be aware of.
Hopefully it will get addressed before long, and Iāll be sure to keep experimenting with 2.x for a while longer before I let it touch my preciousā¦
Why is this being called āreleaseā? Surely it should be called ābetaā as it is clearly not yet feature complete and on a level with v1.4.
It is great to see this - donāt think I am being negative - but reading these posts scare me. Features like not preserving tags and breaking many previous plugins show that this is really Beta territory.
I totally second the request for a portable edition so I can help to test without disrupting the settings for my working v1.4
3 Likes
I canāt speak for the developers, but perhaps I can speak as an observer.
Maybe this is a bit indicative for two worlds colliding at the MusicBrainz universe.
One world inhabited by developers and coders, the other one by regular end-users.
I am sure a lot of work and testing has been going on on Planet #1 for the last six years.
But Planet #2 hasnāt been involved too much with that.
What I think I have been noticing:
When an inhabitant of Planet #2 raises something on this forum, be it a bug, a suggestion or a wish, the reply will often be: āsure, you can raise a ticket for thatā.
But that of course is a language and a concept that is not very familiar with inhabitants from Planet #2.
I can understand and appreciate that MusicBrainz has some āelitistā barriers to protect their coders from too much noise from Planet #2.
Some barriers may be forced a bit, some will just be natural.
But MB should then also understand and accept that some of those barriers will hinder popularizing their products and services, and it will also miss out on valuable information and feedback that monkeys testing out machine guns could bring.
(Tesla understands this quite well: āletās have some fun with humans behind the wheels for a whileā)
All kidding aside.
I really feel there is a missing link in the MusicBrainz universe.
Some moderators certainly do their best to mediate on this once in a while, and that is appreciated, but it looks to me that there is nothing structural put in place to gather input from non-coders, create some two-way bridge of communication, and so create a win-win situation for all parties involved.
3 Likes
Picard 2.0.2 released https://blog.musicbrainz.org/2018/07/30/picard-2-0-2-released-signed-macos-builds/
3 Likes
I replicated your steps. Was able to complete the expected action without any problems. Can you post the specific release id or you log instead?