[Flac-dev] the road to 1.0...

[Josh Coalson]

> ...
> So, two ways that FLAC is far superior to Shorten.. incorporated
> checksums,
> and much improved error recovery.
> 
> I see etree.org users as more of archivists than music fans, since we
> place
> so much emphesis on bit-for-bit accuracy.  Using a codec that makes
> this job
> easier for us is a very welcome thing!
> 
> If you (or anyone else on this list) can keep track of selling points
> for
> FLAC over other current (and future) lossless codecs, I would like to
> compile a list, since I will be running propaganda to convert etree
> users to
> FLAC.  It won't be an easy sell though.
> 
I think making the whole process easier will be key.  Some people
just don't like to change even when the change is for the better.
As far as features go, the two you mentioned are important, plus
better compression ratios.  I will be tackling speed before 1.0
with some assembly, and I expect that flac will eventually get
the same ratios as shorten much faster, as well as better compression
for the same speed.  Right now FLAC already gets usually 5% more
compression than Shorten for about a 2.5x runtime increase (at
least with my tests).

But making it easy will be just as important.  As far as command-line
usage, flac requires less work since the MD5 and seektables are
built-in.  It doesn't restore funky WAV metadata (just the basic
fields) and it doesn't try to reproduce the original date/time
like shorten does because the unix utility 'touch' is just as
effective.

It has a Winamp2 plugin with seeking and ID3V1 tag recognition.
So what else do you guys have written on top of shorten that can
be migrated to FLAC?  And what things (like custom metadata) could
you take advantage of to make trading easier?  I know you had some
rough ideas before, but are you ready to spec out your own
APPLICATION block?

Josh


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/