Vorbis - Apr 2006 - Encoding / new comments

Hi,

I'm developing a software using a vorbis encoder, streaming to an
icecast server. I recently realized that the system gets a bit out of
sync at every new track. The machine isn't really fast, but it's
enough, and it can actually get the sync back quickly. However, I'm
wondering why the encoding costs me so much at every new track, it
would be better to have the system behave more smoothly.

I don't remember where we got the recipe for doing so, but at every
new track we basically completely reset the encoder. It involves a
quite costly call to vorbis_analysis_init. My question is: is it
strictly needed ? I just want to change the metadata after all.. Any
pointer to a good tutorial would be greatly appreciated too, learning
from examples is nice but you never know if the example is so good..

If you're interested in the piece of code I'm writing about, see
ocaml_vorbis_encoder_reset in
http://svn.sourceforge.net/viewcvs.cgi/savonet/trunk/ocaml-vorbis/src/vorbis_stubs.c?view=markup

Cheers
--
David

On Mon, Apr 10, 2006 at 02:48:58AM +0200, David Baelde wrote:
> I don't remember where we got the recipe for doing so, but at every
> new track we basically completely reset the encoder. It involves a
> quite costly call to vorbis_analysis_init. My question is: is it
> strictly needed ? I just want to change the metadata after all.. Any
> pointer to a good tutorial would be greatly appreciated too, learning
> from examples is nice but you never know if the example is so good..
It's not really needed if you're only changing the metadata and not the 
encoding parameters. You might try editing your vorbis_comment 
structure, and then calling vorbis_analysis_headerout() again. I've not 
checked to see if that would work, but it might. If not, you can cache 
the info and setup headers from the first time.

Then you must clear and init your ogg_stream_state with a new serialno, 
of course. Send the new header packets, and then continue by sending new 
data packets from the same encoder state.

What is going to need hacking is to get rid of the blip this will 
introduce. Vorbis packets are overlapped with the previous one, so
when the decoder overlaps the first packet of the new stream segment
with the wrong data it will create noise. To get gapless playback you'll 
have to resubmit just the right about of audio data and/or duplicate 
a packet with the granulepos fudged.

Sorry that this is just off the top of my head, but hopefully it was of 
some help. Good luck and keep us posted.

 -r