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

Rob?  Anybody?

> Rob Leslie wrote:
>
>> The file API of libid3tag presents a single view of all the tags 
>> contained in a file, and does not differentiate between V1 and V2 
>> tags. The idea is that V1 and V2 tags should represent the same 
>> information about a file, and if both are present then V2 information 
>> is preferred because its field lengths are not constrained as in V1. 
>> (When writing tags back to a file, the intent is that the file 
>> interface will generate both V1 and V2 tags from the same source, 
>> ensuring consistency.)
>
>
> This is certainly a sensible strategy.  To that end, I think it would 
> be useful to allow the application to determine what the V1 equivalent 
> of the V2 information is. Sometimes it is possible to create a better 
> V1 equivalent of a V2 tag by abbreviating certain words or phrases. 
> For example, if the V2 title is something like "While the Earth Sleeps 
> (Pet Shop Boys Remix)", the truncated version is "While the Earth 
> Sleeps (Pet Sh", whereas a more informative alternative is "While the 
> Earth Sleeps (PSB)".  Obviously, it's beyond the scope of libid3tag to 
> be able to generate abbreviations for this method.  They should be 
> handled by the application.  But in order to do that, however, the 
> library would have to allow the application to override what it 
> considers to be the equivalent V1 tag, or to put it more simply, the 
> application would have to be allowed to set the V2 and V1 tags 
> independantly of each other.
>
>>
>> Accordingly, it's not possible to access the V1 and V2 information as 
>> separate tags with the file interface. If you really want to do this, 
>> you can use the tag parsing and rendering routines to maintain 
>> separate tag structures and data, but you'll have to read and write 
>> the data from the file yourself.
>>
> I'm preared to do this if necessary, however it occurs to me that what 
> I'll end up doing is rewriting, almost verbatim, functions that 
> already exist in libid3tag (new_file() and the like).  The only reason 
> I couldn't use the library functions is that they aren't exported to 
> the API.  This seems like a bit of a waste since I have to link to the 
> library anyway.
>
> Would you be willing to accept a few patches which expose a bit more 
> of the library's internals to the API?
>
> - Cedric
>
>