My comments: ;)
>hmm, I'm thinking we could
>spec out an ETREE metadata
>block that you could use.
Yes, I think this is a good idea. I'd like to incorporate this a s much as
possible as the "FLAC Standard" if it's OK with you guys, since
ideally FLAC
will be the etree.org format of choice, replacing Shorten.
>> Filesize compressed
>>
>this is problematic because
>the overall filesize can
>change when metadata is
>added or removed.
I didn't even think of this. Perhaps maybe not overall filesize, but
compressed audio stream size? Anyway, the header/ID3 data should only take
up a few KB, right? Not a lot in the grand scheme of things, but enough to
cause confusion down the line.
>> 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.
Uncommon chunks == extra fileheader data?
>> Compression ratio
The only reason why I included this in the spec is for speed. Granted, and
decent software could compute this on the fly quite easily, but my example
is this: Let's say you have a folder or drive with 1000 FLAC files, and you
wanted to get a real quick summary of overall compression ratio. It would be
much quicker to pull the data from the header than do the math. Anyway,
it's just a few extra bytes, and something I thought may provide
expandability down the road.
>> 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.
Right. Another thought I had, was the option, if the audio track is not cut
on a sector boundary, the ability for the software to "fix" this by
taking
the samples from the next track and appending it to the end of the previous
track. Etree.org created such a program, called SHNtool, to do just that.
Having this functionality built into FLAC would be a fantastic leg-up for
the etree geeks, and something to really win them over.
>> Flag for making the ID3
>tags "read-only"
>>
>why not just use file
>permissions?
I was thinking in terms of someone that encodes a track/show and uses the
correct data to fill the ID3 fields. Then, they don't want anyone else
changing this data, as it gets passed from server to server, so they would
be able to "lock" those data fields. Like everything else I brought
up,
this makes a lot of sense in the etree scheme, but probably not a lot of
sense for personal archiving of audio.
>> 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.
So, there's an MD5 hash of the the WAV minus the metadata, but what about
the compressed audio (FLAC) minus the metadata/fileheaders? I guess this is
what I'm asking about. Since, obviously the MD5 would change on the entire
FLAC file whenever ID3 tags change, for example, even though the actual
audio would be identical. I suppose there is no difference between using the
WAV or FLAC audio data.
Good deal on the other points of your email (exporting of MD5 hashes for
fingerprinting and tracking of files, and changing the "coder" to
"codec".
Again, any suggestions I offer, are to help make FLAC be the best it can,
from the (admittedly skewed perspective) of etree. ;)
Obviously, the actual codec speed and compression are the most important
aspects of this project, and I'll let coding guru's work on that. All I
can
offer is suggestions to help make FLAC more "usable".
As always, keep up the great work!
Wren