While playing music today, I noticed a bug in display of album names. They were displayed without capitalisation changes. The problem is in md_pp_capitalize(). It creates a local variable called mdalbum instead of modifying md.album.
Here are two patches: one to fix that bug, and another to apply on top of that, instead of the first one I sent a couple of hours ago. Both against svn version 282.
Index: src/metadata.py =================================================================== --- src/metadata.py (revision 282) +++ src/metadata.py (working copy) @@ -557,7 +557,7 @@ if md.artist: md.artist = string.capwords(md.artist) if md.album: - mdalbum = string.capwords(md.album) + md.album = string.capwords(md.album)
def md_pp_strip_leading_article(md): # strip leading "The " in artist names, often used inconsistently
Index: src/metadata.py =================================================================== --- src/metadata.py (revision 282) +++ src/metadata.py (working copy) @@ -552,13 +552,25 @@ ##############################################################################
def md_pp_capitalize(md): + def capwords(s): + words = string.split(s) + cwords = [] + for word in words: + if word[0] in string.letters: + cwords.append(string.capitalize(word)) + elif len(word) > 1 and word[1] in string.letters: + cwords.append(word[0] + string.capitalize(word[1:])) + else: + cwords.append(string.capitalize(word)) + return string.join(cwords) if md.title: - md.title = string.capwords(md.title) + md.title = capwords(md.title) if md.artist: - md.artist = string.capwords(md.artist) + md.artist = capwords(md.artist) if md.album: - md.album = string.capwords(md.album) + md.album = capwords(md.album)
+ def md_pp_strip_leading_article(md): # strip leading "The " in artist names, often used inconsistently if md.artist and md.artist.startswith("The ") and len(md.artist)>4:
Hi Russell,
On 11.06.07, Russell Steicke wrote:
While playing music today, I noticed a bug in display of album names. They were displayed without capitalisation changes. The problem is in md_pp_capitalize(). It creates a local variable called mdalbum instead of modifying md.album.
Thanks for catching that.
Here are two patches: one to fix that bug, and another to apply on top of that, instead of the first one I sent a couple of hours ago. Both against svn version 282.
There is a small problem with that one, though: If you don't use the C locale, string.letters may also contain non-ASCII characters and then "s in string.letters" fails for any Unicode string. In the present case this means it fails always. This seems to be one of the cases where Python's unicode support is still lacking...
Cheers,
Jörg
On Mon, Jun 11, 2007 at 04:02:03PM +0200, Joerg Lehmann wrote: ...
There is a small problem with that one, though: If you don't use the C locale, string.letters may also contain non-ASCII characters and then "s in string.letters" fails for any Unicode string. In the present case this means it fails always. This seems to be one of the cases where Python's unicode support is still lacking...
Yes, I hadn't thought of that. Does string.punctuation suffer from the same problem? Are there punctuation characters in Unicode outside the ASCII range? (That question may reveal that I don't fully understand the problem...)
I'm going to leave the patch in the version I run, though, as all my .oggs have ASCII tags at the moment. :)
On 12.06.07, Russell Steicke wrote:
On Mon, Jun 11, 2007 at 04:02:03PM +0200, Joerg Lehmann wrote: ...
There is a small problem with that one, though: If you don't use the C locale, string.letters may also contain non-ASCII characters and then "s in string.letters" fails for any Unicode string. In the present case this means it fails always. This seems to be one of the cases where Python's unicode support is still lacking...
Yes, I hadn't thought of that. Does string.punctuation suffer from the same problem? Are there punctuation characters in Unicode outside the ASCII range? (That question may reveal that I don't fully understand the problem...)
No, you're question is fully right and in fact, I had the same idea. Maybe a better solution indeed would be to replace the logic in that way. I also don't know, though, whether string.punctuation lies always in the ASCII range (but it's definitely more probable).
I'm going to leave the patch in the version I run, though, as all my .oggs have ASCII tags at the moment. :)
I guess it's more that you run with a C locale. The PyTone version in the SVN repository internally uses Unicode strings for all tags. And this definitely fails:
u"123" in chr(130)
Cheers,
Jörg
Just to conclude this thread:
On 12.06.07, Russell Steicke wrote:
On Mon, Jun 11, 2007 at 04:02:03PM +0200, Joerg Lehmann wrote: ...
There is a small problem with that one, though: If you don't use the C locale, string.letters may also contain non-ASCII characters and then "s in string.letters" fails for any Unicode string. In the present case this means it fails always. This seems to be one of the cases where Python's unicode support is still lacking...
Yes, I hadn't thought of that. Does string.punctuation suffer from the same problem? Are there punctuation characters in Unicode outside the ASCII range? (That question may reveal that I don't fully understand the problem...)
I now checked in a patch based on the use of string.punctuation. Wheres this is not optimal neither, it should still work most of the time (tm).
Btw, did you test the SVN version a bit. I'm really interested in some feedback, because so far there was not so much... Anyway, I'd like to release the new code rather soon.
Jörg
* Joerg Lehmann joerg@luga.de [2007-06-14 18:05]:
[...] Btw, did you test the SVN version a bit. I'm really interested in some feedback, because so far there was not so much... Anyway, I'd like to release the new code rather soon.
I can give it another try next week and test the SVN version ...
I made my objections against some parts already in another thread ;-)
Greetz Stefan
========================================================= My very personal wishlist for Pytone - just ignore it ;-) ========================================================= * BPS recognition Show the bits per seconds from a song in the MP3 info window
* Pause between tracks
* Some sort of replaygain
* Extended search function -- Stefan Wimmer swimmer@xs4all.nl
* Joerg Lehmann joerg@luga.de [2007-06-14 18:05]:
[...] Btw, did you test the SVN version a bit. I'm really interested in some feedback, because so far there was not so much... Anyway, I'd like to release the new code rather soon.
Hi Jörg,
as promised I tested the latest svn-checkout and I have to say that there are not so much changes regardings the problems I have :-/
OGG-format is now supported indeed but the parser is still not able to read special characters like á, é, í, ñ (2.3.0 was prefectly able to do this). The chars are not shown in the filessystem list nor in the taginfo. I'm using UTF-8 on my systems btw. ...
It seems also that capitalized letters after a / or ! (did not run against other letters but still possible of course) will be converted automatically to small letters. I'm commented out
#postprocessors = capitalize strip_leading_article add_decade_tag
since I used "tags_capitalize = false" in 2.3.0 ... What's add_decade_tag btw?
The biggest no-go for me is still the handling of playlists :( Of course they are supported internally but I simply *need* an export function to be able to use the playlists I create on my mp3-player as well. Stop.
Thank you for your great work and efforts Stefan -- Stefan Wimmer swimmer@xs4all.nl
Hmpf - I forgot completely that the bug with my second soundcard (https://www.luga.de/pipermail/pytone-users/2006/000357.html) still persists as well :-/
Sorry about that Stefan
========================================================= My very personal wishlist for Pytone - just ignore it ;-) ========================================================= * Pause between tracks
* Some sort of replaygain
* Extended search function -- Stefan Wimmer swimmer@xs4all.nl
-
Joerg Lehmann -
Russell Steicke -
Stefan Wimmer