On Sep 21, 2004, at 2:44 AM, Cedric Tefft wrote:
Would you be willing to accept a few patches which expose a bit more of the library's internals to the API?
I'll consider it, but it seems you should not have to duplicate much functionality. Once you have a tag structure containing the desired V1 data, it is very easy to render and apply to a file.
True, but there's no way to read the contents of any *existing* V1 tag (not if there's a V2 tag present, anyway). All you can do is create a new one from scratch and overwrite the old one.
Actually, all you have to do is read the last 128 bytes of the file and call id3_tag_parse().
I haven't made any modifications to the library yet, but just off the top of my head I think I'd only need a few additional functions like:
id3_file_numtags(struct id3_file const *) id3_file_specifictag(struct id3_file const *, int tagnumber)
I'm afraid these are not really in the spirit of the file interface. Logically, there are at most two "tags" -- except as I have described, the file interface presents a merged view of V1 and V2 tags, reducing this number to one. The possibility of multiple V2 tags in various locations throughout the file (as sanctioned by the ID3v2.4 specification) is supported, but these have special semantics in which later tags may either augment or replace information in earlier ones. Again, the file interface is designed to hide these complications by presenting a single merged view of all the applicable tag data.
This is not to say might oppose a simpler API exposing the V1 tag as an independent entity.
possibly:
id3_file_fpopen(FILE *file_pointer, enum id3_file_mode)
The same effect can probably be achieved with id3_file_fdopen(dup(fileno(file_pointer)), mode).