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)
> Reading the code... > > * If we're resampling, stop and restart the resampler. (Probably not a > good move if only the metadata has changed.)Neccesary - included in this is flushing out buffers from the resampler, so we need this in order to flush the encoder.> > * Shut down the encoder (and flush any pending buffers). > > * Reset the encoder. > > * Update any metadata. > > * Restart the encoder from scratch.Looks right.> > Assuming this is correct, the next question that arises is "Is Vorbis > when used this way truly gapless?"Yes, it is. Mike
On Mon, Sep 26, 2005 at 05:30:11PM +0200, Michael Smith wrote:> > Reading the code... > > > > * If we're resampling, stop and restart the resampler. (Probably not a > > good move if only the metadata has changed.) > > Neccesary - included in this is flushing out buffers from the > resampler, so we need this in order to flush the encoder.It's definitely not the resampler, as I've tested without a resampler. Now to do the vorbis fragment tests. -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home)
On Mon, Sep 26, 2005 at 05:30:11PM +0200, Michael Smith wrote:> > Assuming this is correct, the next question that arises is "Is Vorbis > > when used this way truly gapless?" > > Yes, it is.... and I can confirm this. No gaps were perceivable decoding in ogg123. However, an interesting effect can be had if all the parts have the same serial number. You get a bump just like with the ices2 metadata update. ogg123 doesn't complain, but ogginfo does. However, on the icecast2 streams, neither complains. I've just taken a "savefile" from ices2. The bumps aren't happening. It's got to be in icecast2! Now, I know that the current version of icecast has fixes that make it work with Helix (which would give up at stream boundaries). Perhaps it fixes it. Off to grab the new version and test... -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home)