I'm well aware how compression works. But images and document files do not depend on the relative timing of the data to reproduce themselves. They are in essence only two-dimensional in space, whereas the data in a sound file is time-dependent. The question really has more to do with the decoded FLAC stream output, which I presume is a linear PCM file, e.g. WAV. If FLAC is lossless and created from an original CBR WAV file, is is true that the decoded output is also CBR when played? That is, WAV in = WAV out, where both are CBR? Thanks for any insights on this matter. I've been told that because a FLAC stream from a server to an application is VBR, that certain transients are not handled correctly, like the ringing of bells. If this were true, FLAC would not be lossless in this application. Dennis... ------------------------------------------------------------------------ On 5/23/2011 10:58 AM, Masklinn wrote:> On 2011-05-23, at 19:26 , Dennis Brunnenmeyer wrote: >> Is FLAC a variable bit rate format when streamed? If so, how can it be truly lossless? > The same way zip and PNG compression are truly lossless: something can take more space than the information it contains needs. > > For instance, take a 1024*1024 completely white bitmap. Your bitmap file is 1MB (1048576 bytes). A good PNG compressor can get it to 200 bytes (this is not a typo: I have a completely white 1024*1024 PNG file in 222 bytes). > > Well it's the same with sound (a 5mn track with no sound whatsoever contains less information than "Nun seh' ich wohl, warum so dunkle Flammen"). That's also why the format can't help but be VBR: different pieces of sound contain different amounts of information per second, and therefore have different compression ratio (and compression ratios can --- very rarely --- go above even 1: white noise is completely incompressible, when you add FLAC metadata you end up with a FLAC file bigger than the source WAV)-- Dennis Brunnenmeyer Director of Engineering CEDAR RIDGE SYSTEMS 15019 Rattlesnake Road Grass Valley, CA 95945-8710 Office: 1 (530) 477-9015 Mobile: 1 (530) 320-9025 eMail: dennisb /at/ chronometrics /dot/ com http://www.chronometrics.com/crs/index.html <http://www.chronometrics.com/crs/index.html> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20110523/26a47170/attachment-0001.htm
On Mon, May 23, 2011 at 2:35 PM, Dennis Brunnenmeyer <dennisb at chronometrics.com> wrote:> I'm well aware how compression works.If you're going to be condescending, then it only to remains to say that you're clearly not aware of how compression works.> But images and document files do not > depend on the relative timing of the data to reproduce themselves.> They are > in essence only two-dimensional in space, whereas the data in a sound file > is time-dependent.This is a complete misunderstanding.> The question really has more to do with the decoded FLAC stream output, > which I presume is a linear PCM file, e.g. WAV.? If FLAC is lossless and > created from an original CBR WAV file, is is true that the decoded output is > also CBR when played?FLAC is a lossless compression scheme. That's it. Stop wondering, and if you can't stop wondering, go read the papers on it.> Thanks for any insights on this matter. I've been told that because a FLAC > stream from a server to an application is VBR, that certain transients are > not handled correctly, like the ringing of bells. If this were true, FLAC > would not be lossless in this application.your information is wrong. FLAC does not do psycho-acoustic compression. it does not create artifacts. it is a *lossless* compression scheme.
On May 23, 2011, at 11:35, Dennis Brunnenmeyer wrote:> I'm well aware how compression works. But images and document files > do not depend on the relative timing of the data to reproduce > themselves. They are in essence only two-dimensional in space, > whereas the data in a sound file is time-dependent.Images are three-dimensional or maybe five-dimensional, mathematically, because the pixel value at each two-dimension point can have any value (monochrome) or color (three-dimensional RGB). Documents and sound files are two dimensional. You cannot change the position or value of a character in a text file without losing information. The key point here is that the timing you refer to in a sound file is not really so special. It is merely another dimension of the data. It is preserved in FLAC. Of the various methods for drawing sound files on the screen, they are all at least two-dimensional, if not more, which should be a clue that sound files are two-dimensional.> The question really has more to do with the decoded FLAC stream > output, which I presume is a linear PCM file, e.g. WAV. If FLAC is > lossless and created from an original CBR WAV file, is is true that > the decoded output is also CBR when played? > > That is, WAV in = WAV out, where both are CBR?Yes, an uncompressed sound file is CBR, unless you're talking about LDPCM. FLAC is compressed, though, and thus it must be VBR in its compressed form. The Variable in VBR ranges anywhere from slightly above the CBR of uncompressed audio (including overhead) to approximately half that rate (on average) or even sometimes lower.> Thanks for any insights on this matter. I've been told that because > a FLAC stream from a server to an application is VBR, that certain > transients are not handled correctly, like the ringing of bells. If > this were true, FLAC would not be lossless in this application.You have been told wrong. If such things happen with streamed FLAC, then there is a flaw in the streaming software. One thing to keep in mind is that a VBR format like FLAC requires latency when streaming. If the streaming software is not designed with adequate latency, then you could have artifacts when the data does not appear in time. But that is not the fault of the format, but rather that the playback is trying to get ahead of the format - which is impossible. Brian Willoughby Sound Consulting
Brian... You've been both polite and helpful. Thanks. I do understand the dimensional nature of images and sound, though I admittedly glossed over the details while trying to draw attention to time rather than spatial artifacts. What I was looking for was confirmation that a properly designed application would decode FLAC without temporal issues. I believe you've made that perfectly clear. Am I right in assuming that in order to deal with potential latency issues, an application needs a sufficiently large FIFO buffer as well as the proper decoder? Dennis... ------------------------------------------------------------------------ On 5/23/2011 11:57 AM, Brian Willoughby wrote:> > On May 23, 2011, at 11:35, Dennis Brunnenmeyer wrote: >> I'm well aware how compression works. But images and document files >> do not depend on the relative timing of the data to reproduce >> themselves. They are in essence only two-dimensional in space, >> whereas the data in a sound file is time-dependent. > Images are three-dimensional or maybe five-dimensional, > mathematically, because the pixel value at each two-dimension point > can have any value (monochrome) or color (three-dimensional RGB). > > Documents and sound files are two dimensional. You cannot change the > position or value of a character in a text file without losing > information. > > The key point here is that the timing you refer to in a sound file is > not really so special. It is merely another dimension of the data. > It is preserved in FLAC. Of the various methods for drawing sound > files on the screen, they are all at least two-dimensional, if not > more, which should be a clue that sound files are two-dimensional. > > >> The question really has more to do with the decoded FLAC stream >> output, which I presume is a linear PCM file, e.g. WAV. If FLAC is >> lossless and created from an original CBR WAV file, is is true that >> the decoded output is also CBR when played? >> >> That is, WAV in = WAV out, where both are CBR? > Yes, an uncompressed sound file is CBR, unless you're talking about > LDPCM. FLAC is compressed, though, and thus it must be VBR in its > compressed form. The Variable in VBR ranges anywhere from slightly > above the CBR of uncompressed audio (including overhead) to > approximately half that rate (on average) or even sometimes lower. > > >> Thanks for any insights on this matter. I've been told that because a >> FLAC stream from a server to an application is VBR, that certain >> transients are not handled correctly, like the ringing of bells. If >> this were true, FLAC would not be lossless in this application. > You have been told wrong. If such things happen with streamed FLAC, > then there is a flaw in the streaming software. > > One thing to keep in mind is that a VBR format like FLAC requires > latency when streaming. If the streaming software is not designed > with adequate latency, then you could have artifacts when the data > does not appear in time. But that is not the fault of the format, but > rather that the playback is trying to get ahead of the format - which > is impossible. > > Brian Willoughby > Sound Consulting > >-- Dennis Brunnenmeyer Director of Engineering CEDAR RIDGE SYSTEMS 15019 Rattlesnake Road Grass Valley, CA 95945-8710 Office: 1 (530) 477-9015 Mobile: 1 (530) 320-9025 eMail: dennisb /at/ chronometrics /dot/ com http://www.chronometrics.com/crs/index.html <http://www.chronometrics.com/crs/index.html> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20110523/43c4035d/attachment.htm