Icecast - Sep 2005 - ices2 metadata update causes gaps

Mike... did you look into this? I posted a waveform from a file 
generated by ogg123 dumping to a wav (so that audio driver problems were 
eliminated).

It looks to me like ices2 is restarting the vorbis encoder in a 
non-gapless way when it stops and starts the encoding (to change the 
stream id and update the metadata). Because I'm doing crossfades from 
one track to another, this shows up. If you were just playing one track 
after another, letting them play to the end before starting the next 
one, updating the metadata between tracks, you wouldn't notice it.

-- 
Paul Martin <pm@zetnet.net> (work)
  <pm@nowster.zetnet.co.uk> (home)

On 9/23/05, Paul Martin <pm@nowster.zetnet.co.uk>
wrote:
> Mike... did you look into this? I posted a waveform from a file
> generated by ogg123 dumping to a wav (so that audio driver problems were
> eliminated).
>
> It looks to me like ices2 is restarting the vorbis encoder in a
> non-gapless way when it stops and starts the encoding (to change the
> stream id and update the metadata). Because I'm doing crossfades from
> one track to another, this shows up. If you were just playing one track
> after another, letting them play to the end before starting the next
> one, updating the metadata between tracks, you wouldn't notice it.
No, I haven't really looked into this. A quick look at the code
(stream_shared.c around line 150) looks like it's doing the right
thing - it flushes all the encoded buffers before continuing on with
the new substream.

Mike

On Mon, Sep 26, 2005 at 12:41:00PM +0200, Michael Smith
wrote:
> On 9/23/05, Paul Martin <pm@nowster.zetnet.co.uk> wrote:
> > Mike... did you look into this? I posted a waveform from a file
> > generated by ogg123 dumping to a wav (so that audio driver problems
were
> > eliminated).
> >
> > It looks to me like ices2 is restarting the vorbis encoder in a
> > non-gapless way when it stops and starts the encoding (to change the
> > stream id and update the metadata). Because I'm doing crossfades
from
> > one track to another, this shows up. If you were just playing one
track
> > after another, letting them play to the end before starting the next
> > one, updating the metadata between tracks, you wouldn't notice it.
> 
> No, I haven't really looked into this. A quick look at the code
> (stream_shared.c around line 150) looks like it's doing the right
> thing - it flushes all the encoded buffers before continuing on with
> the new substream.
Reading the code...

 * If we're resampling, stop and restart the resampler. (Probably not a 
   good move if only the metadata has changed.)

 * Shut down the encoder (and flush any pending buffers).

 * Reset the encoder.

 * Update any metadata.

 * Restart the encoder from scratch.

Assuming this is correct, the next question that arises is "Is Vorbis 
when used this way truly gapless?"

This should be easy to test: get a song, split it into chunks of a large 
prime number[1] of samples, encode the chunks (with differing metadata), 
chain them together, decode to WAV using ogg123 (and maybe some others), 
and look for discontinuities.

[1] Suitable numbers: 224611 (just over 5 seconds), 441631 (just over 10 
seconds)

-- 
Paul Martin <pm@zetnet.net> (work)
  <pm@nowster.zetnet.co.uk> (home)