[Flac-dev] Variable Bit Rate

[Dennis Brunnenmeyer]

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