Abstracting file access in TagLib

[Brian Nickel]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/taglib-devel/attachments/20061207/62217c91/attachment.html