[Flac-dev] new SEEKTABLE block

[Mike Wren]

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 at lists.sourceforge.net
[mailto:flac-dev-admin at lists.sourceforge.net]On Behalf Of Josh Coalson
Sent: Sunday, April 15, 2001 2:07 AM
To: flac-dev at 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 at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/flac-dev