WIP patch to extend taglib interface

[Peter van Hardenberg]

Greetings,

my patch to extend TagLib's Tag:: interface is nearly complete, so I am attaching it here with a list of questions and notes in the hope of soliciting some feedback. In creating it, I have drawn on the work of Lukas Lalinsky's tag mapping table from the MediaBrainz wiki among many other sources, so I believe I have come close to implementing Best Practices across APE, OGG, ID3v1 and ID3v2. Obviously ID3v1 does not support the full interface. Methods it does not support return String::null or 0 to make TagUnion happy.

Again I would like to emphasize that I have tried to embody best practices, based on the many applications I have examined. My hope is that this work will make it easier for all applications to choose to either read or write more of the metadata fields in a consistent way. As the situation stands, there is significant research and development that a developer of a new project must do to achieve more than the most basic of tagging support from TagLib, including reading a large amount of format documentation. I hope that this will reduce that burden.

I have chosen to begin with an inclusive patch, and this has led me into certain compromises that were not necessarily ideal. While I have made what I hope are reasonable choices for all of them, I am open to changes or removals if given compelling arguments. I regret that this patch is such a monster, but it should be relatively easy to parse. The simple architecture of the library has kept the changes conveniently isolated.

And now the fun stuff, my...

Controversial Decisions:

* track/totalTracks (and disc equivalents)

All formats except ID3v1 support a string value for this track. Instead of going to a string interface, I have -- where best practices suggest it -- written a parser based on the ID3v2 genre number parser which looks up the first and second number in a string. *There may only be a second number.* In the event that the string is like "/14", I assume this means "blank of fourteen". All strings which begin with non-numeric characters get this treatment. I use this code in both APE and ID3v2.

* setTrack/setTotalTracks

For formats which use one field for both values, I cache the most recent value set for the "other" half of the value through the d-pointer, and regenerate the string each time based on that. Thus, for ID3v2 -- "tag->setTrack(7); tag->setTotalTracks(13); file->save();" will write "7/13" into the TRCK frame.

* isCompilation

I was tempted to leave this one out. This is the only boolean property implemented. If there is a field set to "true", it returns true. I have used iTunes non-spec TCMP frame in this version of the patch for ID3v2, but am considering adding another ITUNES_HACKS define for diehards who take offense. If you setIsCompilation(false) the frame is removed.

* APE capitalization

I have maintained TagLib style capitalization instead of using Lukas' CamelCase style. His PicardQT table shows a variety of capitalization styles and seemingly arbitrary choices of whether to use a space in the item name. I have gone without spaces.

* ID3v2: TIPL

Right now I am following Lukas' guide of how to map TPE<N> to artist, album artist, and conductor. I'm not entirely comfortable about this. These properties should also query the TIPL field, as producer will shortly, so that if someone sets the "composer" there, tag->compser() will find it either there or in TCOM where it belongs.

* ID3v2: rating

Wow, popularimeter is a weird one. I have no intention of putting anyone's email address into their ID3 tags, particularly given the litigious climate of the world today. Nor do I intend to increment play counts on a per-user basis. Still, I intend to store the rating in this field, with the email address "private at user". Better, spec-friendly alternatives are welcome, since this opens a whole can of worms that probably should be followed up in another thread.

* M4A

I have renamed some methods from using "num" and "disk" to "total" and "disc" for consistency with my other changes. I know the M4A patch we are running here is not in trunk, but there it is for anyone interested. I don't think I've finished this one yet.

Thanks for taking the time,

-pvh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taglib-tag-wip.patch
Type: application/octet-stream
Size: 66969 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20080506/60310eee/attachment-0001.obj