[ID3 Dev] Genre suggestion

[Mitchell S. Honnert]

Pat,

>Yes, I know that there is a ID3 means for multi-genre classification, but
>that's just not used.  Why?  Because it doesn't cross the threshold of 
>having enough added value in the way it is implemented.
Personally, I think the reason multi-genre support never became popular is
the ambiguity in the TCON frame's spec.  I'd love to know the actual
history, but it's my guess that early implementers of the ID3v2.3 spec
weren't really sure what to make of the description of the TCON frame
(especially the "Several references" part), so they just opted for the easy
approach, only implementing a single genre value.

In my ID3 library, I've chosen to implement multiple genre values in the
TCON frame in the same way that ID3-TagIT does it, a nullchar-delimited list
of genre names (ignoring the whole "modifier" business).  If the popular MP3
players supported this, you would have a workable implementation of a
content rating.  I could not only say that a track was "Hard Rock", I could
add that it was "Adult Language" or "Instrumental" or "Live" as well.

All things being equal, of course I'd rather have a custom "Content Rating"
frame.  It's just a shame that a multi-value TCON frame was never able to
get off the ground because this would have at least provided a workable
solution to the content rating issue.

>Computer monitors display colors in a 24 bit color space: 8 bits red, 8
>bits green, 8 bits blue.  There are an infinite number of variations that 
>exist between all of the colors that those 24 bits can represent, but we 
>defer to the standardization of the 24 bit scheme.
Well, not "infinite". A heck of a lot, but not infinite.  I say this not to
be pedantic, but to illustrate a flaw in your analogy.  The colors in a 24
bit scheme are finite.  Of course there aren't names for each of the colors,
but the colors themselves are objectively quantifiable.  Not so with genres.
There truly *are* an infinite number of genres.  Further compounding the
problem is the subjective nature of genres.  A given color has an objective
red/green/blue ratio.  But is a given track "Rock", "Rock and Roll",
"Classic Rock", "Southern Rock", "Rockabilly", "Classic Rock"? Even if you
could set up a wiki which maintained a finite list of genres, you'd still
have to assign your genres to a track.

Maintaining a list of genres would be a never-ending and thankless job.
Whether it's for genres or content rating descriptions, all I need is a
standardized container; I'll come up with the contents myself.

 - Mitchell S. Honnert




-----Original Message-----
From: Pat Furrie [mailto:pfurrie at hotmail.com] 
Sent: Saturday, September 16, 2006 12:07 AM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] Genre suggestion

On the subject of genre (from the idea of "polluting the genre field"):

The whole genre concept is way overdue for a makeover.

If you don't like the term "genre," fine.  Pick a synonym.  Classification.

Categories.  Groups.  Families.  Whatever.

Whoever had the idea of giving songs/music/media a single "genre" 
classification from the outset was fantastically short-sighted.

In terms of the current "adult" genre concept, we have a problem that, 
should we apply a new "adult" genre to the list, then that's it: a song is 
no longer rock or jazz or classical or whatever.  It is adult.

Yes, I know that there is a ID3 means for multi-genre classification, but 
that's just not used.  Why?  Because it doesn't cross the threshold of 
having enough added value in the way it is implemented.

In the spirit of "being constructive," here's my suggestion:

Bit map the genre/category/groups information.

Divide up this data field into many unique genre "descriptors" which cover 
the gamut of descriptive types, in a heirarchical (sp?) structure, and 
configured so as few or as many descriptors can be flagged for a given file.

The descriptors cover a range of major topics, from classical genre types, 
to local descriptions (New Orleans, Asian, French, etc), instrument types 
(strings, percussion, horns, etc), band type (orchestral, quartet, acapella,

etc), mood (happy, inspirational, flamboyant), and others (such as a set of 
"adult" bits).

Who decides?  A database, run wiki-style, which maintains all the 
classifications that users give input to.  The same sort of mechanism for 
mediation which exist for wiki articles also exists for genre disputes.  
Some fields for certain media are locked when there is no dispute about a 
song being in that catagory (if the song has trumpets, it has trumpets).

So what if a song ends up classified as both rock and jazz?  Some stuff will

have mutliple classications -- that's the whole point.

New classification terms can end up in the database through a submission 
process...

And I don't even suppose to know all the answers to this... but this plan 
would, better than any other current method, help categorize in a rich, 
descriptive, and easy way all the media in most people's music libraries.

If somebody has a better idea that takes care of the myriad of problems with

the current implementation, let's here them.  Here are the criteria we need 
to keep in mind:

1) Rich description
2) Ease of application for user
3) Ease of application to entire music database
4) Consistency of categorization
5) Able to grow while maintaining all of the above

Computer monitors display colors in a 24 bit color space: 8 bits red, 8 bits

green, 8 bits blue.  There are an infinite number of variations that exist 
between all of the colors that those 24 bits can represent, but we defer to 
the standardization of the 24 bit scheme.  There are sufficient combinations

of those three simple components to make up a wide assortment of colors, 
enough for most people.  There are precious few people who are after color 
perfection in a larger bit-mapped color space, and even in those differing 
schemes, the total number of colors is still finite.

What really matter is not that we have an infinite variety, but that we have

a sufficient variety.

Some people will say that "a limited genre set is insufficient" yet they 
seem satisfied with the current tiny number of ID3 genres.  Others will 
concoct examples of "genres" which are such statistical outlyers that the 
extreme example is patently absurd.

The point is to help a large majority of typical users be able to have a 
means of categorizing their ever-growing computer-based music collection 
with the least amount of effort possible.  Least amount of effort?  That's 
one of the things that computers are supposed to help us do.

Pat



>From: "Tom Sorensen" <tsorensen at gmail.com>
>Reply-To: id3v2 at id3.org
>To: id3v2 at id3.org
>Subject: Re: [ID3 Dev] Genre suggestion
>Date: Fri, 15 Sep 2006 23:09:23 -0400
>
>If that's all you want, then creating your own Genre tags is perfectly
>sufficient. Then create a playlist that excludes those tags. It's that
>simple.
>
>If you wanted to get a bit more advanced then you'd have to create a
>custom ID3v2 tag (XRTG maybe) and modify software to be aware of that
>tag when generating playlists, etc. It wouldn't buy you much more than
>what using additional genres would, except then you're not "polluting"
>the genre field.
>
>But that's not what the original poster asked for. And yes, it is
>beyond the scope of an ID3 tag (or any other similar tag), due to the
>very nature of the problem.
>
>Tom
>
>On 9/15/06, Ben Allison <benski at winamp.com> wrote:
>>Tom,
>>
>>I think you might be taking this a bit too far.  Or at least certainly
>>beyond the scope of an ID3v2 tag :)
>>
>>It could certainly be useful even if it's insecure.  What if I want to put
>>my music collection on 'shuffle' for a party, but want to easily filter
>>out anything with inappropriate lyrics.  Or I'm preparing a setlist for a
>>radio show - I couldn't play an unedited 'Money' from Pink Floyd's DSOM on
>>the air, even though the rest of the album (and the rest of the
>>discography) is OK.
>>
>>-Ben
>>
>> > The only solution is to have it as part of a DRM wrapper. Something
>> > that is, in theory, not changeable or removable. There is absolutely
>> > no other way to do it that's not easily circumventable.
>> >
>> > In theory you could do it outside of such a method, in something like
>> > an ID3 tag, but only if you force every toolset and library to
>> > recognize, support, and refuse to "downgrade" the flag. But even then
>> > anyone with a compiler and source code (or even a specification) could
>> > circumvent it; it's just a matter of how difficult it is to do.
>> >
>> > And I would like to point out that all of the similar efforts to do
>> > such automatic ratings and restrictions has either been a market
>> > failure (V-chip) or reasonably easy to disable/fool/circumvent (web
>> > surfing software). It winds up being a parental responsibility to
>> > educate and trust your children. And yes, I have two girls of my own.
>> >
>> > That said, pursuing such a system is not inherently bad. Go for it.
>> > But you'll have to get Apple and Microsoft to buy in (and hopefully
>> > come to a common standard) or else it won't succeed -- they're the two
>> > big guys on the block at this point, especially Apple with its
>> > combined hardware and software sales.
>> >
>> > And yes, multiple levels of designation are definitely a good idea.
>> >
>> > Tom
>> >
>> > On 9/15/06, Pat Furrie <pfurrie at hotmail.com> wrote:
>> >> Tom,
>> >>
>> >> Now, I don't know if Tim's suggestion is workable.  But he does bring 
>>up
>> >> a
>> >> problem he's at least giving some thought to solving, and I'm certain
>> >> other
>> >> people have had this as a problem with which to deal.  It's the sort 
>>of
>> >> thing that brought about the ratings codes in movies (quite some time
>> >> ago)
>> >> and ratings on TV (more recently).  I've got kids of my own who I want
>> >> to
>> >> have some way of helping distinguish which music is appropriate.
>> >>
>> >> You've pointed out a couple of challenges.  Perhaps you could provide
>> >> some
>> >> constructive analysis.  Devil's advocate is too easy; anyone can do
>> >> that.
>> >> But as they say, if you're not part of the solution, you're part of 
>>the
>> >> problem.  Tim isn't looking for why it won't work, he's looking for 
>>ways
>> >> to
>> >> make it work.
>> >>
>> >> Tim: I'd like to see a set of method with more granularity than just
>> >> "adult"
>> >> or not.  "Adult" is a bit slippery, and is defined differently by
>> >> different
>> >> people.  However, the existance of certain key words and concepts are
>> >> more
>> >> objective.  You might want to look at how TV has done ratings, and 
>>model
>> >> it
>> >> after that.  This way any "adult content" tag methodology could 
>>leverage
>> >> the
>> >> methods already adopted, and be more universal across media types
>> >> (meaning,
>> >> not just audio files).
>> >>
>> >> We could nay-say and do nothing, or we can get off our butts and do
>> >> something.  Even if something doesn't work, I'd rather have tried to
>> >> make it
>> >> work than not.
>> >>
>> >> Fail fast, succeed sooner.
>> >>
>> >> Pat
>> >>
>> >>
>> >> >From: "Tom Sorensen" <tsorensen at gmail.com>
>> >> >Reply-To: id3v2 at id3.org
>> >> >To: id3v2 at id3.org
>> >> >Subject: Re: [ID3 Dev] Genre suggestion
>> >> >Date: Fri, 15 Sep 2006 15:20:40 -0400
>> >> >
>> >> >If you want a new Genre, just make one. There is no list of
>> >> >pre-defined genres for ID3v2. You'd then have to modify whatever
>> >> >player to not play any music that belonged in that genre (and see
>> >> >below for the issues with that).
>> >> >
>> >> >But that's not what you really want. You want a flag that a music
>> >> >player would have to check before playing (or, since you seem
>> >> >concerned about the title, before even displaying). Certainly
>> >> >possible; there are other similar flags in the ID3v2 spec currently.
>> >> >
>> >> >I'll go ahead and object to it as pointless though. Since:
>> >> >
>> >> >A) nobody implements anything like this in current players (software
>> >> >or hardware), and it would be 3-5 years before that would change (and
>> >> >that's being optimistic; more likely it would never be implemented.
>> >> >ID3v2.4 is 5 years old now and still has very low uptake),
>> >> >
>> >> >B) it would be completely trivial to bypass and/or disable anyway
>> >> >since you cannot prevent someone from changing the tag (or removing 
>>it
>> >> >entirely).
>> >> >
>> >> >Tom Sorensen
>> >> >
>> >> >On 9/15/06, Tim Reinarts <tim_reinarts at soniqcast.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>Do you have any provisions in the latest spec for adding an "adult
>> >> >>content"
>> >> >>genre category?
>> >> >>
>> >> >>
>> >> >>
>> >> >>I would propose that such a tag would allow parents to control the
>> >> content
>> >> >>being used by their children.
>> >> >>
>> >> >>
>> >> >>
>> >> >>Media player manufacturers can then implement a feature that allows
>> >> >>parents
>> >> >>to prevent the player from accessing files with an Adult Content
>> >> genre.
>> >> >>
>> >> >>
>> >> >>
>> >> >>It concerns me that some of the most popular content on many sites
>> >> like
>> >> >>MTV's URGE are songs with explicit titles.
>> >> >>
>> >> >>
>> >> >>
>> >> >>Regards,
>> >> >>
>> >> >>Tim Reinarts
>> >> >
>> >> >---------------------------------------------------------------------
>> >> >To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> >> >For additional commands, e-mail: id3v2-help at id3.org
>> >> >
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> >> For additional commands, e-mail: id3v2-help at id3.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> > For additional commands, e-mail: id3v2-help at id3.org
>> >
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>For additional commands, e-mail: id3v2-help at id3.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org




---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org