UltraID3Lib
Home
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
Downloads
|
File |
Contents |
|
· UltraID3Lib.dll · UltraID3Lib.xml · UltraID3Lib.chm (Help file) · UltraID3Lib Release Notes.htm · UltraID3Lib License.txt |
|
|
· Sample VB.NET solution source code, demonstrating reading,
writing, Frames, Warnings/Errors · UltraID3Lib.dll |
Message
Boards
There are two message boards for
UltraID3Lib...
UltraID3Lib Support Message Board
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...
UltraID3Lib Announcement Message 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.)
When
will support for feature X be added to UltraID3Lib?
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.
Why
did you write UltraID3Lib?
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.
Is
UltraID3Lib truly object-oriented (or is it crusty VB6 code masquerading as
VB.NET code)?
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.
Can
you publish the UltraID3Lib source code or release UltraID3Lib as open source?
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". ;-)
Does
UltraID3Lib support files types other than MP3?
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.
Why do I have to call the UltraID3.GetExceptions function after I
do an UltraID3.Read instead of just putting the Read in a Try/Catch block and
handling the Exceptions that are thrown?
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.
Why
am I getting an UltraID3v2InvalidLanguageCodeFrameException when I read a file
with a "Comment" field created or edited in WinAmp?
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.)
Why does UltraID3Lib say that the Comments text is one thing and WinAmp says that it's another?
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.)
Why
does the UltraID3Lib GetFrameCount function indicate
that there are less MPEG frames than WinAmp?
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.)
Why
do I get an exception when reading an MP3 where I’ve set the Compilation field
in iTunes?
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.