[Flac-dev] Variable Bit Rate

[David Richards]

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 <
dennisb at 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 at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20110523/2c640cbc/attachment-0001.htm