Version 0.91 of TagPy is out

I've just released version 0.91 of TagPy. Besides some minor fixes, the biggest change is that you don't say any more

tag.setArtist("Fat Boy Slim")

Instead, the (IMO) much more pythonic

tag.artist = "Fat Boy Slim"

is now where it's at. Reading these attributes (and just these) is also changed from tag.artist() to tag.artist. I repeat, this only affects

  • Tag.title
  • Tag.artist
  • Tag.album
  • Tag.genre
  • Tag.year
  • Tag.track
  • AudioProperties.length
  • AudioProperties.bitrate
  • AudioProperties.sampleRate
  • AudioProperties.channels

Since these are so frequent, I saw a compelling reason to change them. Everything else in the API will remain as close as possible to TagLib's C++ conventions.

Sorry for the source-incompatible change, it will not happen again.

Enjoy.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Submitted by Anonymous on Sat, 11/07/2009 - 13:34.

Hi Andreas,

I just wonder what would be the best way to copy all of the tags from one file to another (possibly across different tagging standards).

It seems Tag::duplicate() from TagLib isn't implemented in TagPy. Besides that, even duplicate() would only copy over the generic tags. What am I supposed to do if I have tags named on my own (I think these are, except in ID3V1, part of all tagging standards!?).

Perhaps there is a quick-and-dirty way like copying all string objects f.tag() possesses over to f2.tag()? How would this look in a concrete way? Will this work a safe way? Does the encoding of those strings play a role or is encoding-independence part of the abstraction?

I would appreciate some small input. I hope it is not to obvious, im just at the beginning of doing some computer stuff. Thanks!

Submitted by inducer on Sat, 08/08/2009 - 19:55.

Tag::duplicate is now implemented in git. For other, more specific tag formats, you'd have to code your own copying routines, though.

HTH, Andreas

Submitted by TagPy future user on Tue, 29/08/2006 - 14:28.

Hi!

After reading more carefully the TagLib and the ID3 docs, I agree that the dictionary-like interface wouldn't be the "perfect solution" I imagined it would be. Like you mentionned, each tagging standard has some idiosyncracies. For me, some of the main problems are:

  • Ogg allows several values for the same key
  • The frames in ID3 can have different encoding, encryption,...

(I didn't look the APE tags). A dictionary that would support all these differences would be possible (it is one of the way to access the tags in TagLib) but not very elegant.

I still think that, for basic tags, the dictionary is better than the properties (because, deep down, tags are just a set of key-value entries), but I guess it is just a matter of taste. :) Of course, if one of your design goal for this project is to stay close to the original TagLib API, then, yes, properties are the right way to replace getters and setters in Python.

Nice discussing with you. Keep up the good work! :yes:

Slach

Submitted by TagPy future user on Sun, 27/08/2006 - 18:02.

Hi!

I am looking for a library for reading mp3 and ogg tags in python and I stumbled upon your page. I am about to test TagPy.

About the changes, I think that the more "pythonic" way to access the tags would be to have a dictionary-like interface:

tag['artist'] = 'Fat Boy Slim'

by defining the ____getitem____() method and some other methods on the tag class...
(see http://docs.python.org/ref/sequence-types.html for more info).

By doing this, you have a common interface for every tag and you can also make the key (ie, the tag name) case-insensitive.

Slach

Submitted by inducer on Mon, 28/08/2006 - 22:40.

I disagree:

  • This does not and should not cover all tags, as (unfortunately) each tagging standard has its own idiosyncracies past these basic tags. In ID3, you get to meddle with frames, Ogg has the (fantastically simple) Key-Value map, and APE has something still different. Glossing over these differences would be folly.

  • Past that, TagPy does not mean to invent its own API. In particular, I don't mean to write documentation for it at all. It should be sufficiently clear from Scott Wheeler's documentation what the Python API will look like. It just happens that the "right" way to wrap getXXX() and setXXX() calls in Python is to have properties and not separate methods. I got this wrong in the first release.

I appreciate your comment, though. }:) Feel free to refute my views.