Curt Sampson wrote:> > > > I've thought of doing lossy compression before on instruments, > but I'd > > > > much rather stick to lossless, at least for now. > > Honestly, stick to lossless. I mean, to the point where you can get > your exact samples back. Sure, an S900 sample is not so great quality, > but having come from the era where I did the 13-bit Ensonique stuff, > you know, even then we were saying that the Jupiter-8 had a sound all > it's own. The stuff you ripped in on your Ensonique (or, God help me, > older sampler) will never sound the same played back on something > else, > but the point is, if you ever want to go back to that sound, you can > probably buy a used sampler at some point, cheaply or not, and load > this > stuff into it, but if you do a lossful compression, you're going to > lose > the character, without a doubt. This is not even about sound quality > any > more: this is about history, and the way that crappy sampler actually > recorded whatever piece of metal you happened to be banging on at the > time... > > cjs >My thoughts exactly :) I am curious though how one would get around the problems of looping with a lossy algorithm. When decoding a vorbis stream would one have the same number of samples as you encoded? The problem with looping arises if the loop points aren't the same sample values, resulting in a click. Some sort of algorithm could be run around the loop points to get them to align again, but I wouldn't know the best way to do that, yet. The purpose of FlacPak is to be able to compress existing sampler formats that contain binary and audio data. Many of these formats also contain stereo samples, but separated into individual mono samples. The encoder will have knowledge of the format it is compressing and will be able to exploit split stereo samples, etc. The encoder on the other hand will be generic. The FlacPak encoder class is almost ready. Just need to come up with a good way to MD5 sum the whole mess to ensure data integrity. Cheers. Josh Green
On Thu, 2003-11-20 at 00:01, Curt Sampson wrote:> On Wed, 19 Nov 2003, Josh Green wrote: > > > I am curious though how one would get around the problems of looping > > with a lossy algorithm. When decoding a vorbis stream would one have > > the same number of samples as you encoded? The problem with looping > > arises if the loop points aren't the same sample values, resulting in > > a click. Some sort of algorithm could be run around the loop points to > > get them to align again, but I wouldn't know the best way to do that, > > yet. > > I'd think that there is no reliable way to do that unless the lossy > algorithm is not very lossy at all, since if the waveform changes > enough, the loop points may be nowhere near where they were originally, > and the loop may not even be the same length. > > Well, there is a reliable way: re-loop by hand, which is how any > particularly difficult sound was originally looped anyway. But I doubt > that every person unpacking the file wants to do that. I suppose you > could compress, decompress, loop the decompressed sample, and then put > those loop points back into the compressed file.... > > cjsManual looping is not an option with instrument patches, since there can be several thousands of audio clips in a single instrument file. The only way I can see how to try and retain loops with lossy compression, would be if the compression algorithm had the following properties: - Same number of sample points out as put in - No time offset introduced (which would screw up the loop positions) If those 2 things could be ensured, then an algorithm could be run on the decompressed audio around the start and end loop points. This algorithm would coerce the sample amplitudes to be the same (the effect would increase as it nears the start/end point). Or perhaps the area around the loop points could be saved in a lossless manner, and the lossy compressed audio coerced around them, that might be even better. I'm sure someone has thought of this before, I wonder how Fruity Loops does it, or do they allow loops within a sample for vorbis compressed audio? For now though, I'm not going to dwell on it too much :) Cheers. Josh Green
On Wed, 19 Nov 2003, Josh Green wrote:> I am curious though how one would get around the problems of looping > with a lossy algorithm. When decoding a vorbis stream would one have > the same number of samples as you encoded? The problem with looping > arises if the loop points aren't the same sample values, resulting in > a click. Some sort of algorithm could be run around the loop points to > get them to align again, but I wouldn't know the best way to do that, > yet.I'd think that there is no reliable way to do that unless the lossy algorithm is not very lossy at all, since if the waveform changes enough, the loop points may be nowhere near where they were originally, and the loop may not even be the same length. Well, there is a reliable way: re-loop by hand, which is how any particularly difficult sound was originally looped anyway. But I doubt that every person unpacking the file wants to do that. I suppose you could compress, decompress, loop the decompressed sample, and then put those loop points back into the compressed file.... cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.NetBSD.org Don't you know, in this new Dark Age, we're all light. --XTC