This week we take a break from our current VoIP obsession and instead focus on some of our other obsessions.
Music, for example. We have a large collection of digitized music and we'd like to preserve the context of an album's context. It's irritating to listen to an album we've ripped where the tracks on the original flowed from one to the next and the player pauses between each track because they were ripped into separate files.
Of course you could rip the album to a single file but then you would not be able to easily find the start of any particular track. In short, your choices are imperfect playback or unmanageable content.
If you, like us, have theorized about a standard to fix this, theorize no longer. A group called ID3 is working on a proposal to add table of contents and chapter data to any file that uses the ID3 tag.
The ID3 tag is a data structure that is commonly used in a number of audio file formats, including MP3, AAC, WMA and Ogg Vorbis, and stores meta-information such as artist, album and release date. The entire ID3 tagging scheme is a de facto standard and can be applied to any file, although its use outside of audio is rare.
ID3 tags are prepended as the file's header and the reason they don't interfere with the original contents is any code that parses data is supposed to ignore data structures it doesn't understand.
ID3 Version 1 was limited in the amount of data it could store (all data fields were of a fixed length and totaled 128 bytes), but Version 2 tags are, in comparison, huge (as large as 256M bytes). Version 2 tags consist of a series of chunks of data called frames (in common with MP3 data structures), and each frame can be as much as 16M bytes in size.
There are no restrictions on what kind of data can be stored in ID3 Version 2 frames so anything from raw text (Unicode is supported) to images and even program code can be embedded. There is even support for synchronized lyrics and audio encryption.
Anyway, what got us excited was the proposal for table of contents and chapter frames . In this scheme chapter frames define the start and end of a chapter in the content as well as an optional title, related URLs and so on. Table of content frames can list either "child" tables of content (which allows for hierarchical structures) or chapters. There also is a field to indicate whether the listed chapters are ordered, that is, to be treated as sequential and continuous.
Obsession No. 2 is actually a question: In Outlook 2003 we had a distribution list that was imported from another copy of Outlook. The problem is internal data architecture issues mean when you move a list from one machine to another you lose the individual list entries. And when you use these corrupted entries you get the terribly useful message "An unexpected error has occurred." You have to delete the offending distribution lists and recreate them.
But if you use the same name for the new distribution list the automatic name-checking feature will find the old distribution list details from some internal cache. This list in fact points to nothing so if you accept the entry and then try to send your message you'll get that unexpected error.
To get around this you have to go to the address book to use the new version of the distribution list. After that it seems the old version of the list is purged from this mysterious cache and automatic name completion will provide the new distribution list. Of course, there's a catch. When you restart Outlook the old cache appears to be reinstated.
So, our question is how do you either purge the old cached contents used by the automatic name-completion feature or force the updated cache contents to be flushed to disk to be used by automatic name completion when Outlook next starts?