[ID3 Dev] New genre coding idea?

Sat Mar 4 13:40:01 PST 2006

Pat, it's obvious you put a lot of thought into this proposal, but I think
there's a "showstopper" item missing from your Disadvantages list.
Converting the existing genre frame to support a bitmap style representation
of multiple genres would break backward compatibility.  The ID3 standard has
had free-form genres for so long, it'd be next to impossible to go back to
using a fixed list, even one that allowed for modified pairs like you
described.  For example, if your proposal were adopted, how should an
ID3-compatible program handle the genre of "Venezuelan Beaver Cheese Chill
Out Groove" or even "Mitch's Favs".  You just never know what people have
put in the Genre field, so there's really no way to convert these values and
go back to a fixed set of values.  The genie is out of the bottle, so to
speak.

However, this doesn't mean that we can't clarify the genre frame
specification to promote the use of multiple genres.  The only application
that I've found that supports multiple genres is ID3-TagIT.  It uses what I
think is the simplest, best approach for multiple genres which is simply
using a null char delimited list of genre values.  In fact, I've adopted its
format in my own ID3 library, UltraID3Lib.)  This technique has the benefit
of being backward compatible with all ID3v2 versions.  (Apps should just
ignore anything after the first null char delimiter, so they wouldn't fully
support the format, but neither would this format break compatibility.)

Anyway, not that I want to be such a downer, but I think it's too late to go
to a limited set of genre values.  There are just too many weird genres out
there to ever be codified in a manageable list.

Mitchell S. Honnert

www.UltraID3Lib.com

  _____  

From: Pat Furrie [mailto:pfurrie at hotmail.com] 
Sent: Saturday, March 04, 2006 3:31 PM
To: id3v2 at id3.org
Subject: [ID3 Dev] New genre coding idea?

I've been considering how multiple genres can be assigned via ID3.

What I do understand:

1)       ID3v1 had a single byte which mapped to a fixed and limited list of
genres.

2)       ID3v2 allows for a genre frame which can have some mix of genres.

3)       Very few programs, if any, are using the multiple genre capability.

4)       Programs like iTunes seem to allow multiple genres, but in reality
users are only creating a new genre which is the composite of existing
types.  However there is no cross-referencing: I can give an MP3 the "genre"
of "rock soundtrack" but if I list everything in the "rock" or "soundtrack"
genres, it doesn't show up.  Additionally, "soundtrack, rock" is not
equivalent to "rock, soundtrack" in the iTunes world.

One way of dealing with it is to utilize free-form text with delimiters,
allowing users to enter as many of whatever genres they come up with.
However, this has a few problems:

1)       Because the length of the field is unknown, padding must be used,
and the possibility still exists of needing to re-write the rest of the file
due to exceeding the space given by any padding.

2)       Any spelling errors create additional genres when they shouldn't
exist (does "soundtrack" equal "sound track"?)

3)       What works for English doesn't work for other languages.
Localization is difficult.

The original one-byte method in ID3v1 did have the potential of being able
to be localized, since the genre name lookup table could be altered for
whatever the user's language is.  But it only allows a single genre, and it
is easy to show that most files (of any type) can be reasonably listed in
multiple categories.

Another solution is to use the same look-up table, but have multiple
delimited values listed.  

Let's bit-map the genre information.  Make the bit-mapped switches
correspond to smaller divisions of description as opposed to compounded
versions.  For example, terms like "Rock," "Classic Rock," "AlternRock,"
"Instrumental Rock," "Gothic Rock," "Folk-Rock," "Progressive Rock,"
"Psychedelic Rock," "Southern Rock," "Symphonic Rock," "Hard Rock," "Slow
Rock," and "Punk Rock" are replaced by "Rock," "Classic," "Alternate,"
"Instrumental," "Gothic," "Folk," Progressive," "Psychedelic," "Southern,"
"Symphonic," "Hard," "Slow," and "Punk."  Note that any of those terms can
be combined with any of the others to give a larger variety of unique genres
(ie, "Instrumental Punk" and "Southern Folk"), as well as with a myriad of
other terms condensed from the current list of genres, and a host of
additional modifiers and qualifiers.  This atomized approach to the
subjective art of classification allows for a far more expansive range of
control and choice while keeping spellings and terms standardized.  And
while there are fewer than 150 genres in the more-or-less standard version,
this new approach allows for, well. an awfully big number. 2 to the number
of bits used in the bit map.

After doing some digging up of genre types from the Internet, it seems 1000
bits should be sufficient.  This includes a wide range of modifying terms
and plenty of reserved space for the future.  Doing a little rounding to
come up with an even number, 150 bytes appears to be a good number to
consider for the size of the reserved space.

Bitmap Advantages:

-          Efficient.  With a small amount of file space, a very large
number of genres can be described.

-          Complete.  A user can have any combination of a large number of
genre and modifiers to describe each audio file.

-          Language independent.  The bits map to terms which can be
localized to a user's language.

-          Can be cross-referenced.  Files can easily be sorted on a single
genre attribute or any combination.

-          Changes don't ever affect a file's size.  Once the fixed-length
bit-map has been attached, regardless of what genre/modifier values have
been selected, genre changes will no longer have any impact on file size.

-          Standardized terms and spellings.  A user has a hard enough time
entering the same text each time exactly the same, let alone having
different users entering textual genre information the same.  Consistency in
spelling and terms becomes possible when the choices are mapped to a fixed
word list.

-          Room for term growth.  The full list of genre switches wouldn't
be exhausted, leaving head-room for additional bit-mappable items to be
added over time.  

Bitmap Disadvantages

-          No user-customized genres.  This is the case with the ID3v1
scheme as well.  However, the baseline list of proposed genres and modifiers
is much more vast, and the freedom for creating any combination gives
choices many orders of magnitude greater than before.  Also, by having
standardized genres, you can be sure that when you import an audio file with
this scheme into your own database, the genres will mesh - no ambiguity due
to spelling, language, or word order (that is, "soundtrack rock" will equal
"rock soundtrack".)

-          Not "human readable."  The genre and modifier data is bit-coded,
so if a user were to open such a file with a text viewer/editor, they'd have
difficulty making sense of it.  However, most users never have the need to,
know how to, or want to open audio files with a text editor.  They'll use
software designed for viewing and editing the tags.  Also, coded in hex,
this could easily exist with an XML framework, if need be.

-          Always consumes 150 bytes.  From a relative point-of-view, this
is a big increase. This is a lot more than the 1 byte for ID3v1.  However,
from an absolute viewpoint, this isn't much.  For a user with ten-thousand
MP3s, the total impact byte-wise is 1.5 megs.  Using my collection of
slightly more than ten-thousand MP3s as an example, it consumes just over
forty gigabytes of disk space.  1.5 megs of additional space amounts to a
percentage increase of less than 4 one-thousandths of one percent.

--------------

Pat

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060304/d55a98eb/attachment.html>