I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to radically speed up seeks. I should point out a SEEKTABLE is optional; FLAC doesn't need it to seek but they can help. And 1% resolution within a stream only costs 1808 bytes. Josh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Well, I thought there might be cases where you wouldn't know what you wanted for seek points before encoding, so I included a special kind of seek point that is a just a place holder. Between that and PADDING blocks I think you can pretty much do anything. You're right in that no metadata affects the checksums so you can do whatever you want with metadata afterwards. Josh --- Mike Wren <mikew@etree.org> wrote:> I first thought that it would be much better to create a single seek > standard for FLAC. Then, I thought, why couldn't someone just create > the > optional SEEKTABLE data after an initial encode, if they need this > data? > Since the checksums are a part of the FLAC format (unlike Shorten), > and > these checksums are on the data stream, not the metadata, so any > additional > metadata shouldn't matter or change the internal checksums, right? > > Then, while I was thinking about how this seek data would be used: > Why not > just have the Winamp/XMMS plugin create this extra seek data > on-the-fly? > This may be too CPU intensive, however. > > > Sorry for the stream of consciousness email... I'm more thinking > (typing) > out loud than anything else... ;) > > > ---------------------- > Mike Wren > Server Team, Webmaster > http://etree.org > > > > -----Original Message----- > From: flac-dev-admin@lists.sourceforge.net > [mailto:flac-dev-admin@lists.sourceforge.net]On Behalf Of Josh > Coalson > Sent: Sunday, April 15, 2001 2:07 AM > To: flac-dev@lists.sourceforge.net > Subject: [Flac-dev] new SEEKTABLE block > > > I've checked in code that supports a new metadata block called > SEEKTABLE. Basically, it is an optional, arbitrarily-long list > of seek points, by sample number and stream offset. I also added > command-line options to flac so you can specify seek points by > specific sample number and/or a specific number of evenly-spaced > seek points. The table cost about 18 bytes per seek point. > > This seems to radically speed up seeks. I should point out a > SEEKTABLE is optional; FLAC doesn't need it to seek but they can > help. And 1% resolution within a stream only costs 1808 bytes. > > Josh__________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
I first thought that it would be much better to create a single seek standard for FLAC. Then, I thought, why couldn't someone just create the optional SEEKTABLE data after an initial encode, if they need this data? Since the checksums are a part of the FLAC format (unlike Shorten), and these checksums are on the data stream, not the metadata, so any additional metadata shouldn't matter or change the internal checksums, right? Then, while I was thinking about how this seek data would be used: Why not just have the Winamp/XMMS plugin create this extra seek data on-the-fly? This may be too CPU intensive, however. Sorry for the stream of consciousness email... I'm more thinking (typing) out loud than anything else... ;) ---------------------- Mike Wren Server Team, Webmaster http://etree.org -----Original Message----- From: flac-dev-admin@lists.sourceforge.net [mailto:flac-dev-admin@lists.sourceforge.net]On Behalf Of Josh Coalson Sent: Sunday, April 15, 2001 2:07 AM To: flac-dev@lists.sourceforge.net Subject: [Flac-dev] new SEEKTABLE block I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to radically speed up seeks. I should point out a SEEKTABLE is optional; FLAC doesn't need it to seek but they can help. And 1% resolution within a stream only costs 1808 bytes. Josh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ _______________________________________________ Flac-dev mailing list Flac-dev@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/flac-dev