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
