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