[Tremor] lowmem-no-byte decoding problem

[Monty]

On Mon, Oct 03, 2005 at 02:47:11PM +0900, akarui wrote:
> Hello everyone,
> 
> I recently have been using tremor lowmem-no-byte (I was using the 
> regular version of Tremor), but have ran into a problem with an ogg file 
> that's encoded at 22,050kHz @ ~30kb/s @ -0.1q.  With this setting, the 
> 'used_entries' variable from the codebook structure is 0 after a few 
> calls to _make_decode_table in codebook.c; a system crash occurs since 
> alloca attemps to allocate memory with an invalid value.

What platform is this?  alloca(0) is usually legal, although like
malloc, it is probably a good idea to guard it.

For now, I would expect that simply replacing alloca(foo); with
if(foo)alloca(foo); to be sufficient. 

An older encoder release wasted a single zero-size codebook stage on
very low bitrate files.  The files are valid and the wasted entry is
harmless (it increases file size by a byte or two) and you've
possibly found one of these files.

> I've spent some time trying to figure out why this is the case, but 
> since I am not yet intimately familiar with the source, I am having 
> trouble determining where 'used_entries' needs to be set to a non-zero 
> value.  This problem on both x86 and ARM platforms that I am currently 
> working on.

Codebooks may be sparse; they are not required to physically occupy
the entire codeword space they declare.  A lattice codebook might
claim to be, for example, several thousand total codewords, but only
actually represent a few hundred.  The used_entries variable
represents the actual codebook size.

> I looked through the message archives, but was not able to find any 
> threads that discuss this.  Is this a known bug/problem that has been 
> fixed?  If so, is there a place where the fix is available?  It doesn't 
> seem that the svn branch for tremor lowmem-no-byte has been updated any 
> time recently (especially with the memory leak fix).

Tremor is just a starting point and there's not really much left to be
done to the versions in SVN.  ...with the exception of the leak fixes
and probably the example fixed-heap allocator.

Monty