Welcome to the home of UltraID3Lib, a .NET library for reading and writing ID3 metadata in MP3 files. UltraID3Lib is a fully object-oriented implementation of the ID3 tag standards as specified at www.id3.org. UltraID3Lib supports most all of the seventy-four types of frames specified in the ID3 v2.3 standard as well as fully supports the ID3 Version 1.0 and 1.1 tags. Common ID3 fields like Artist, Title, and Album can be accessed via wrapper properties, but all frames in the ID3v2.3 tag and fields in the ID3v1 tag can be accessed directly as well. UltraID3Lib also supports reading MPEG data like Duration, Bit Rate, and Frequency.
- Mitchell S. Honnert
· UltraID3Lib.chm (Help file)
· UltraID3Lib Release Notes.htm
· UltraID3Lib License.txt
· Sample VB.NET solution source code, demonstrating reading, writing, Frames, Warnings/Errors
There are two message boards for UltraID3Lib...
People can post support questions and give feedback in the Support Message Board. Here are some good reasons to visit and/or register at the discussion board...
If you would like to be notified of new UltraID3Lib versions or other important announcements, please register and subscribe to the Announcement Message Board. You can set up your message board account to e-mail you of any new posts to this board so you can find out about any new versions right away.
Frequently Asked Questions - General
Frequently Asked Questions - Implementation
UltraID3Lib is free to use in any application. All I ask is that I'm credited in any application or site which uses UltraID3Lib. (See the license information included with the download.)
As I have time, I add new features to UltraID3Lib. Currently on top of the ToDo list is support for ID3 v2.2 and ID3 v2.4, strong naming, a QuickRead method to return a read-only ITag class, and implementing the few remaining unsupported ID3 v2.3 frames.
I wrote UltraID3Lib for use by my audio file manager application, AudioFiler, as well as for my friend Chris Armogida's net radio application, The Juke, which ran his now-defunct GidaFolk web radio station.
UltraID3Lib is about as object-oriented as you can get. Wherever possible, it takes advantage of the native features of the .NET Framework. For example, the main class, UltraID3, includes an ID3v1Tag property and an ID3v23Tag property. Each of these properties are themselves classes which store the properties specific to the version of the tag they represent. The UltraID3.ID3v1Tag.Genre property is a Byte data type because genres are stored as numeric codes in ID3v1 tags, whereas the UltraID3.ID3v23Tag.Genre property is a String data type because the ID3v2 standards allows for a free-form text description. Even the ID3v2 frames are implemented as classes, thus ensuring that each frame only has the properties required by that type of frame.
No. I realize that I wouldn't have to spend as much time to support UltraID3Lib if I just released the source code, but as the author, I reserve the right to enhance the library as I deem appropriate. While I may not be able to respond to support questions as promptly as if I were a professional software development organization, I do my best. UltraID3Lib is a labor of love for me, so I don't mind the work. It's just a matter of finding the time. If I were going to release the source code, I guess I'd go open source, but to be honest, I really don't know much about open source licenses or the related implications. I barely had time to write the library itself, much less research all of the issues with releasing software to open source. In the end, I thought that managing and supporting UltraID3Lib myself and letting people use it for free would have the same basic effect as releasing the source. That, and I'm an egomaniac who didn't want to relinquish control of his "baby". ;-)
Yes, but probably not in the way you think. Literally speaking, the ID3 standard tags can be used in any file. But in reality you will probably only find ID3 tags in MP3's. Other file formats have their own metadata formats. So, because the ID3 standard can apply to any file and UltraID3Lib doesn't do any checking of the file type, UltraID3Lib does any file type.
The short answer is that multiple, non-fatal Exceptions can occur during a Read, so there needs to be a way to convey a fatal error or a collection of non-fatal errors to the calling method. When the UltraID3Lib.Read method is called to read the ID3 tag of a file, there are two categories of error that can occur: a fatal exception where something is so screwed up with the file that no part of the tag or no significant part of the tag can be read and the non-fatal exception where there is a part of the tag that is in an unexpected/non-standard format, but can be skipped. When the fatal Exception occurs, an Exception is thrown. It is thrown because the Read has failed outright. But when a non-fatal Exception occurs, the entire Read hasn't failed. It's just that one or more of the sections or fields in a tag are corrupt. The error information about this bad frame is stored in an Exception class, but instead of being thrown, it is merely stored in a collection so that it can be retrieved after the Read by the GetExceptions method. Why make an object that isn't thrown inherit from ApplicationException? Well, in some cases these Exceptions are just added to a collection returned by the GetExceptions method, but at other times, they are thrown. For example, if during the Read of a tag with an ID3RecordingDayMonthFrame.Month value of 13, an ID3v2MonthNumFormatException would be returned during by the GetExceptions method. But if you were trying to set the ID3RecordingDayMonthFrame.Month value to 13 after a Read, ID3v2MonthNumFormatException would be thrown.
There is a very good reason for this. WinAmp has a bug which creates corrupt Comments (COMM) frames. What! WinAmp, the worlds favorite MP3 player and tag editor, has a bug? Impossible! It's strange, but true. By viewing files edited by WinAmp in the VS.NET binary editor, I have confirmed that WinAmp sets the COMM frame's Language Code to random, meaningless characters. This causes comments edit and/or created by WinAmp to not appear in iTunes and presumably other programs which bother to follow the standard. For more details on this bug, go here to see a bug report I've posted to the WinAmp forums. (I have received neither an acknowledgment nor a response from WinAmp regarding this bug report.)
While the ID3 v2.3 standard allows for multiple Comments (COMM) frames in a tag, WinAmp does not properly handle this. The bug is caused because WinAmp apparently ignores the Description field of the Comments (COMM) frame, so WinAmp displays whichever COMM frame happens to be read last. For more details on this bug, go here to see a bug report I've posted to the WinAmp forums. (I have received neither an acknowledgment nor a response from WinAmp regarding this bug report.)
WinAmp miscalculates the number of MPEG frames because it does not count the actual frames, but makes an estimate based on the size of the MPEG audio and the size of the first MPEG frame. This bug overstates the number of MPEG frames because the first MPEG frame (I've found) usually does not contain any padding bytes, whereas later frames can. For more details on this bug, go here to see a bug report I've posted to the WinAmp forums. (I have received neither an acknowledgment nor a response from WinAmp regarding this bug report.)
To put it bluntly, this problem is caused because iTunes does not adhere to the ID3 standard. When you set the Compilation field in iTunes a “TCMP” frame is added to the MP3’s tag. The problem is that there is no such frame. They made it up. It appears nowhere in either the 2.3 or 2.4 standards. I can only categorize iTunes' use of the TCMP frame as a design flaw. (It’s not a bug per se because they apparently did this on purpose.) Incidentally, the proper way to add custom data to a tag is to use the Private frame. Microsoft does this to store information like the rating number set in Windows Media Player. Their custom data doesn’t cause exceptions because the binary data is imbedded in the Private frame which is recognized, albeit not able to be decoded, by UltraID3Lib.