[Flac-dev] Variable Bit Rate
dennisb at chronometrics.com
Mon May 23 12:09:26 PDT 2011
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?
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
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Flac-dev