[Vorbis] ov_open_callbacks takes so much time to open 210 MB OGG file

[Pavel Nikitenko]

I use libvorbis-1.3.3 with libogg 1.3.0 which I downloaded from download 
section here: http://www.xiph.org/downloads/ .
Not sure if this is "Omnipresent" release though. Also I do not know 
what "Omnipresent" means exactly?

I wish if ov_open_callbacks could open the file in 630ms. It takes 23.3 
minutes for me here.
Do not know why. It is strange if it takes just 630 ms on your PC and 
23.3 minutes on my.

Thank you very much for suggestions about my wrongly generated OGG file, 
I will try to modify audio record/encode code.
The way how I try to close OGG file is here. There is already used 
vorbis_analysis_wrote(&vd,0) as you suggested.
So I do not know what is wrong there? Please see.

void FileWriteA :: closeOggFile( void )
{
     /* end of file.  this can be done implicitly in the mainline,
     but it's easier to see here in non-clever fashion.
     Tell the library we're at end of stream so that it can handle
     the last frame and mark end of stream in the output properly */
     vorbis_analysis_wrote(&vd,0);

     /// my
     int result=ogg_stream_flush(&os,&og);
     if(result !=0)
         fwrite(og.header,1,og.header_len,fd_);
         fwrite(og.body,1,og.body_len,fd_);
     ///my

     /* clean up and exit.  vorbis_info_clear() must be called last */

     ogg_stream_clear(&os);
     vorbis_block_clear(&vb);
     vorbis_dsp_clear(&vd);
     vorbis_comment_clear(&vc);
     vorbis_info_clear(&vi);

     /* ogg_page and ogg_packet structs always point to storage in
     libvorbis.  They're never freed or manipulated directly */

     fclose(fd_);
}

Yes, the streams are intended to be quadrophonic. Although just 2 
channels of audio were physically connected during the audio recording 
into the OGG file.

Pavel

On 16.12.2012 20:26, xiphmont at xiph.org wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Pavel Nikitenko <pavnsw at gmail.com> wrote:
>> Hi Monty,
>>
>> Did you have a chance to look on the observed issue with ov_open_callbacks,
>> please?
> Yes; the file opens properly here using the last few vorbis releases
> [630ms in my test--- higher than I'd like, but meh... 52 links].  You
> are using the 1.3.3 "Omnipresent" release for both encode and decode?
> I also checked using your lightly modified vorbisfile_example.c just in case.
>
>>> It looks something is wrong. Either something with ov_open_callbacks if it
>>> is not optimized or the OGG is not generated as it should.
> There are some problems in the generated Ogg, but like I said, they
> would not cause a problem of this magnitude.  A stock build here
> successfully opens, parses and decodes the file.
>
>>> I do not
>>> understand much terminology of the OGG file format. The OGG file is
>>> generated by appending of new OGG file at the end of previously generated
>>> OGG file. If there would be better way, I would use it for sure.
> That is the correct way to put two Ogg files together.  However, the
> files that are being appended in your Ogg are unfinished fragments;
> the streams are not being flushed and closed out before beginning the
> next.  In addition, it looks like there is some unencapsulated data
> being placed between section (perhaps caused by the same bug).
>
> Eg, the normal way to do this in encoding is to call
> vorbis_analysis_wrote with a write length of zero indicating the end
> of data.  At that point, the vorbis encoder will flush internal
> pending data and a construct a final Ogg end-of-stream page.
>
> Also... are these streams intended to be encoded as quadraphonic?  Two
> of the channels in your file are completely unused.
>
> Again, all of this is likely completely unrelated to the lengthy open time.
>
> Monty