Archive

Archive for October, 2010

Metadata and Semantic Meaning

October 23, 2010 157 comments
Recently I’ve been diving into handling file format metadata.  A lot of common files have metadata, and it is generally expected that the metadata will be retained across format conversions where possible.  Music files have song titles, artist names, album names, track names, etc.  Digital cameras often embed date and time of picture, and cell phones can embed location.
Handling this in a generic way is both easy and hard.  The current method I’m using to identify data is to embed semantic tagging in the abstraction of a converter.  For example, LAME’s id3 title argument is tagged with <semantic type=”music” tag=”title”/>.  This provides a very simple mechanism for giving meaning to the data, as we now know that it contains the same information as other things tagged “title”.  As simple as this is in concept, there are several potential problems to mitigate.  The first is text encoding.  There is an excellent standard for encoding pretty much any form of text, unicode.  Unfortunately, people don’t yet universally utilize this standard, and in practice text encoding can be a mess.  Additionally, non-string metadata will be encountered eventually.  For now I’m sticking to string data, but all metadata handling is wrapped in a class with functions for setting and getting, so as new data types come up it should be relatively extensible.
All interfraces capable of handling metadata inherit the Semantic interface class, which means they provide simple functions to handle metadata transfer.  Once the plugin code fully implements the Semantic interface, metadata transfer will be as simple as passing a Semantic pointer from the source to the loadSemantic() function.

Recently I’ve been diving into handling file format metadata.  A lot of common files have metadata, and it is generally expected that the metadata will be retained across format conversions where possible.  Music files have song titles, artist names, album names, track names, etc.  Digital cameras often embed date and time of picture, and cell phones can embed location.

Handling this in a generic way is both easy and hard.  The current method I’m using to identify data is to embed semantic tagging in the abstraction of a converter.  For example, LAME’s id3 title argument is tagged with <semantic type=”music” tag=”title”/>.  This provides a very simple mechanism for giving meaning to the data, as we now know that it contains the same information as other things tagged “title”.  As simple as this is in concept, there are several potential problems to mitigate.  The first is text encoding.  There is an excellent standard for encoding pretty much any form of text, unicode.  Unfortunately, people don’t yet universally utilize this standard, and in practice text encoding can be a mess.  Additionally, non-string metadata will be encountered eventually.  For now I’m sticking to string data, but all metadata handling is wrapped in a class with functions for setting and getting, so as new data types come up it should be relatively extensible.

All interfraces capable of handling metadata inherit the Semantic interface class, which means they provide simple functions to handle metadata transfer.  Once the plugin code fully implements the Semantic interface, metadata transfer will be as simple as passing a Semantic pointer from the source to the loadSemantic() function.

Advertisements
Categories: Uncategorized

Progress

October 10, 2010 4 comments

Figured I’d provide an update, because we haven’t had a lot of visible progress.  Work goes on under the hood with core code, we have an abstraction framework for code execution so that running programs is platform independent and uses the C++ STL.  As a result 40 line test files can convert files, and have been used to convert vorbis and flac for my iPod.  There is a lot of code building out the converter abstraction, that will hopefully soon be complete enough to build test code with.

Categories: Uncategorized