Re: Writing a glib/vfs id3 library/MP3s to test.



I guess I should explain my horrendous code.
If you look at libid3tag, you have 5 basic types; text, url,
experimental, unknown, and obsolete. My ugly code is a ton of functions
to handle the neglected frames along the lines of pictures, lyrics, CD
identifiers, relative volume adjustment (I want to see this one in
gstreamer), commercial data, TOS, et al. ID3v2 (esp. 2.4) is an amazing
spec and I think its a damn shame WMP9 is the only software that treats
it as such. (We might as well just use ID3v1.1 with the way we use it
now.)

In retrospect, and per your dissent, I'm grouping my ugly functions into
something easier to handle:
gid3tag *g_id3_tag_read( gid3tag *tag, gchar *file_name );
gid3data *g_id3_data_read( gid3tag *tag, gchar *name, gid3data *after );
gid3error *g_id3_data_write // Not sure how this will work yet.
gid3error *g_id3_tag_write( gid3tag *tag, gchar *file_name );

(g_id3_tag_read and g_id3_tag_write are specific of the library, eg.
gid3vfs or gid3file and the buffer backend will still be open for
streams/new libraries)


But now I have a programming ethics question. Is it better to have a
simple stucture or a described one: (string, string2, string3) vs
(owner, description, mimetype, language, filename, identifier, seller,
date, text) when there will only be 3 strings in a structure at a time,
but their purpose varies depending on the purpose of the structure, eg.
ownership frame vs picture frame.

Also, I currently use gid3frame as an internal structure for the actual
raw frame, but I think it is better to have gid3frame as the interpreted
data to the user (currently gid3data). This leaves me with the dilemma
of what to call the raw frames.
________________________________________________________________________
Brian Kerrick Nickel                                     kerrick cox net
Kernel                                                   2.6.0-test3-mm1
Processor                              Intel(R) Pentium(R) 4 CPU 2.00GHz
Uptime                                                 0d 13h 23m 33.77s

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]