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