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.<div>
<br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="https://github.com/oneman/jack-network-port">https://github.com/oneman/jack-network-port</a></div><div><br></div><div><a href="https://github.com/oneman/jack-network-port"></a>-David</div>
<div><br></div><div>Krad Radio<br><div><div><br><div class="gmail_quote">On Mon, May 23, 2011 at 3:09 PM, Dennis Brunnenmeyer <span dir="ltr"><<a href="mailto:dennisb@chronometrics.com">dennisb@chronometrics.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff">
Brian...<br>
<br>
You've been both polite and helpful. Thanks.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Dennis...<br>
<hr width="100%" size="2"><div><div></div><div class="h5"><br>
On 5/23/2011 11:57 AM, Brian Willoughby wrote:
<blockquote type="cite">
<br>
On May 23, 2011, at 11:35, Dennis Brunnenmeyer wrote:
<br>
<blockquote type="cite">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.
<br>
</blockquote>
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).
<br>
<br>
Documents and sound files are two dimensional. You cannot change
the position or value of a character in a text file without losing
information.
<br>
<br>
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.
<br>
<br>
<br>
<blockquote type="cite">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?
<br>
<br>
That is, WAV in = WAV out, where both are CBR?
<br>
</blockquote>
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.
<br>
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
You have been told wrong. If such things happen with streamed
FLAC, then there is a flaw in the streaming software.
<br>
<br>
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.
<br>
<br>
Brian Willoughby
<br>
Sound Consulting
<br>
<br>
<br>
</blockquote>
<br>
</div></div><div class="im"><div>-- <br>
<div>
<p class="MsoNormal">Dennis Brunnenmeyer<br>
Director of Engineering<br>
<span style="font-family:"Stone Sans Bold"">CEDAR
RIDGE SYSTEMS<br>
</span>15019 Rattlesnake Road<br>
Grass Valley, CA 95945-8710<br>
Office: <a href="tel:1%20%28530%29%20477-9015" value="+15304779015" target="_blank">1 (530) 477-9015</a><br>
Mobile: <a href="tel:1%20%28530%29%20320-9025" value="+15303209025" target="_blank">1 (530) 320-9025</a><br>
<span>eMail</span>: <span>dennisb</span>
/at/ <span>chronometrics</span> /dot/ com<br>
<span style="font-size:12pt"><a href="http://www.chronometrics.com/crs/index.html" target="_blank"><span style="font-size:11pt">http://www.chronometrics.com/crs/index.html</span></a><a href="http://www.chronometrics.com/crs/index.html" target="_blank"><span style="font-family:"Times New Roman""><br>
</span></a></span></p>
</div>
</div>
</div></div>
<br>_______________________________________________<br>
Flac-dev mailing list<br>
<a href="mailto:Flac-dev@xiph.org">Flac-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br>
<br></blockquote></div><br></div></div></div>