[Flac-dev] Variable Bit Rate
Is FLAC a variable bit rate format when streamed? If so, how can it be truly lossless? -- 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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
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) ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
My question is based on temporal considerations. Given a WAV file converted to FLAC and then decoded to WAV, is it possible for artifacts to be introduced? I've been told that FLAC files, when played back into a high-quality sound system, fail to properly reproduce certain kinds of sounds, like ringing bells or the 'clang' of a triangle. If this were the case, then FLAC would not be lossless in a dynamic sense. As a proponent of FLAC for lossless music storage on a server, this question is important to convincing others that FLAC accurately reproduces the original WAV or PCM file. Dennis... On 5/23/2011 10:37 AM, Tyler Eaves wrote: FLAC is variable bitrate, but the bitrate is determined by how efficiently the data can be compressed while maintaining 100% data integrity. On Mon, May 23, 2011 at 1:26 PM, Dennis Brunnenmeyer denn...@chronometrics.com wrote: Is FLAC a variable bit rate format when streamed? If so, how can it be truly lossless? -- 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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev -- 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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On Mon, May 23, 2011 at 2:35 PM, Dennis Brunnenmeyer denn...@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. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On May 23, 2011, at 10:26, Dennis Brunnenmeyer wrote: Is FLAC a variable bit rate format when streamed? If so, how can it be truly lossless? No offense intended, but your logic is backwards. You should be asking: How can a constant bit rate format be truly lossless ... unless it is not compressed at all. Look at it this way: You can either guarantee a low bit rate, and you'll have to lose data to fit ... or you can guarantee that no data is lost, and you'll have to adjust the bit rate up to guarantee that. You can't have both the guarantee of a (low) target constant bit rate and a guarantee that nothing will be lost when you reduce bit rate below uncompressed. Masklinn actually did a great job of explaining why, I just wanted to present a different way of looking at the problem. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
Flac network streaming is tricky because of the way flac handles silence in audio, but it can be worked around with a few lines changed in libflac. I've recently developed some of the only software I know of that lets you simply stream native flac from computer to computer, up to 8 channels. Its still highly alpha and Linux/Jack only. https://github.com/oneman/jack-network-port https://github.com/oneman/jack-network-port-David Krad Radio On Mon, May 23, 2011 at 3:09 PM, Dennis Brunnenmeyer denn...@chronometrics.com wrote: 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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On May 23, 2011, at 12:09, Dennis Brunnenmeyer wrote: 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? Basically, yes. It does not need to be strictly labeled as a FIFO, but the order should certainly be preserved in whatever buffer is used. The streaming software could be as simple as decoding to a WAV file and then starting playback after a sufficient amount of data has been collected. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
--- Dennis Brunnenmeyer denn...@chronometrics.com wrote: I've been told that FLAC files, when played back into a high-quality sound system, fail to properly reproduce certain kinds of sounds, like ringing bells or the 'clang' of a triangle. --- end of quote --- maybe he's been reading threads like this: http://www.audiocircle.com/index.php?topic=92852.20 ? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
2011/5/23 Scott C. Brown 02 scott.c.brown...@alum.dartmouth.org: --- Dennis Brunnenmeyer denn...@chronometrics.com wrote: I've been told that FLAC files, when played back into a high-quality sound system, fail to properly reproduce certain kinds of sounds, like ringing bells or the 'clang' of a triangle. --- end of quote --- maybe he's been reading threads like this: http://www.audiocircle.com/index.php?topic=92852.20 i guess we need to teach people about the cmp(1) and diff(1) commands. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On Mon, May 23, 2011 at 12:09:26PM -0700, denn...@chronometrics.com wrote: Brian... You've been both polite and helpful. Thanks. I think everyone on this thread has been both polite and helpful. When you ask a very open question like how can it be truly lossless? you should expect that some people are going to assume that you know little about data compression, because you didn't say otherwise. It might have been more useful to describe your intended application, or read some of the list archives. There have been some very thorough and detailed discussions here about high-def (as in better than CD) FLAC streaming and playback CPU speed scaling in the past few months. What I was looking for was confirmation that a properly designed application would decode FLAC without temporal issues. That wasn't clear from your original post. -- -Dec. --- (no microsoft products were used to create this message) ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On Mon, 2011-05-23 at 17:25 -0400, Paul Davis wrote: 2011/5/23 Scott C. Brown 02 scott.c.brown...@alum.dartmouth.org: --- Dennis Brunnenmeyer denn...@chronometrics.com wrote: I've been told that FLAC files, when played back into a high-quality sound system, fail to properly reproduce certain kinds of sounds, like ringing bells or the 'clang' of a triangle. --- end of quote --- maybe he's been reading threads like this: http://www.audiocircle.com/index.php?topic=92852.20 i guess we need to teach people about the cmp(1) and diff(1) commands. I did once have a PII machine where the pitch of the built-in sound device audibly varied with system activity (either CPU of HDD, I didn't do a lot of testing), but I tended to think that was down to the lousyness of the sound, not the formats I was playing. I suspect in fact that the difference in volume in that forum post explains the change in perceived sound quality completely, human hearing being very sensitive to that sort of thing. As to why the volume doesn't match, I suspect that one of the playback chains is integer all the way and the other is float, with the conversion being not quite right ... Richard ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Variable Bit Rate
On May 23, 2011, at 15:05, Richard Ash wrote: I suspect in fact that the difference in volume in that forum post explains the change in perceived sound quality completely, human hearing being very sensitive to that sort of thing. As to why the volume doesn't match, I suspect that one of the playback chains is integer all the way and the other is float, with the conversion being not quite right ... You're probably right, or at least something similar is going on. I primarily use a FireWire audio interface which allows me to loop back the exact digital data that is being sent to the DAC such that I can analyze the data. This comes in very handy for confirmation that a particular piece of software is not altering the data along the way. Now that we have 16-bit, 24-bit, and lossy formats (often resulting in 32-bit samples, although the increased depth is far from increased accuracy) as well as 44.1 kHz, 48 kHz, 96 kHz, and 192 kHz, it becomes even more important to confirm that what we're evaluating out of the DAC is actually what we think. I have certainly had instances where 24-bit FLAC would not play correctly on certain pieces of software, but this sort of error was immediately evidenced by my metering system. In that case, I was not getting 24-bit samples sent to my DAC, and thus all bets are off when trying to evaluate the quality of FLAC. A proper system will result in FLAC sounding identical to AIFF or WAV. If you hear a difference, then something is wrong with your system, not with the FLAC format. Brian Willoughby Sound Consulting ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
