[Tremor] looking for test vectors that hit specific parts of codebook.c and res012.c for memory analysis

[xiphmont at xiph.org]

> 1.  Does anyone know when the encoder started using less memory/acting like
> the latest release from a memory usage perspective?

When tesselated codebooks were deprecated, at least deprecated in the
sense that we finally decided the memory overhead wasn't worth it.
I'm guessing rc1ish, I can check.

> 2.  Are there other known spikes in memory usage with some encoders that a
> static memory allocation system would have to worry about?

No; it's all about the codebooks.  Floor0 was somewhat more CPU
intensive compared to floor 1, but used no more memory.

> 3.  Was beta 4 commonly used to encode files?  Is it safe to ignore audio
> encoded this long ago?

I would not advice ignoring it if possible, but constraints are constraints.

> 4.  Is there somewhere where I can grab win32 binaries of all the vorbis
> encoder releases?  It's a bit of a pain needing to rebuild from source,
> especially if I need to benchmark memory usage against all encoder releases.

I don't know if these are archived anywhere as we haven't officiall
provided win32 encoders since early on when we had some longer-term
win volunteers in the core of the project.  HA might actually know.

> I'd really like to avoid needing to allocate all this extra memory for a
> very old encoder, but if there are a lot of ogg files out there then we're
> going to at least need to come up with some elegant solution.  When is the
> earliest the decoder realizes that the input file is from beta 4?  Is it
> when it captures the vendor name in _vorbis_unpack_comment()?

well, *I* have a bunch, but I don't count :-)  And yes, this was back
in 2001ish.

The decoder doesn't really know/care about specific releases.
However, if memory usage is the concern, you can watch for large
tesselated codebooks. Codebook maptype 0 == tesselation.

Monty