Vorbis dev - May 2004 - AW: AW: Reading OGG embedded in a pack file

yes, you are right. i always search for quick and easy solution and
forget in the meantime that vorbis is a low level codec library. so
probably a wrapper lib is the right way. but as far as i understand
vorbisfile is already a bunch of convenience functions? so to speak a
wrapper lib ? so why not enhance a little bit vorbisfile ?

and - i did not felt personally attacked. i just wanted to note that
some parts of c are hard to capture and note that there are novice
programmers that  may find sort of hard to use vorbislib. thats sad,
because vorbis is such great thing :))

<p>> -----Ursprüngliche Nachricht-----
> Von: owner-vorbis-dev@xiph.org
> [mailto:owner-vorbis-dev@xiph.org] Im Auftrag von Lourens Veen
> Gesendet: Donnerstag, 6. Mai 2004 12:31
> An: vorbis-dev@xiph.org
> Betreff: Re: AW: [vorbis-dev] Reading OGG embedded in a pack file
> 
> 
> On Thu 6 May 2004 10:57, Andre Krause wrote:
> > i cant agree with this. templates for example are a great
> thing i use
> > since 1993. i love them. but pointers, especially function
> pointers,
> > are a pain.
> 
> Well, personally I still don't understand the more complex template
> metaprogramming stuff in C++. I can use the STL and make a simple 
> template class, but that's about it. That doesn't mean that Boost 
> should add a non-template using interface, does it?
> 
> > and how can it be that in 2 weeks three different people (including
> > me) are flooding the mailing list with just the same 
> problem, playing
> > oggs from an archive ? couldnt it be that just another variant of
> > ov_open could have avoided this? function pointers are just not 
> > comfortable. and you are speaking like
> 
> Perhaps another variant of ov_open could have avoided this. Of
> course, next week there will be someone else with a slightly 
> different problem, and we'd have to make yet another variant. Et 
> cetera. The whole point of having these callbacks is that it is a 
> very flexible way of doing things. Ogg Vorbis is an audio codec, 
> not a package or file or stream manager, and the use of callbacks 
> gives the user of the library a lot of flexibility in and control 
> over how they want to input their streams to the library.
> 
> > someone who does not respect the novice programmers. learning and
> > really understanding c / c++ is not a matter of weeks, its 
> a matter of
> > at least months if not years. so if all libraries would need the
> > understanding of, for example,  function pointers, a beginner would 
> > never take off programming in c. take me as an
> 
> I'm not blaming anyone for not knowing or not understanding
> something, and my post was definitely not intended as a personal 
> attack on you. I'm sorry if I came across that way.
> 
> I'm not saying it's easy to learn C or C++. I wouldn't exactly
> consider myself an expert in either of them either. All I'm saying 
> is that if you don't understand something, you should learn about 
> it, not try to replace it by something you do understand even if it 
> is not as good a solution. Why limit yourself to the few tools you 
> know already? Learn a new skill, and build better products with it!
> 
> If you use Vorbis files in a package file all the time, it may well
> be useful to have a convenience function like the one you 
> suggested. It should be put in a separate library though, not in 
> the Ogg Vorbis libs. Perhaps creating such a library would be a 
> nice learning experience? Find out how these callbacks work, create 
> your wrapper library, and write a nice document about how you did 
> it and how it works. That way you learn how callbacks work, and 
> everyone else who comes here to ask in the future can learn about 
> them too.
> 
> And, thus enlightened, we shall all live happily ever after :-).
> 
> Lourens
> --
> GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to
> 'vorbis-dev-request@xiph.org' containing only the word 
> 'unsubscribe' in the body.  No subject is needed. Unsubscribe 
> messages sent to the list will be ignored/filtered.
> 
> 
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu 6 May 2004 12:49, Andre Krause wrote:
> yes, you are right. i always search for quick and easy solution
> and forget in the meantime that vorbis is a low level codec
> library. so probably a wrapper lib is the right way. but as far
> as i understand vorbisfile is already a bunch of convenience
> functions? so to speak a wrapper lib ? so why not enhance a
> little bit vorbisfile ?
You are right, it would be a good idea for vorbisfile I think (but 
ofcourse IANA xiph.org developer). I was thinking about the core 
libraries, but ofcourse ov_open is a libvorbisfile function, and I 
missed that. And if it's an addition then it shouldn't do any harm. 
I still think it would be better to improve documentation for the 
use of the callbacks though, but on the other hand, if you have to 
learn every detail then your program never gets finished. Sometimes 
the easy way out is the best way.

Anyway, I've had a look at ov_open() in vorbisfile.c, but adapting 
that to create your ov_open2() would be rather tricky. The tell and 
seek callbacks need to get passed the offsets of the start and end 
of the file, but they're plain functions, so they don't have a 
state so they can't "remember" them in between calls. Passing them
each time doesn't work, since it would require passing extra 
arguments to the callback function, and the arguments are fixed in 
the type of the function pointer.

I can think of a nice way to do it in C++ (with a functor) and in 
Haskell (partial parameterization), but I can't see a way to do it 
in C other than with a global table that maps each FILE* used to 
the matching offsets and a set of callbacks that take that into 
account; like a functor but with external state. It'll probably 
work, but it's not very nice IMHO. Any better programmers with 
better solutions out there?

Lourens

-- 
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

On Thu, May 06, 2004 at 12:49:14PM +0200, Andre Krause
wrote:
> 
> 
> yes, you are right. i always search for quick and easy solution and
> forget in the meantime that vorbis is a low level codec library. so
> probably a wrapper lib is the right way. but as far as i understand
> vorbisfile is already a bunch of convenience functions? so to speak a
> wrapper lib ? so why not enhance a little bit vorbisfile ?
An enhancement that makes one thing easier and another harder isn't
really an enhancement.  Adding more and more specific features makes
the code less useful for other specific things that were not
previously envisioned.

But really, there's no reason to build it in underneath because it can
be done so easily with callbacks.  You can do the 'archive' trick in
about 50 lines (30 of my whitespace-impaired lines ;-).  A similar
example already exists in the documentation.  Perhaps this can serve
as another near-trivial example.

Monty
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.