[ID3 Dev] Genre suggestion

[Robert Manson]

>As far as new genres, I can imagine it being based on user input to a
wiki-
>style database, where new genres are proposed and discussed and
ultimately 
>decided for inclusion by users who care enough to take the time.  
>The bit-mapped category space in the metadata includes unassigned bits,

>just for this purpose.

This assumes that genres will never be merged together or separated into
two or more sub-genres.  If someone is running an application that has
not been updated to the latest changes in the mapping they would see
incorrect genre(s) if he or she got a hold of a file that had been
tagged with the new system.  Therefore, for bitmaps to work you need a
separate field that contains a version number.

Musicologists have numerous ways of categorizing music and each is
entirely subjective.  AMG, Muse, and Gracenote all have different genre
systems for example.  I would like to see a genre system that supported
different sources (similar to how UFID works) for the genre system.

Such a genre frame might look like this
<Header for 'Extended Genre Frame', ID: "XCON">
Text encoding           $xx
Genre system identifier <text string according to encoding>
Genre String            <text string(s) according to encoding>
Auxiliary Data    	<up to 64 bytes binary data>

Such a scheme would allow for bitmapping, versioning and other
mechanisms in the auxiliary data section. The auxiliary data would be in
a format identified by whoever created the particular genre system.  The
Genre system identifier would allow applications to recognize genres
systems it trusts and recognizes.  However, the genre string section
would allow applications that don't recognize a particular genre system
identifier to still display something.

-Rob
-----Original Message-----
From: Pat Furrie [mailto:pfurrie at hotmail.com] 
Sent: Monday, September 18, 2006 6:31 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] Genre suggestion


>
>>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.
>
>No, because ID3v2.3 and .4 support multiple genres. Admittedly the
>support in 2.3 is rather vague, but that hasn't stopped a lot of
>people from using it. If nothing else, space delimited genres with
>substring searches works fairly well (which, again, is how iTunes
>implements it).
>
>>Bit map the genre/category/groups information.
>
>This has been suggested before and it's a complete disaster waiting to
>happen. What happens when someone creates a whole new genre that
>doesn't easily fall into previous ones? Trying to shoehorn new genres
>into old ones is more of an issue, IMO, than having disagreements on
>what genre a song belongs to, or mispellings, or any of the other
>issues with free-form Genre fields.

I like to see a central user-driven category database which can be
shared, 
in order to spread any categorization effort.  How do you possibly
implement 
that with free-form genre fields?

You can go to a ridiculous extreme and suggest there is an infinite
number 
of genres out there, or take a more practical approach, one which finds
a 
good middle ground, between the previous limited one-byte indexed
version 
and anarchy of the free-form model.

As far as new genres, I can imagine it being based on user input to a 
wiki-style database, where new genres are proposed and discussed and 
ultimately decided for inclusion by users who care enough to take the
time.  
The bit-mapped category space in the metadata includes unassigned bits,
just 
for this purpose.

But as more genres types are added, the field for potential new ones 
diminishes, as the new ones help fill in the gaps for things which were 
previously difficult to categorize.  The more time goes on, the slower
the 
inclusion or new categories becomes.


>>Who decides?  A database, run wiki-style
>
>That's not a solution because it doesn't help embedded devices. And
>those are far too large a part of the market to simply ignore.

Not moving forward isn't a solution.  Many of the embedded devices are
flash 
upgradeable.  For the rest, they get loaded from PCs which can be 
compatible, can do a search on the database for playlists based on a
rich 
but standardized category schema -- those more limited players benefit
by 
virtue of that connection.

And a user-driven model is a good way to go.  So a song might be
classified 
in multiple genres.  That's the whole point.

This isn't "a disaster waiting to happen."

>>Some people will say that "a limited genre set is insufficient" yet
they
>>seem satisfied with the current tiny number of ID3 genres.
>
>The number is tiny only if you restrict yourself to the ID3v1 list --
>which is specifically deprecated in the ID3v2 spec.

My idea of computers are as tools to make life easier and more
enjoyable.  
Being chained to mine in order to categorize thousands of songs doesn't
fit 
either of those goals.  But being able to easily pick out specific kinds
of 
music based on multiple criteria does make life easier and more
enjoyable.

Data works for people best when it is entered just once.  After that,
you 
leverage the effort of the original data entry to help many people.

If you want free form, have it in labeling the bit-mapped categories
with 
terms that you like, in the language you use, with the spelling and
wording 
you prefer.  But the bit-map doesn't get affected in that model, unless
you 
specifically change your music's categorization.  At that point, the
better 
meta-data editing software gives you the option of sharing your new data

entry to the catetorizations to the shared master database, where it
gets 
included or weighted with other people's input in order to give others
the 
benefit of your categorization insights.

I'm a music novice.  I like to listen, and I like to pick out different 
kinds of music at different times based on my mood or what is going on.
I 
dont' know enough about it to tell for sure what "genres" it all is, but

certain other stuff, it would be great for sorting and filtering
selections. 
  Tonight I'd like to hear instrumental rock music with orchestral 
accompaniment, particularly violins, which has an upbeat mood.  I don't
want 
to build a complex playlist, I just want to select these elements from a

list of category elements, and have our living room player run them
directly 
from our server.

The server and the player already exist in our house, but not the
ability to 
pull out that kind of a selection on a whim (or even with lots of
effort).  
And I can imagine wanting just that sort of music the other day, but
didn't 
have the means to do it.

Why?  I know I'm not the only one out there who wants to choose what to
play 
from their music library easily.  I know the entrenched single-genre
model 
is silly.  I know there are no technical limitations to being able to
doing 
it.  The only thing which seems missing is the vision of people who
might be 
in a position to effect change.


>I wouldn't mind seeing a "Content Rating" field in the spec, as you
>and others have given valid uses that don't require iron-clad
>protection (which, again, is what Tim basically asked for at the start
>of the thread -- it has diverged since). And it's definitely a better
>idea than having an additional entry in Genre.

This is just another categorization, and it needs its own set of flags
in 
order to define what is "adult" about it; just calling something "adult"
is 
too coarse.


>And, as a final (offtopic) note -- if you've bought a TV 13" or larger
>since 2000, you have a V-chip enabled TV. And all broadcasters are
>required to put identifiers in their shows that the V-chip uses. It's
>still virtually unused, and most people don't even know that their TV
>has the feature.

There are a lot of features in Windows which many (most) people I know
are 
unaware, but I wouldn't want them done away with.  For those who know or

those who care to use them, they are useful.  Same with a set of music 
"adult" flags and the V-chip.

Pat



---------------------------------------------------------------------
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