Extending TagLib::Tag's interface.

[Peter van Hardenberg]

Since I haven't mentioned it yet, I should probably note that I'm doing this work for Songbird's 0.6 release, so unless I hear a resounding "don't bother" I can pretty much guarantee some kind of patch making its way to the list. To that end, I just skimmed the history of taglib-devel looking for threads relevant to this project and collected some things I ought to ask on the list about.

1) 2.0?

With 1.5 out in the wild, is it time to start a 2.0 branch? My life will be much easier if I can break binary compatibility. I know Scott has posted some thoughts on what he wants for 2.0, and I think I can contribute to that. On the other hand, if now is not the time to branch, I'll need to do some heavy thinking about how to implement additional fields in a way that is upstreamable without breaking binary compatibility and I will definitely accept suggestions. Songbird is compiled without RTTI enabled, making life even harder for me.

2) Tag::*

Attached is a patch against tag.h which adds a whole heap of fields to the base interface. I have been implementing all these fields using the most canonical information available, the ID3v2 spec, the Xiph.org wiki, the Creative Commons wiki, and such. When I have the rest of the tag formats implemented, I'll attach a new patch and then we can work out the details of field names on a per-field/per-tag basis.

Which bits of metadata deserve promotion to Tag::*? Which ones are just giving me carpal tunnel for no reason? 

3) Tag::supports*

Currently, I allow setting an unsupported field on a tag as a no-op, and getting to return null/0/false. Right now I think adding "supportsWhateverField()" with a default implementation of "return false;" would be a reasonable way to let people figure out what their tag formats will do for them. I prefer no-opping to explicit failure for unsupported fields since writing out metadata is usually a non-interactive process where as much information as the file can capture is written. If that makes people go all squinty and press their lips together with disapproval I might be convinced otherwise.

4) totalTracks()

The base Tag::(set)track interface does not provide support for totalTracks. Obviously binary compatibility reasons prevented this from being changed. APE/Vorbis comment seem to be largely standardized on TOTALTRACKS, which could be promoted while still providing support for any other widely used field names in a method similar to the current comment() implementation. ID3v2 still recommends the "/" syntax which could be made available through the Tag interface. 

Furthermore, a clever Taglib::XiphComment::Tag::totalTracks() implementation could even support reading and writing both the combined ID3 style storage and a separate two-field approach. I will gladly implement this for you.

5) Tag::set(anyProperty)

In addition to the core metadata properties I would like to be able to set my own completely arbitrary properties in a generic way across all supported Tag implementations. I would also like to be able to enumerate these properties, and, maybe even as many of the properties as can be reasonably interpreted. This is probably worthy of a thread all its own.

6) Images / Timed lyrics / Binary data in general

I have no desire to do any of these at the Tag level and I don't think there is nearly enough consensus between the various specs to make this reasonable.

And with that, flame away!

-pvh


----- Original Message -----
From: "Peter van Hardenberg" <pvh at songbirdnest.com>
To: taglib-devel at kde.org
Sent: Tuesday, April 22, 2008 1:33:26 PM GMT -08:00 US/Canada Pacific
Subject: Extending TagLib::Tag's interface.

We are using TagLib::Tag at Songbird for prototyping our metadata writing functionality and of course, it only supports a few of the most basic fields. I'd like to extend this list of fields to include more of the set of properties which are defined in ID3v2 and widely accepted by the Vorbis comment/APE community such as "composer". 

I would also like to implement an "extended(propName)" / "setExtended(propName, value)" function pair to provide a more general metadata storage for custom properties. I'm open to suggestions on how to implement this, but I think that for xiphcomment and ape, this would mostly be a matter of getting/setting the upcased value. For ID3v2, I was considering following iTunes' example and creating a comment with that fieldname as description.

The Creative Commons guys are also interested in having easier ways to store and retrieve license information from files.

Patches will follow as I produce them.

-pvh
_______________________________________________
taglib-devel mailing list
taglib-devel at kde.org
https://mail.kde.org/mailman/listinfo/taglib-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interface.patch
Type: application/octet-stream
Size: 2896 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20080423/1a82a44c/attachment.obj