[#PICARD-50] Picard not applying "convert unicode punctuation to ascii" setting to album-level metadata - MusicBrainz JIRA

Picard

Picard not applying "convert unicode punctuation to ascii" setting to album-level metadata

Created: 23/Sep/11 06:41 AM Updated: 20/Oct/11 05:10 AM Resolved: 17/Oct/11 11:00 PM

Component/s:

Tags & Metadata

Affects Version/s:

0.15, 0.15.1

Fix Version/s:

0.16

Description

« Hide

See http://forums.musicbrainz.org/viewtopic.php?pid=15524

At first glance it looks to me like album.py:_parse_release() needs a call just after line 95 like

# Convert Unicode punctuation
if self.config.setting['convert_punctuation']:
    m.apply_func(asciipunct)

There is the wider issue of the weird behaviour you get due to some things reading metadata from the album object, but some from the track object, but that may be a separate ticket...

Sort Order:

[ Permalink | « Hide ]

Michael Wiencek added a comment - 17/Oct/11 11:00 PM

Applied voiceinsideyou's fix in http://git.musicbrainz.org/gitweb/?p=picard.git;a=commitdiff;h=fce9d38cdc495cc265c2c59afdd5d58d52334918

[ Permalink | « Hide ]

voiceinsideyou added a comment - 18/Oct/11 12:37 AM

Ahh, cool. I never actually tested that "fix" - it was just an off the cuff thought, so not sure if it has any side effects. I was also planning to do a bit of digging and see why the bug reports mentioned sometimes it was correct and sometimes not - it indicates that Picard is not consistent as to whether it reads the release artist from the track or the album entity internally?

[ Permalink | « Hide ]

Michael Wiencek added a comment - 18/Oct/11 04:28 AM

Don't worry, I tested the fix first and it solved the issue.

There was actually another underlying cause here which I realized I fixed in an unrelated commit. I verified that when the "Details..." window opens, it's indeed consistently reading everything from track metadata. So I was confused why Album Artist and Album Artist Sort would have non-ASCII characters in them, when asciipunct definitely ran on the metadata. The reason turned out to be that the album metadata was being re-copied into the track metadata (it did this as a hack, just in case the album metadata was modified by a plugin, we wanted to copy back the changes). Anyway, since commit 2b30ad3a769dd602875dbfb05f9ab127b2caff86 it no longer uses that hack (and with your above fix we probably never would've noticed anyway).

So I'm fairly sure this specific issue is fixed, unless there's other weird behavior I didn't notice.

[ Permalink | « Hide ]

voiceinsideyou added a comment - 19/Oct/11 07:56 AM

Awesome; good to have someone taking a critical look at some of these long-standing weirdnesses!

is there a current vague aim for timing of 0.16 release? I'd really like to get a couple of fixes in - especially ~~PICARD-54~~ which is a regression in 0.13 onwards - perhaps I need a bit of time pressure to kick me in the butt?

[ Permalink | « Hide ]

nikki added a comment - 19/Oct/11 09:14 AM

voiceinsideyou: luks and bitmap were planning a release of some sort this weekend - http://chatlogs.musicbrainz.org/musicbrainz-devel/2011/2011-10/2011-10-17.html#T19-39-24-891751

[ Permalink | « Hide ]

voiceinsideyou added a comment - 19/Oct/11 09:41 AM

Argh; not much chance of me being done for that

[ Permalink | « Hide ]

Michael Wiencek added a comment - 19/Oct/11 08:25 PM

Ah, well nice to see that you have a pull request for ~~PICARD-54~~ at least. What were the other fixes you were working on? I can help take a look at one or two of them, but I guess it depends on the complexity of the ticket if they can be fixed in time.

[ Permalink | « Hide ]

voiceinsideyou added a comment - 20/Oct/11 12:53 AM - edited

Yeah; decided to sort out the rest of ~~PICARD-54~~ last night in the end. None of the other fixes were critical, or had much real progress made on them, so no big deal

[ Permalink | « Hide ]

Michael Wiencek added a comment - 20/Oct/11 05:10 AM

Okay, sounds good, they can always be revisited for the 1.0 release.