[ID3 Dev] 'Extending' ID3 V2.4

[Mitchell S. Honnert]

>This is largely sane, though I think you could generalize things 
>a little more.
Largely sane?  That's the nicest thing anyone's said to me all week.  ;-)
Sure, I could see there being quite a bit of discussion around what base
frames would be needed.  The goal would be to find the sweet spot between
not having so many that it overly complicates the base frame code and having
enough to handle the majority of commonly-used frames.  Maybe an application
of the 80/20 rule where the base frames handled 80% of the overall frames?

>> NumberFrame - a strongly typed frame to store numbers i.e. Track Number,
>> Year, Beats Per Minutes, Duration (MS)
>This one's arguable.  It's not particularly difficult to convert 
>between text and integers as in the current text frames.
It's not a matter of the trouble to do the conversion as much as a matter of
the *validation* during the conversion process.  For example, if we store
the Year in a NumberFrame which stores its value in a fixed number of bytes,
then I wouldn't have to check to see if the value was a valid number when
decoding the frame.  The value would, by definition of it being in a
NumberFrame, be numeric.  In practical terms, this would mean I wouldn't
have to check for cases where people have set the Year value to "Year" or
other nonsensical text values.  One could argue that some of the "numeric
text" fields could legitimately have non-numeric values -- anyone else seen
values like "19XX"? -- but I would argue that values like Track Number,
Track Count, Year, Beats Per Minutes and Duration (MS) should be restricted
to numeric values only. 

>> TextCollectionFrame - a list of text values i.e. Genres
>>
>> DictionaryFrame - a collection of text key/value pairs i.e. Involved
>> People.
>I don't see the major difference between these two,
I was thinking along the lines that the TextCollectionFrame would store a
unique collection of text values, where the DictionaryFrame would store a
collection of key/value pairs.  So, a TextCollectionFrame could store
multiple Genre values ("Rock", "Instrumental") and the DictionaryFrame could
store Involved People List values (Involvement Type, Involved Person).

>and of course the current text frames are capable of doing lists as well.
Ah, the current text frames are *capable* of storing a list of text values,
but there are competing implementations.  Genre is the example that comes to
mind.  The ID3v2.3 standard indicates that you can have multiple genres in a
single frame, but it references delimiting the values with parentheses.  But
there are implementations out there (ID3-TagIT) that ignore the standard and
use a null-char-delimited list for multiple Genres.  So, where I'm going
with this is that having a base frame dedicated to a unique list of values
would unify the implementation of the Genre frame and any other frames that
could be implemented using a unique collection of text values.


>A GEOB currently isn't limited to binary data -- it's just something with a

>mime-type.  I don't see a reason not to have text/xml as one of those.
Fair enough.  I can see that.  One thing on the side of having a specialized
picture frame, however, is that it is one of the most commonly used frames,
so there might be some benefit to having some picture-specific properties.

>In terms of getting things implemented, the closer things are to a subset
>of the current spec in my opinion the better since that would mean that
>getting momentum behind a new spec would be much easier.
Agreed.  Again, I think we're still in the "it's academic" stage here, but
it's interesting to at least toss around the idea of what it would take to
make a new standard viable.

Mitchell S. Honnert
www.UltraID3Lib.com





-----Original Message-----
From: Scott Wheeler [mailto:wheeler at kde.org] 
Sent: Saturday, February 11, 2006 4:02 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4

On Saturday 11 February 2006 20:46, Mitchell S. Honnert wrote:

This is largely sane, though I think you could generalize things a little 
more.

> So, to throw out some ideas, these "base" frames might be...
>
> TextFrame - what's now the "T" frames i.e. Artist, Title, Album

Sure.

> NumberFrame - a strongly typed frame to store numbers i.e. Track Number,
> Year, Beats Per Minutes, Duration (MS)

This one's arguable.  It's not particularly difficult to convert between
text 
and integers as in the current text frames.

> BinaryFrame - generically store pictures or any BLOB's/GEOB's

See the note in XML below.

> TextCollectionFrame - a list of text values i.e. Genres
>
> DictionaryFrame - a collection of text key/value pairs i.e. Involved
> People.

I don't see the major difference between these two, and of course the
current 
text frames are capable of doing lists as well.

> XMLFrame - basically the same as TextFrame but flagged as storing XML.

A GEOB currently isn't limited to binary data -- it's just something with a 
mime-type.  I don't see a reason not to have text/xml as one of those.

In terms of getting things implemented, the closer things are to a subset of

the current spec in my opinion the better since that would mean that getting

momentum behind a new spec would be much easier.

-Scott

-- 
There are 10 types of people in the world: Those who understand binary, and 
those who don't.

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