Abstracting file access in TagLib

William Pitcock nenolod at atheme.org
Fri Dec 8 00:05:22 CET 2006


Well, writing a stream class would be trivial; the main issue is that 
TagLib::File is mostly non-virtual. If TagLib::File were made virtual, 
then there would be little problems. The main issue at present is that 
TagLib::File isn't as abstractable enough to support a VFS layer. I'll 
write a patch to make it work in an abstractable manner soon, I suppose.

- William

On Thu, 7 Dec 2006, Brian Nickel wrote:

> The file access in abstraction works in TagLib# because .NET has a
> generic IO.Stream class that makes it easy to accept any VFS that
> provides a stream. I know very little about C++ streaming/files, but if
> it's possible to accept use a generic stream, it would be relatively
> easy to add abstraction to TagLib, but if that's not possible, the
> entire file handling system would need to be rewritten so an abstractor
> could deal with every, seek, tell, read, write, etc action.
>
> Either way, I know there's been concern and interest about seeing this
> implemented, especially with people who want to play music off networks,
> so I think this feature should be looked at.
>
> - Brian Nickel (TagLib#)
>
> On Thu, 2006-12-07 at 03:40 -0500, William Pitcock wrote:
>
>> Hi,
>>
>> In audacious 1.3, we have a stream-based I/O system called NewVFS (it's
>> exposed through the old vfs_* APIs in BMP, but that's irrelevant). At
>> present, I see no easy way to abstract TagLib::File in a way that it can
>> be treated by TagLib as compatible with TagLib::File (gcc simply chokes
>> and says that there is an invalid attempt to use TagLib::File::File() when
>> defining a new class that is virtual of TagLib::File).
>>
>> Am I missing anything, or is this functionality simply unavailable? Is it
>> possible to do this?
>>
>> Searching around on Google, I found a port to Mono called TagLib#. I was
>> hoping that it was simply a glue/wrapper code, and that it might have
>> documentation on abstracting Taglib's I/O, but sadly, I discovered that it
>> was a full port. TagLib# lets you do it by changing the creator of
>> TagLib::FileRef or something (I didn't look very closely when I discovered
>> it was 100% C#).
>>
>> TagLib is a very good library for just getting into the file and getting
>> at the metadata, and in general, we are satisfied with TagLib's
>> performance. It would be a shame to have to find another reliable id3v[12]
>> tagging library (libid3 is broken, writing unicode frames to id3v2.3
>> structures, which is wrong as id3v2.3 is latin1 only). However, on the
>> other hand, we do want to support our stream layer as much as possible in
>> 1.3.
>>
>> Anyway, if anybody has any pointers on how to make Taglib::File do what we
>> need, I'd definately appreciate it. I've tried to subclass like I
>> mentioned earlier, but ran into a dead end.
>>
>>    -- William
>> _______________________________________________
>> taglib-devel mailing list
>> taglib-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/taglib-devel
>


More information about the taglib-devel mailing list