Picard 0.16 released (Page 1 of 2)

I installed 0.16, and it seems you have to choose between the old puids and the new acoustids, is there are reason why this has to be one or the other? I'm all for going acoustid, but would like to have puids as a fallback if no acoustid exists.

One more thing too, in addition to luks’ AcoustID in PUID script, there is another script made by a genius, that you can use if you want to see/edit AcoustIDs in the release page.

Unicode punctuation is now converted to ASCII by default.
Why is that ? Or is it only for filenames ? ← ok if so.

1. (removing non ascii characters) I don’t remember any such “feature request” to change track names.
I’ve tested the new Picard, thanks it’s great ! But here are my few remarks
2. When I hit scan, it retrieves a PUID and matches the file in a release BUT the PUID tag isn’t added as it was before (?).
3. The AcoustID tag should be added the same way too.
4. We should retrieve BOTH PUID AND AcoustID (and store them in tag) without having to scan once, go in options to change and scan twice.

Let me rephrase my bad exposed issues. :)
I’ve tested it furthermore and can more precisely exaplain issues now.
Thanks Luks for the great new version by the way !

I don’t remember any such “feature request” to change track names.
I mean I don’t see why it should be default now.

There is another more important regression :
When I hit scan, it retrieves a PUID but the PUID tag isn’t added as it was before (checked in 0.15) in left hand panel.
Same for the AcoustID tag.
You can actually only see them in the right hand panel now, whereas it was displayed in both panels.

And now for something that is for the new AcoustID feature :
As to go on further on what rocketsurgeon666 said, we should be able to retrieve BOTH PUID AND AcoustID (and store them in tags) without having to scan once, go in options click click click to change setting and scan again.

And also the settings where you have to point to AcoustID tool should open a browse window with the fpcalc.exe search instead of *.*. I thought I had to get to fingerprinetr.exe before seeing it was not working and understanding why (reading a link somewhere from here).
I mean I eventually understood because I’m a super genius, but that might not be the case of erevyone.

And last but not least, thank you as the fpcalc.exe seems not affected by the unicode-filename-bug !

What I mean then is why would a new user get a cropped down version of MB data by default ? And where does this change was been had request-ed from into ?

edit:
I’m sorry that this is the least important comment that gets the most coverage.

The other regression is more important : no PUID (nor AcoustID) tag in left hand panel any more (was there in 0.15).
The other feature request is more important too : Retrieve both PUID and AcoustID (and put them bag in left hand panel’s tags)

The fpcalc.exe explanation in the browse dialog is as minor as the first (ascii default) regression.

@jesus2099: I requested that the Unicode-to-ASCII option should be enabled by default in http://forums.musicbrainz.org/viewtopic.php?id=2857, and a submitted patch got merged by Lukáš (I think).

In this case, I would just remove the locale from that alias. As we can only have ONE alias per locale, if the two names are equally correct, neither should be selected as the localised alias IMO.

The locale can be readded as auto edit. :D
And what if my Picad is set to french and I want this japanese artist name to be romanised ? Do we have to store the same romanisation for each locale that exist ? ¹

edit: btw I created the following appropriate tickets
PICARD-66 : Regression : Scanning files doesn't store the found PUID in left hand panel's tags any more
PICARD-67 : Fetching both PUID and AcoustID instead of only one of them
PICARD-68 : Add some explanation in AcoustID settings regarding the calculator
PICARD-69 : Regression : the applied characters are no longer the same as MB data

Those interested in seeing more comprehensive alias information can vote for this bug report:

http://tickets.musicbrainz.org/browse/MBS-843

I have an issue with this, as long as there are both recordings and track title entities in the database _and_ they sometimes differ, would it not make sense to at least give Picard users the option to pick either the recording or the track title?

Which title does it now default to, the track title or the recording title?

There are certainly lots of examples in the database at present where the track title differs from the recording title and is not as good (e.g. (original mix) may be excluded from the recording title, which covers many albums, the original and later compilations), and there are also cases where the recording title is not as good as the track title, because editors fix up the track title and forget to mirror this change to the recording title (and I presume the same scenario could occur vice-versa).

I support the standardisation of the style guidelines for both recording title and track title, but realistically the database is never going to be entirely this simplistic.

It didn't make sense in its previous form because
a) there was no ability to choose on a case by case basis which titles you wanted to use

b) recording titles were rarely useful across an entire collection as they can often lack relevant and required context for a particular release.

If I have a Single with

TrackTitle (album mix)
TrackTitle (single mix)
TrackTitle (no rap)

And the recordings have all been standardised to put the Extra Title Information into the recording comment, then I don't want three tracks all called "Title". And neither are recording disambiguation comments really designed to be used in tags, either.

Similarly with live tracks.

Since the guidelines were changed to require "standardisation" of track titles in the database; except where required for useful disambiguation, like the above, there really wasn't a compelling need for such recording standardisation; and it was just confusing for less experienced people.

c) Data not being correct in the DB has rarely been a reason for a feature to exist in Picard. We should be fixing the data and working with developers to come up with ideas to make it easier to find and fix such problems, not encouraging people to work around it locally.