Vorbis dev - Aug 2001 - Problems with vorbisfile and files smaller than CHUNKSIZE

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'm writing a simple application to decompress a set of Ogg files to
raw PCM format, using vorbisfile, because that is the simplest way of
doing it. These Ogg files are sounds for a game, and thus sometimes
very short (about .25 s).

However, vorbisfile has severe problems with Ogg files that are
smaller than the CHUNKSIZE which is #defined at the top of
vorbisfile.c (8150 bytes at the moment). In that case, the ov_open()
call takes an unusually long amount of time (10-30 s on a P3-450), and
the first ov_read() call after that will _always_ return 0, indicating
EOF.

The result is that decoding with vorbisfile takes a very long time,
and even worse, output files are empty most of the time. Precisely
the same problems occur with the vorbisfile_example.c program. :(

Following that, I tested with the decoder_example.c, which does NOT
use vorbisfile, but uses the lower level primitives directly. That
program doesn't have any of the problems that vorbisfile has, and
decodes even the shortest Ogg files without problems.

I've not yet been able to resolve this problem fully, but did find
some obvious problems in vorbisfile.c relating to small files, such as
the following code fragment at the start of the _get_prev_page()
function:

tatic long _get_prev_page(OggVorbis_File *vf,ogg_page *og){
  long begin=vf->offset;
  long ret;
  int offset=-1;

  while(offset==-1){
    begin-=CHUNKSIZE;
    _seek_helper(vf,begin);
...

Initially, _get_prev_page() is called from _open_seekable2(), after
seeking to the end of the input file. So if the file is small enough,
vf->offset can end up smaller than CHUNKSIZE, and the variable
'begin'
will become negative just after the while(), causing _seek_helper() to
fail. However, its return value is never checked, so the problem isn't
noticed...

This is the cause of the ov_open() call taking a very long time to
complete; I'm amazed at how it even completes *at all*, it seems to
end up in a very tight loop. A simple fix could be the following,
although I'm not sure of its correctness:

...
  while(offset==-1){
    begin-=CHUNKSIZE;
    if(begin<0)begin=0;
    _seek_helper(vf,begin);
...

It's helping in my case, anyway. :) This will fix ov_open(), but NOT
the later decoding, which still returns 0 on the first ov_read(). I'm
still investigating that, and will keep you posted.

That is, unless somebody on the list already knows what's wrong with
vorbisfile here, and how it can be fixed. :)

Cheers,
- --
Dimitry Andric <dim@xs4all.nl>
PGP Key: http://www.xs4all.nl/~dim/dim.asc
Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i
Comment: http://www.gn.apc.org/duncan/stoa_cover.htm

iQA/AwUBO4365rBeowouIJajEQJlYQCg5cSdgpT0wyKOL/vt4hSkpRHRxuIAn0L2
q4Us75xLasirSZdT8KIcgBUO
=LONN
-----END PGP SIGNATURE-----

--- >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, Aug 30, 2001 at 11:35:40AM +0200, Dimitry Andric wrote:
> I'm writing a simple application to decompress a set of Ogg files to
> raw PCM format, using vorbisfile, because that is the simplest way of
> doing it. These Ogg files are sounds for a game, and thus sometimes
> very short (about .25 s).
It is a known bug in vorbisfile; you're correct that you're doing
nothing wrong, and I appreciate the effort put into tracing what
vorbisfile is doing and taking a stab at a fix.  This problem will be
fixed in the next rc release.

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.