flac dev - Sep 2004 - (no subject)

First, thanks to everyone for putting in their time to make the first
truly "free" lossless audio codec.  I'm co-founder of etree.org,
the
largest online community of lossless audio traders (currently 12,000
active members).  We have been living in the shadow of Shorten for almost
three years.  Shorten, as most of you have come to realize, is extremely
limited in terms of expandability.  It does what it was designed to do,
compress and decompress audio losslessly.  Beyond that, it's rather
limited.

Designing a new lossless audio codec from the ground up is a huge task,
and my hats off to Josh for heading up this project!!!  I have no skills
as a programmer (hell, I can barely figure out HTML), but I have helped to
create the etree.org community and the basic standards among lossless
audio traders.

That said, the possibility of helping to create a new lossless audio codec
really excites me!  I think that now is the best time to break out my
"wish list" that I have compiled over the past 3 years of
dealing/struggling with SHN  ;)

Below are my thoughts on fileheader data.  I know some of these have
already been implemented, and some would be better suited for ID3-style
tagging.  Since I'm not a programmer, I will ask a lot of newbie-like
questions... such as: Is there a fundamental different between fileheader
data, and ID3 tags?  I'm assuming that ID3 tags are stored in the file
header, but I'm unsure of the specifics.

If anyone wants me to explain any of these further, or provide
justification, please let me know on or off list.


Filename

Filesize compressed

Filesize uncompressed

Compression ratio

Audio length in time

When encoding, a check to see if audio is cut on a sector boundary
(very important for people who will use this data for decompressing and
burning to CD-R). This field would be either a Y or N probably.

Date encoded

Time encoded

Encoding author (to be used by front-end GUI?)

Version of encoding codec

OS of encoding codec

Encoding GUI name (assuming there will be multiple front-ends that will
use the FLAC codec)

Flag for making the ID3 tags "read-only"

MD5 hash of compressed audio data

MD5 hash of uncompressed WAV file

Additionally, the ability to easily export MD5 hash of compressed and
uncompressed data for integrity and show tracking purposes from the file
header would help the etree.org community greatly, since we attempt to
track, via MD5 hashes, each show in circulation (
http://db.etree.org/shncirc ).  Being able to easily export a unique
"fingerprint/MD5 hash" as a .txt file, or exporting the MD5's of a
directory of FLAC files into a single .txt file would be needed.



Also, I would suggest that the name of this project be changed from "Free
Lossless Audio Coder" to "Free Lossless Audio Codec".  It's a
matter of
semantics, but important that we clear that up as early on as possible.

Thanks!



----------------------
Mike Wren
Server Team, Webmaster
http://etree.org

hmm, I'm thinking we could spec out an ETREE metadata
block that you could use.  I made some more comments
inline:

--- Mike Wren <mikew@etree.org> wrote:
> Filesize compressed
> 
this is problematic because the overall filesize
can change when metadata is added or removed.
> Filesize uncompressed
> 
FLAC only preserves the "fmt" metadata chunk of
the RIFF WAVE format so the uncompressed size of
the .flac file will be shorter than the original
if the wav had any of the uncommon chunks in it.
> Compression ratio
> 
> Audio length in time
> 
> When encoding, a check to see if audio is cut on a
> sector boundary
> (very important for people who will use this data
> for decompressing and
> burning to CD-R). This field would be either a Y or
> N probably.
> 
all these you can calculate from the ENCODING block.
> Flag for making the ID3 tags "read-only"
> 
why not just use file permissions?
> MD5 hash of compressed audio data
> 
> MD5 hash of uncompressed WAV file
> 
why do you need separate hashes?  there is currently
an MD5 signature of the unencoded audio data (i.e.
WAV file minus the metadata).  that should be enough
to fingerprint the file.
> Additionally, the ability to easily export MD5 hash
> of compressed and
> uncompressed data for integrity and show tracking
> purposes from the file
> header would help the etree.org community greatly,
> since we attempt to
> track, via MD5 hashes, each show in circulation (
> http://db.etree.org/shncirc ).  Being able to easily
> export a unique
> "fingerprint/MD5 hash" as a .txt file, or exporting
> the MD5's of a
> directory of FLAC files into a single .txt file
> would be needed.
> 
this utility would be pretty easy to write.
> Also, I would suggest that the name of this project
> be changed from "Free
> Lossless Audio Coder" to "Free Lossless Audio
> Codec".  It's a matter of
> semantics, but important that we clear that up as
> early on as possible.
> 
ok, enough people have asked for this that I went
and changed it everywhere I could.  search engines
may still have it wrong though...

Josh


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