I'm seeing some inconsistency in returned timestamps using vorbisfile. I open a file, read some data (grabbing timestamps with ov_pcm_tell), then seek back with ov_pcm_seek(vf, 0) and read it again. The seek lands back on 0, but on the second read through, there's a gap in the timestamps: they jumps up by 2112 frames. This causes my vorbisfile code to insert silence to maintain sync (as if there was a hole), and one of my test cases fails: "reading data, rewinding and reading it again must always give the same results". (This also fails if I disable hole-padding.) More specifically, ov_pcm_tell returns 0 after the seek, and 3136 after reading 1024 frames. OV_HOLE is never returned. (On the first read through, it returns 1024 after reading 1024 frames, as expected.) ogginfo says: Warning: Vorbis stream 1 does not have headers correctly framed. Terminal header page contains additional packets or has non-zero granulepos Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3) Warning: EOS not set on stream 1 The file is available at ftp://zewt.org/local/test.ogg, if anyone wants to take a look. -- Glenn Maynard
On Tue, Jun 08, 2004 at 09:55:53AM -0400, Frederic Bastien wrote:> > I'm seeing some inconsistency in returned timestamps using vorbisfile. > > You seem to use an old version 1.0 RC3. What I have heard is that this > version is buggy. Can you grab a newer version 1.0 or the last one 1.0.1?The file was encoded with 1.0RC3; I'm using 1.0.1. It's a user file, which I have no control over, but 1.0.1 seems to be handling it inconsistently. This glitch means that Oggs sync differently in our program than in others. This is extremely frustrating, since I'm always pushing users to use Ogg, with one of the selling points being that, because of timestamping, sync is much more reliable than MP3. However, I've fixed all known MP3 sync discrepencies between our MAD-based decoder and the BASS-based decoder, so now MP3 is actually more reliable than Ogg for us. Whoops. I suppose I'll have to learn how libogg and libvorbis work, so I can figure out what's really going on. Sigh. -- Glenn Maynard
On Monday 07 June 2004 14:39, Glenn Maynard wrote:> I'm seeing some inconsistency in returned timestamps using vorbisfile. > > I open a file, read some data (grabbing timestamps with ov_pcm_tell), > then seek back with ov_pcm_seek(vf, 0) and read it again. > > The seek lands back on 0, but on the second read through, there's a gap > in the timestamps: they jumps up by 2112 frames. This causes my vorbisfile > code to insert silence to maintain sync (as if there was a hole), and one > of my test cases fails: "reading data, rewinding and reading it again must > always give the same results". (This also fails if I disable > hole-padding.)Sorry for not responding to this before - I was going to, but forgot about it until your recent followup. Anyway, as ogginfo says on your file, it's invalid according to the vorbis spec. Vorbisfile attempts to be liberal in accepting it, but due to the nature of the corruption, it gets some details wrong when seeking around the file. This is very easily dealt with by simply using valid vorbis files - I don't think this will ever occur with a valid vorbis file, and if it does, that's clearly a (major) bug, and we'd look into it immediately.> More specifically, ov_pcm_tell returns 0 after the seek, and 3136 after > reading 1024 frames. OV_HOLE is never returned. (On the first read > through, it returns 1024 after reading 1024 frames, as expected.) > > ogginfo says: > Warning: Vorbis stream 1 does not have headers correctly framed. > Terminal header page contains additional packets or has non-zero granuleposSpecifically, this is the problem. The header pages (illegally) containing vorbis data confuses vorbisfile - when it seeks back to 0, it seeks to the first possible place for vorbis data to exist (according to the spec), thus missing the data in the header pages. If you manage to find a reasonable fix for this specific problem, we'd be happy to accept a patch, though.> Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3) > Warning: EOS not set on stream 1This, whilst not ideal, doesn't cause any known problems with vorbisfile. Mike