On Wed, 2002-11-20 at 16:56, Josh Coalson wrote: > In every case I've ever seen, default FLAC compresses more > than default shorten. The anomaly here is due to the number > of channels; it appears that you really do have 300 uncorrelated > channels of data (uncorrelated according to the linear predictor > I mean). FLAC only supports 8 channels, but I would bet that > the compression would be a lot better if you separated the 300 > channels stream into several streams (<=8 channels each) and > compressed them with FLAC. That may not be practical for your > application.
Hmm, well it would be a bit of a pain :) Might be an interesting thing to try though. > > I needed the --lax otherwise it generated a > > FLAC__STREAM_ENCODER_NOT_STREAMABLE error. > > Yes, by default the encoder tries to encode according to a subset > of parameters that makes for easier decoding. You need --lax to > turn that off. Ahh, I see. > You could try splitting the signal like I mentioned. It might > take some experimenting to find channel combinations that have > some exploitable correlation. See the format page for the kinds > of inter-channel and intra-channel decorrelation FLAC does, it > might give you some more ideas: OK, the format description explains a bit more. Thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Flac-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flac-dev
