On Fri, 2 Feb 2001, Josh Coalson wrote:> this is probably a good point to remind everyone that FLAC is still > beta so don't delete your originals! everyone here has been good > about it but I'm dreading that message from someone who lost all their > stuff.You mentioned that one update was to include an md5 signature of the compressed stream to detect errors? Could you also not store the md5 signature of the original wav data? This would mean it'd be impossible for flac to extract an invalid .wav file. I know this would not help someone that had deleted their original wav, but it would at least mean problems are reported immediately without people then further processing dodgy wav files? Any possible rot would be stopped early. Also, a few more minor points. I don't know what others feel, but I think the way shorten works is intuitive. i.e. the following compresses a file: $ shorten file.wav this creates file.wav.shn and deletes file.wav. This is the way all UNIX compressors; compress, gzip, bzip & lame have worked. They simply add on their own extension without making the mistake of trying to understand and then munge the existing filename. You have the option of specifying this if you want: $ shorten file.wav file.shn and in that case the original won't be deleted. But if you don't specify the destination file then I think the .wav.shn extension is fine as it allows: $ shorten -x file.wav.shn to simply give you back the original file.wav and deletes file.wav.shn. I know flac is still beta, so the deleting might be left off by default until v1.0. Wav file format is the default, whereas you have to specifiy -fw to flac. It also preserves the modification time of the original file as do all other UNIX compressors. Unless I'm not paying attention, flac doesn't seem to do this? Cheers. Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key
> > I found a bug with FLAC v0.6 raw encoding. It > appears that the file > > pointer in the source file is not reset after > seeking to the end for > > checking the size. I've attached a patch. > > What's the impact? Do I have bad .flac files? >If you are piping raw samples in, no. The bug only occurs when you give an input file AND use -fr. In that case the encoder will stop immediately after writing only the header. The output will look something like: 0.00% complete: frame 0, wrote 42 bytes, 0 of 230389 samples, ratio = Inf unfortunately the exit code is still 0 in this case, so if you are running silent from a script you might not notice. this is probably a good point to remind everyone that FLAC is still beta so don't delete your originals! everyone here has been good about it but I'm dreading that message from someone who lost all their stuff. Josh __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
> You mentioned that one update was to include an md5 > signature of the > compressed stream to detect errors? Could you also > not store the md5 > signature of the original wav data? This would mean > it'd be impossible for > flac to extract an invalid .wav file. I know this > would not help someone > that had deleted their original wav, but it would at > least mean problems > are reported immediately without people then further > processing dodgy wav > files? Any possible rot would be stopped early. >actually the MD5 *is* on the unencoded data. I'll check back with the docs to see if they're wrong. there are many ways that data can be fed to the MD5 accumulator while encoding since the data can come in at many resolutions, big-endian/little-endian, etc., so the format I chose was channel-interleaved, little-endian, byte-aligned, so that the MD5 signature you get in the flac file should be the same as the one you get if you strip off the header of the wav file and run md5sum on it..> Also, a few more minor points. I don't know what > others feel, but I > think the way shorten works is intuitive. i.e. the > following compresses a > file: > > $ shorten file.wav > > this creates file.wav.shn and deletes file.wav. This > is the way all UNIX > compressors; compress, gzip, bzip & lame have > worked. They simply add on > their own extension without making the mistake of > trying to understand and > then munge the existing filename. > You have the option of specifying this if you > want: > > $ shorten file.wav file.shn > > and in that case the original won't be deleted. But > if you don't specify > the destination file then I think the .wav.shn > extension is fine as it > allows: > > $ shorten -x file.wav.shn > > to simply give you back the original file.wav and > deletes file.wav.shn. I > know flac is still beta, so the deleting might be > left off by default > until v1.0. > Wav file format is the default, whereas you have > to specifiy -fw to > flac. > It also preserves the modification time of the > original file as do all > other UNIX compressors. Unless I'm not paying > attention, flac doesn't seem > to do this? >yeah, this is all true. it is easy enough to add this and I probably will now. flac is slightly different that the examples you mentioned in this way: it is not really a wav file compressor, it's a converter. right now some kinds of wav metadata is not stored, so I thought I was avoiding confusion about usage. Josh __________________________________________________ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/