[ID3 Dev] Genre suggestion

[Robert Manson]

http://en.wikipedia.org/wiki/Musicologist


By two genres merging I meant that one of them becomes invalid.  Without
a versioning scheme you will supply correct genre information if a "bit"
has been invalidated.

How do you ensure against invalid combinations of bits being set, for
example, Male Solo-Vocalist and Female Solo-Vocalist both being set?

What kinds of scenarios would a bitmap approach address that having
string based genres [taken from predefined sets] could not address.
For example:
Jazz, Female Vocalist, Soundtrack, Mellow

-Rob

-----Original Message-----
From: Pat Furrie [mailto:pfurrie at hotmail.com] 
Sent: Tuesday, September 19, 2006 6:13 PM
To: id3v2 at id3.org
Subject: RE: [ID3 Dev] Genre suggestion


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

Actually, I don't know that it does or doesn't assume what you suggest.
You 
certainly make an interesting point.  Let's look at this a little more 
closely:

First, the idea of two genres merging.  I suppose that could happen, so 
let's imagine a scenario where we have a piece of music that has been 
defined as to exist in both the categories of "rock" and "jazz."
Initially, 
both of these descriptors (and maybe others, too) are toggled on for the

song.  Later, as music evolves, some new combination genre comes into
being, 
let's call it "razz."  Do we eliminate the "rock" and "jazz" bits of the

song in favor of the new "razz" genre, at least for the original song?
I 
suspect not, though perhaps it meets the qualifications, and can have
that 
bit set later by the updating routine built into your iTunes version 9.

This doesn't break anything in your system, though, even if you aren't 
updated.

The next day, I give you a new piece of music I created myself, in the 
"razz" style, and I've politely pre-set all the category descriptor
flags 
that I feel best suit the it.  This includes, of course, the new "razz" 
descriptor bit, which may well be new to some of your audio programs.  
However, that bit, "sanctioned" by the community driven audio category 
database, was carved out from one of the bits in the "reserved for
future 
use" section of the bit-map space.  What does happens when the new music
is 
loaded on your computer?  It might notice it, and understanding that
this 
bit lies outside of its pre-defined category space for the version of
the 
descriptors it is aware of, triggers a routine to go fetch either a
whole 
new set of descriptors, or (better), just the changes to the descriptor 
list.  Time to fetch: less than a second.  What if you aren't online?
No 
biggie: the added descriptor doesn't break anything.  At such a time
that 
the descriptor list is updated, the bit will be more useful (having a 
human-meaningful term to associate with that particular bit).

When the new bit does finally get updated on the computer, the computer
may 
also find it is time to check for any media changes which have occured
since 
the last update.  Your computer forwards the last update date to the 
database server, and a query is run to produce a list of all music which
has 
had record updates since that time.  Your computer will compare that
list 
with its own, and make changes based on preference you've previously set

(you may have your system preferences set to only point out possible 
changes, but don't make them until you give it the go-ahead).  For
instance, 
some old rock song was used in the 2008 remake of "Citizen Kane," and
now 
that song has been updated to have the "soundtrack" bit set.  You find
this 
useful, as going back and continually updating your 30,000 file music 
collection is a pain in the butt, though when you have a movie party at
your 
house, it is nice to have an automatically generated playlist which was
set 
to pull up "soundtracks" and "rock," also include this new member of the

soundtrack club.  In fact, you might have also had that playlist search
fine 
tune the selections with some boolean operations on the mood of the
music, 
adding descriptor such as "triumphant" and "inspirational" but
forbidding 
anything that might also include "slow" or had the regional descriptor
of 
"Asian" set.

Allowing updates over time allows the descriptor richness of your
collection 
to grow, without anywhere near the amount of effort it would take to do
it 
manually.  You can adjust your own database, here and there, as you see
fit, 
but by and large, you find that most of the category choices are
reasonable, 
particularly since they allow a musical piece to cover all the genres
you 
expected, even if they might also include a few you didn't expect.

Also, so you understand, as I see it, bit mapped descriptors would work
in a 
manner so as to construct "genres" (a vague term).  For instance, while 
there would be a "rock" descriptor, there wouldn't be "hard rock" or
"pop 
rock" descriptors.  Instead, there would be "pop" and "hard"
descriptors, 
and a file can have any combination turned on in order to describe it.
As 
you add descriptors, the total number of combinations grows
exponentially 
(as opposed to linearly).  Yes, it is a finite number of combinations,
but 
the number is still very large, and by breaking down the popular genre
terms 
to their constituent parts, you cover all the current bases very well.
I'm 
certain that any current genre description systems can be included in
this 
way.  Many of them share a large number of genre types, and those that
may 
be unique can be constructed from elemental descriptors taken from
those.  
In addition, many new descriptor would be added (far more than would be 
created by inclusion of elemental genre descriptors from current
schemes).  
Allowing for descriptors in the areas of mood, region, tempo, key, 
instruments, modifiers, and misc, great richness in description can be 
achieved while using agreed-upon terms.

During a rough first draft, I identified nearly 50 moods alone.  My
first 
thought was that there would be at least 1000 bits.  That first draft
fills 
in less than 500 between all those master category headings.  But
remember: 
as each new descriptor term is added, it becomes more difficult to find
a 
descriptor which doesn't already have something in the list which would 
suitably work in its place.


>Musicologists have numerous ways of categorizing music and each is
>entirely subjective.

Is "Musicologists" really a word?  ;)


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