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)
On Mon, Sep 26, 2005 at 07:50:59PM +0100, Paul Martin wrote:> 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...Nope. 2.3.0 still does it. I wonder what icecast could be doing to the stream that could cause a bump in the audio. -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home)
> > 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.Having the same serial number makes it an invalid ogg stream. Don't do that.> > 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!Wow, that sucks! This used to work perfectly, I guess someone broke it. That's a pretty nasty bug to have when we've just done a new release! I can see a 2.3.1 in the near future... Karl - any idea what might be causing this? Mike
On Mon, Sep 26, 2005 at 07:50:59PM +0100, Paul Martin wrote:> I've just taken a "savefile" from ices2. The bumps aren't happening. > It's got to be in icecast2!It's definitely something in icecast. I've had a savefile coming out of ices2 and a dumpfile for the same stream out of icecast2. Here's from ices2: Vorbis stream 3: Total data length: 957707 bytes Playback length: 2m:57.094s Average bitrate: 43.262980 kbps Logical stream 3 ended And the same from icecast2: Vorbis stream 3: Total data length: 960839 bytes Playback length: 2m:57.107s Average bitrate: 43.401440 kbps Logical stream 3 ended More from ices2 savefile: Vorbis stream 4: Total data length: 1436445 bytes Playback length: 4m:06.090s Average bitrate: 46.696544 kbps Logical stream 4 ended Vorbis stream 5: Total data length: 892599 bytes Playback length: 2m:49.479s Average bitrate: 42.133741 kbps Logical stream 5 ended and the same from icecast2 dumpfile: Vorbis stream 4: Total data length: 1440252 bytes Playback length: 4m:06.122s Average bitrate: 46.814092 kbps Logical stream 4 ended Vorbis stream 5: Total data length: 895785 bytes Playback length: 2m:49.508s Average bitrate: 42.276800 kbps Logical stream 5 ended>From somewhere, there's an extra 0.03 seconds of stream. It looks as ificecast is throwing in an extra (perhaps duplicated) frame from somewhere. (Tested with icecast2 2.2.0 and 2.3.0.) -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home)
On Tue, Sep 27, 2005 at 11:42:00AM +0200, Michael Smith wrote:> > I've just taken a "savefile" from ices2. The bumps aren't happening. > > It's got to be in icecast2! > > Wow, that sucks! This used to work perfectly, I guess someone broke > it. That's a pretty nasty bug to have when we've just done a new > release! I can see a 2.3.1 in the near future...My money's on this code in format_vorbis.c, causing a duplicate packet at stream boundaries: /* push last packet into stream marked with eos */ static void initiate_flush (vorbis_codec_t *source_vorbis) { DEBUG0 ("adding EOS packet"); if (source_vorbis->prev_packet) { /* insert prev_packet with eos */ source_vorbis->prev_packet->e_o_s = 1; add_audio_packet (source_vorbis, source_vorbis->prev_packet); source_vorbis->prev_packet->e_o_s = 0; } source_vorbis->get_buffer_page = get_buffer_finished; source_vorbis->initial_audio_packet = 1; } -- Paul Martin <pm@zetnet.net> (work) <pm@nowster.zetnet.co.uk> (home)