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