Re: Re: [mad-user] How to manipulate both V1 and V2 tags in the same file

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

-- 
Rob Leslie
[email protected]