[vorbis] Interactive RC3 quality analysis graphs

[Kenneth Arnold]

On Tue, Jan 22, 2002 at 09:02:40PM -0700, Jack Moffitt wrote:
> > I'm depreciating oggchain before it even starts
> > working. 
> 
> While I can see a good use for having a tool that does the equivalent of
> 'cat' to make chained bitstreams and can undo this (win32 doesn't have
> cat, and to be fully correct you'd need to detect and redo serialno's
> since you'd want cat a.ogg a.ogg a.ogg > b.ogg to be a valid bitstream),
> your oggchain tool did almost nothing, and what it did do, ogginfo
> already did.  Please take a little more care when creating new
> directories in CVS and starting on new tools.  

It was intended to be a very alpha preview of a KISS tool to
concatenate, list chains of, and extract chains of, Ogg
files. Committing it to CVS so early was probably a mistake in light
of your comments. I stopped working on it soon after the commit
because I realized I would be duplicating a lot of code and not
gaining nearly enough benefit for it. That's why I started on what
used to be called oggtool; see below.

> First of all, an all-in-one tools goes against the Unix philosophy which
> is to make the tools do one thing and do it well.
> 
> There's certainly a lot of room for improvement in the vorbis-tools
> modules, but I think oggenc and ogg123 are shaping up quite nicely.

I'll start by saying I've had a slight, but significant, change in
plans for my work. My original plan was a monolithic binary that could
be called independantly or by symlinks or similar mechanism (so
switching off argv[0]) to do the same as the existing tools. Your
input plus some thoughts of my own showed that it would be much better
to write it as a library, either as liboggfile (the part I'm working
on now) or a more general multimedia processing library; it's flexible
enough at the moment to go either way as I flesh out the code. 

> I don't really have an issue with anyone proposing and working on better
> or more easy to use versions of these tools, but I have a hard time
> understanding what you're trying to accomplish with 'oggtool' that isn't
> already done?

I don't blame you at all for wondering -- I didn't explain my
reasoning very well. Here's another try.

Start with vcedit for example. You noted just an email or so ago that
vcedit only handles the first of any number of chained streams. I
doubt if vcut can handle chained streams as well as it should
either. Both of these will likely completely fall apart on all but
degenerate streams. On the non-denerate side, we have in ogg-tools
oggmerge, oggplay, and omplay. I can't help but notice that there's a
lot in common between everything currently available, or what they all
hope to be. Besides, we'll need a liboggfile at some point.

So I thought -- why not write something where all of those are just
simple frontends on a general core library?

I'm writing it from the simple framework of representing input and
output datastreams as encapsulations of segmented datastreams, and
doing work based on transforming a given input data format into a
given output data format. In this case, data format includes the
structure and encoding of the data as well as metadata, time regions,
and other specific data. Designed to be simple yet flexible. I'm still
decently happy with the design after a day, which is a good sign
(though it evolves as I write code and realize I need to store a few
more things, as was expected).

> In fact, I think an all-in-one tool would be harder to use, and for an
> example I'll give sox.  Sox does so much, they have to have shell
> scripts to do common things (ie, play) so that your average human can
> get work done.

I also think sox has a badly-designed command line interface. It's a
powerful tool, but an overgrown, bloated interface. But as I said, I'm
leaning away from an all-in-one tool as such.

> In any case, I don't want to discourage any work, but I would appreciate
> some more discussion.  I'd like to know about some of these things
> before the cvs list tells me :)

Noted. My plan is that as soon as I get something useful running in
whatever I decide to call my library (hopefully something useful you
can't do with an existing tool), I'll post a tarball of it somewhere
and send the list a link. Then maybe we can think about CVS.

As for oggchain, if you want to dump it from CVS, go right ahead. It's
one of those things that's going to be a 5-minute task to duplicate
once I finish my library. (get information on input, display it if
user wants, construct output data structure tree from what user wants,
go.)


-- 
Kenneth Arnold <ken at arnoldnet.net>
- "Know thyself."


-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20020123/dab500c8/part.pgp