Re: [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

-David

Krad Radio

On Mon, May 23, 2011 at 3:09 PM, Dennis Brunnenmeyer <
denn...@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
>  
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

Give it a go, I await your results :D

On Sat, Jan 8, 2011 at 12:20 AM, Brian Willoughby  wrote:
> Well, in that light, I suppose it isn't reasonable to expect people to wait
> 23 seconds for their internet streaming broadcast to start playing.
>
> Then again, maybe it could be sold as the "price" for lossless streaming!
>  ;-)
>
> Seriously, though, what about if the Ogg page is not part of the picture?
>  i.e., what about just using pure FLAC and IP?
>
> Brian Willoughby
> Sound Consulting
>
>
> On Jan 7, 2011, at 20:49, David Richards wrote:
>>
>> The actual non made up number for 44100 is 23 seconds. :D
>>
>> 4096 samples, 254 packets in an ogg page.
>
>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

The actual non made up number for 44100 is 23 seconds. :D

4096 samples, 254 packets in an ogg page.

-David

On Fri, Jan 7, 2011 at 11:44 PM, Ben Allison  wrote:
> The main problem is in the Ogg layer, in my opinion.
>
> Imagine this extreme use-case with __completely made up__ numbers.  This
> is a scenario where the server is encoding to FLAC on-the-fly from a raw
> PCM input, either from disk or a live stream.
>
> Let's say the FLAC block size is 1024 samples, or 23ms at 44100 Hz.
> Let's say each silent block compresses to 1 byte.  Let's also say that the
> Ogg packeting layer wants 4096 bytes before creating a page.  Again -
> these numbers are completely made up, but illustrate the point.  In this
> example, it would take 95 seconds of digital silence before Ogg decided to
> send another page out over the network.
>
> If the input audio on the server is coming from a live-source (such as
> simulcast of an FM station) or if the disk I/O is very slow, this can be
> extremely problematic.
>
> Ben Allison
> Principal Software Engineer
> Nullsoft, Inc.
>
>> I just thought of something: Given the maximum supported network
>> packet size, and the minimum number of channels (probably stereo) for
>> a FLAC broadcast stream, it should be possible to calculate the
>> absolute longest time that a single network packet could span.  Once
>> you know that time, you could simply double it, and then make sure
>> the streaming client always buffers up at least that much time before
>> playback is started.  Voila - instant protection against starvation
>> due to silent frames being compressed to ultra-tiny packets with a
>> long delay.
>>
>> Some of the comments here have talked about low latency, but I would
>> say that low latency has no place in an internet streaming
>> broadcast.  I mean, the listened have no frame of reference for
>> latency anyway, so what does it matter if the latency is really high?
>>
>> Now that I think about it this way, I'd say that FLAC and OggFLAC
>> should not have any real problems due to compression of silent
>> frames.  Any place there is a problem should be blamed on bad
>> streaming client / player code, not on the format itself.
>>
>> Brian Willoughby
>> Sound Consulting
>>
>> ___
>> Flac-dev mailing list
>> Flac-dev@xiph.org
>> http://lists.xiph.org/mailman/listinfo/flac-dev
>>
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

On Fri, Jan 7, 2011 at 11:25 PM, Brian Willoughby  wrote:
> I just thought of something: Given the maximum supported network
> packet size, and the minimum number of channels (probably stereo) for
> a FLAC broadcast stream, it should be possible to calculate the
> absolute longest time that a single network packet could span.  Once
> you know that time, you could simply double it, and then make sure
> the streaming client always buffers up at least that much time before
> playback is started.  Voila - instant protection against starvation
> due to silent frames being compressed to ultra-tiny packets with a
> long delay.
>
> Some of the comments here have talked about low latency, but I would
> say that low latency has no place in an internet streaming
> broadcast.  I mean, the listened have no frame of reference for
> latency anyway, so what does it matter if the latency is really high?

You can say that but I can also stick my fingers in ears and whistle
whilst you do. 2kb of ram is enough for anyone...

> Now that I think about it this way, I'd say that FLAC and OggFLAC
> should not have any real problems due to compression of silent
> frames.  Any place there is a problem should be blamed on bad
> streaming client / player code, not on the format itself.

Its not in the format or the client / player code. Its in libflac as I
have pointed out.

-David

>
> Brian Willoughby
> Sound Consulting
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

There is a hack fix that won't break the standard. Disable constant
subframes and fixed subframes on the encoding end. 100% compatible.
Your going to be using all that bandwidth most of the time anyways,
and when it goes down temporarily, that could actually cause a problem
at the network level depending on the fancyness of your QoS and other
routing razzle dazzle.

Here is the other hack so that you don't get a logjam in the Ogg layer.

https://github.com/oneman/libflac/commit/67e13364032404ebc1837af143fdd1cd81786c3a

-David

On Fri, Jan 7, 2011 at 9:12 PM, Brian Willoughby  wrote:
>
> On Jan 7, 2011, at 16:48, Ben Allison wrote:
>> The issue is that silent frames compress to a very small size, and
>> the Ogg
>> packeting layer can put more than one FLAC frame into a page.  So
>> if you
>> have an extended period of silence with a live or rate-limited input
>> stream, the client buffers may exhaust themselves before a new page
>> can be
>> put together and transmitted.
>
> Ah, yes, I remember reading about this.  It does seem like an
> unfortunate problem, and I would guess that both FLAC and OggFLAC
> have the same issue.  At the very least, I don't see how OggFLAC
> could compress more than FLAC when using FLAC, and thus the problem
> should be the same in both.
>
> However, if you've been following my suggestions about flagging
> silence and other gaps in the broadcast content, then I think there
> might be a common solution to both problems.  With flags for silence
> defined in the protocol, the streaming broadcast server would be able
> to alert the clients to the situation where an extended period of
> silence is about to occur.  Maybe there would even need to be some
> advance notice, otherwise the flags would come too late, just like
> the silent frames.  Seems like the streaming broadcast server could
> define some sort of maximum time gap, and if a future frame is going
> to exceed this maximum time, then a prior frame could be encoded with
> a flag announcing the imminent "problem" - upon which the client
> could simply prepare to go silent and resync.
>
> It still seems difficult, because the trailing audio right before the
> silent frames could end up getting trapped in a FLAC block that takes
> too long to arrive because it is mostly silent, but not completely
> silent.  Perhaps a "short" block is needed so that all of the non-
> silent audio can be sent right away, along with a warning flag, and
> then the client will know to produce silence (and perhaps resync)
> until the super-compressed silent frames finally arrive.
>
> Unfortunately, this all seems like a significant deviation from the
> FLAC streaming standard, unless variable block sizes can be allowed.
> I must admit that I have not studied this closely, but I do seem to
> recall that the block can is allowed to vary under certain
> conditions.  It might be the case that certain decoders only work
> with fixed block sizes, but a streaming broadcast client would
> obviously be a special case where support for small blocks could be
> mandatory without causing a huge problem.
>
> Apparently, slim has something along these lines in their stream, but
> I wonder whether they've fully taken advantage of the possibilities.
>
> Brian Willoughby
> Sound Consulting
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby  wrote:
> This thread has raised several good topics.  It's surprising that the
> FLAC-Dev list has been silent for years, and now suddenly there are several
> good ideas to discuss.

I'll take credit for this, toot toot toot :D

>
> On Jan 7, 2011, at 15:04, David Richards wrote:
>>
>> I am interested in streaming lossless audio, FLAC is probably the best
>> option for that. Currently the OggFLAC way of doing it mostly works
>> with a few hacks in libflac and my version of edcast. It might be that
>> the Ogg packaging layer is ill suited for this purpose, and an
>> alternative model developed.  I've seen that its possible to stream
>> native flac with netcat, but thats not really the solution I'm looking
>> for.
>
> I have not done much work with streaming.  I have written a lot of serious
> code that uses the FLAC library.  I remember that there used to be separate
> objects in the FLAC library for streams, and they were unique from the file
> objects because you can seek backwards in a file, but you cannot seek
> backwards in a stream.  For some reason, it seems that these objects have
> been removed in the latest versions of the FLAC library.
>
> Can anyone explain the issues with streaming pure FLAC?  What does OggFLAC
> add to make streaming possible, or even easier than pure FLAC?  I thought
> that OggFLAC was just a way to put FLAC blocks into the Ogg file format.
>  Apple's CAF specification would also allow FLAC blocks to be placed inside
> their file container, although this still would not force iTunes to play
> FLAC unless a decoder were installed in the system.
>
> What is it about netcat that you don't like?  Can you describe what you're
> looking for, and why the specific details are important?  I was always under
> the impression that the FLAC format was already designed for streaming, but
> I must admit that I've never studied the issue.
>
>
Ok dokie, basically libflac provides functions for working with
streams as well as files, but thats as far as it goes and there is a
bit more needed for a entire solution. So libflac is ready to go, but
you need more that libflac to stream, in the same way that you need
more than libflac to hear a flac being played... What I mean by this
for those reading is that libflac provides functions for encoding and
decoding from an arbitrary buffer rather than a file.

netcat isn't right for what I think are obvious reasons, namely one to
many transmission, it just doesn't scale in the correct way something
like icecast and a vorbis stream would.  I actually have never
bothered to try it, but I think you actually have to hack libflac even
for that because many programs that play flac will wait until the end
of the silent (constant) subframes before continuing to decode so any
silence gets you out of sync...

Compatibility with icecast would really be the ideal way to handle it
I think. I'm not sure how it might get in the way if your goal was
super low latency, but I think it still may work in that case. OggFLAC
currently works with icecast, thats why I started messing with it. It
somewhat hijacks the Ogg part of the vorbis code in icecast from what
I've seen.. I've been able to use it with about 1 second of latency
just fine on localhost and other machines on my network. It doesn't
support metadata updates, ie. chained ogg decoding, but I don't think
any clients do either. I think wrote the only client that doesn't
crash when listening to OggFLAC for extended periods too, lol. Mplayer
will crash randomly, and VLC will stop and rebuffer randomly..

So in summary Icecast is a http 1.0 streaming music server, and if its
oggflac getting fixed, native flac with perhaps some kind of small
wrapper or modification, I think that should be a target protocol,
everyone uses icecast.

And if for some reason icecast doesn't suit the lowest latency
situations, perhaps a small protocol could be designed to wrap native
flac and provide network streaming, with a lib, and some sample
senders/receivers.

A problem with native flac and streaming IIRC is that you only get one
metadata frame and thats at the beginning or end of the stream. I
really don't think metadata et all such as coverart and all of this
really needs to be fretted over, really all that is needed is a string
or two, maybe 255chars each, one can be the title or currently playing
information and the second one arbitrary, and something to handle this
time sync stuff we have been talking about.

Of course any of this should handle all capabilities of the flac
format, ie streaming 8 channel 24bit/96khz audio. I've been doing two
channel 24bit 44.1khz, and the bitrate is a bout 200-250K (thats big
K) per second, I haven't tried 4 or 5 channe

Re: [Flac-dev] Idea to possibly improve flac?

[David Richards]

I think it should just have an arm reach out of the computer monitor
and hit them on the head with a bat.

( A nerf bat of course )

In all honesty, its only giving the codec a bad name to people who
didn't bother to even learn about it for one second. Setting these
kind of people strait is a lifes work for many a thinking man, but it
is not my battle.


-David

On Fri, Jan 7, 2011 at 5:59 PM, Markus Ewald  wrote:
>  On 1/7/2011 11:42 PM, Jørgen Vigdal wrote:
>> Hi Brian.
>>
>> I also agree with you on these points you mention. If you guys are familiar 
>> on how the piracy groups work on the internet, you are aware that they have 
>> "releases" with their names on it. In the piracy "scene", some groups are 
>> competing on getting the first release out, and could only be beaten by 
>> another group releasing another higher quality release. Some groups (or even 
>> individuals) are releasing their stuff that is being "ripped off" another 
>> release, and they transcode the original release (mp3 320kbps for example) 
>> to a flac release (that really isn't a flac).
>>
>> Some of these groups or individuals are young people, tinking that they know 
>> everything. My idea was based on this. It would be fun stopping this, and 
>> also, as you mention in your answer, having fun and experimenting with the 
>> flac code.
>>
> ... that really sucks. Pirates giving a genuinely great codec a bad name
> because of the way their ecosystem promotes treachery. Though I wonder
> if they wouldn't self-regulate by requiring EAC .logs or something like
> that?
>
> I think an simple tool that is run on existing FLAC files and gives a
> clear good/bad answer (perhaps with a probability to remain fair) could
> spread like wildfire amongst audiophiles if publicized in the right
> channels.
>
>> Thanks,
>>
>> J.
> -Markus-
>
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?

[David Richards]

On Fri, Jan 7, 2011 at 5:58 PM, Tor-Einar Jarnbjo
 wrote:
> Am 07.01.2011 23:38, schrieb David Richards:
>>
>> I'm also interested in another concept of lossless streaming with
>> flac. Lets call it broadcast flac. A problem with streaming for long
>> periods of time is that the sending and receiving computers clocks go
>> out of sync, for example even if I stream myself on localhost, with
>
> This is not a FLAC specific problem, but has to be handled in all situations
> where the streaming server is in control of the transmitting data rate. It's
> caused by a playback device, which actual sample rate is slightly higher
> than the sample rate actually requested or a streaming source, which system
> clock is running slowly. Since these parameters (at least an exact playback
> sample rate) is hard to achieve, this is a rather common problem. Or to
> shorten it: If the data has a sample rate of 44100 and your sound card
> consumes more than 44100 samples per "sender-time" second, your buffer will
> eventually exhaust. If it's the other way around, your buffer may overflow
> if the client does not handle these cases properly.
>

I am well aware its not flac specific, but such a standard way of
handling such a matter could be part of the packaging for streaming
flac.

>> Anyway what could happen is the client could do a little bit of
>> re-sampling here or there to ensure its in sync with the servers
>> clock.
>
> That is how streaming clients usually solve this problem, although is not
> really improving sound quality.

Its probably not a big deal if you don't resample all the time, just
when your off by X amount, all of this would just be client side
preferences. As long as the client side "knows" its off by X amount
you could handle it in any number of ways, I'd be fine if its just
crossfaded to the correct timing if was off by more than half a
second, then no resampling would ever happen, you would just get a
weird effect about once an hour, better than a buffer underrun or lag,
or perhaps the client could look for a half second of silence and just
cut it out.

-David

>
> Tor
>
>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Indexed FLAC file?

[David Richards]

Probably what you want is a media player software that turns your file
structure into a database, you won't have to spend so much time
dealing with the tedium aspects of navigating the structure that
way...

However, I believe you could create such a file with MKV which can
hold multiple tracks of flac AFAIK. I'd be curious to hear back if you
try that specifically.

Probably no normal music player will deal with mkv, but if your this
into it you could develop your own..

( if you wanted to look into a custom media player for option number
one, take a look at xmms2 )

-David

On Fri, Jan 7, 2011 at 5:53 PM, George Barton  wrote:
> Hi all,
>    I have a very large music collection that I keep on a portable hard
> drive (to plug in to car USB, carry with when I'm at my office, etc).
> All but a few dozen files are part of an album, and not a single audio
> file. This translates to an insane amount of files stored on my hard
> drive. I am very strict about how I label and file my media (I loathe
> unlabeled audio tracks), but even so it is very tedious at times to
> navigate this file structure, and takes a long time to load in my car. I
> have seen other file formats (specifically one proprietary audio book
> format) that supported indexing, and think it would be a great feature
> to add to FLAC. Example...
>
> Instead of having:
>     \Dark Side of the Moon
>         01 - Speak to Me.FLAC
>         02 - Breathe.FLAC
>         03 - On the Run.FLAC
>         ...
>
> Like a CD, you would have:
>     Dark Side of the Moon.FLAC
>         -01 - Speak to Me
>         -02 - Breathe
>         -03 - On the Run
>         ...
>
> It seems to me that a .cue (or something similar) file could be appended
> to the FLAC file, and the ID tags modified and merged to reflect the
> indexes. Any newer program/hardware could take full advantage of the
> indexes, and any older program/hardware would simply see the FLAC file.
>
> I can see one major disadvantage. It would be more difficult to place a
> full playlist in shuffle mode without the program/hardware creating a
> master index detailing the contents of each file. However, many
> computer-based media players already do this.
>
> I'm not very (any) good (at all) at coding, or I would have a go at
> creating this.
>
> Just a thought...
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Idea to possibly improve flac?

[David Richards]

t;  Overall, the average performance is identical.  Apple hired some of the
> most amazing geniuses of physics to design ALAC, and if they can't beat the
> performance of FLAC in all situations, then what makes you think there is
> any reason to make a single change to the FLAC sources?
>
> While I'm writing, I also want to respond to the question about how to
> change FLAC so that all of the third party tools pick up the change.  Well,
> I don't think that is possible.  Many tools run the command-line flac
> utility behind the scenes.  Others use the FLAC library directly.  The
> problem is that both of them often run with out of date versions of the FLAC
> code, so no matter which way they incorporate the official FLAC sources, you
> cannot make them update to your anti-MP3 version.
>
> On that last note, I want to encourage you to experiment and have fun trying
> to create an MP3 detector that could warn users about quality issues.
>  However, I believe it is extremely unlikely that you would ever be
> successful in getting your code into the official FLAC sources.  This kind
> of change has nothing to do with the official FLAC format, and thus I doubt
> there would be any professional interest in changing things just for the
> sake of change or "newness."
>
> Brian Willoughby
> Sound Consultinf
>
>
> On Jan 7, 2011, at 12:56, David Richards wrote:
>>
>> Its really sad to hear thats happening but even more sad is the fact
>> that flac is becoming a very common format for music on the interweb
>> whilst at the same time the development has ceased. I've found some
>> severe issues with OggFLAC that essentially make it a useless format
>> for streaming, no one cared.
>>
>> On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal  wrote:
>>>
>>> Due to the fact that more and more users increasingly use MP3 < 320kbps
>>> as
>>> their source for encoding music, and publish it as flac files, I suggest
>>> that something is done in the flac encoder to possible avoid this.
>>> My idea is kinda easy/stupid, but might work;
>>> Implement a function that use a FFT to check if the input has frequencies
>>> >
>>> 16kHz, and informs the user that the file would not be encoded unless a
>>> -force parameter is specified (or at least ask the user if he or she want
>>> to
>>> do this :) )
>>> Hopefully, this will reduce the number of files released on the internet,
>>> re-encoded from a lossy file format. Unfortunately, many users avoid
>>> using
>>> flac, because they think the encoder is lossy due to the poor sound on
>>> some
>>> files released.
>>
>>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Idea to possibly improve flac?

[David Richards]

I'd like to express a few things whilst I have the ear atleast a few folks.

There once was a program called oddcast, and then edcast that you
could use on linux to broadcast an OggFLAC encoded audio stream from
jack. Sounds like something many folks would be interested in doing,
but I haven't heard to much of a peep about it. At any rate, it had a
a few issues legally and technical problems broadcasting an OggFLAC
stream ( again related to periods of silence in the stream). So edcast
is officialy dead now.

But now it is an undead zombie! I talked to the original developer (
Ed ), then removed the legally questionable parts (and windows
support), and fixed some issues with vorbis and oggflac encoding, and
I even added support for 24bit flac. I'm probably the only guy in the
universe listening to streaming 24bit audio, but if anyone wants to
join me the code is located here:
https://github.com/oneman/edcast2_jack

Cheers,

-D


On Fri, Jan 7, 2011 at 4:19 PM, David Richards  wrote:
> I might be able to look into this soon, I actually got my mother a
> squeezebox boom for xmas, but I have no experience with the device,
> other than initial set up and hearing it go. My choice of the word
> "useless" was deliberate to get folks rawled up, and it worked! :D It
> doesn't make it entirely useless, just unreliable and inconsistent. If
> they are using the code from the main flac branch unmodified then I'm
> sure the device is hitting these bugs. There is different bugs in the
> encoding and decoding side of things, and also in the ogg packaging
> layer. All of this is related to periods of silence in the stream of
> sound.
>
> -D
>
> On Fri, Jan 7, 2011 at 4:01 PM, Paul Davis  wrote:
>> On Fri, Jan 7, 2011 at 3:56 PM, David Richards  wrote:
>>> Its really sad to hear thats happening but even more sad is the fact
>>> that flac is becoming a very common format for music on the interweb
>>> whilst at the same time the development has ceased. I've found some
>>> severe issues with OggFLAC that essentially make it a useless format
>>> for streaming, no one cared.
>>
>> could have fooled slimdevices/logitech, which sends FLAC to all their boxes.
>>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Idea to possibly improve flac?

[David Richards]

I might be able to look into this soon, I actually got my mother a
squeezebox boom for xmas, but I have no experience with the device,
other than initial set up and hearing it go. My choice of the word
"useless" was deliberate to get folks rawled up, and it worked! :D It
doesn't make it entirely useless, just unreliable and inconsistent. If
they are using the code from the main flac branch unmodified then I'm
sure the device is hitting these bugs. There is different bugs in the
encoding and decoding side of things, and also in the ogg packaging
layer. All of this is related to periods of silence in the stream of
sound.

-D

On Fri, Jan 7, 2011 at 4:01 PM, Paul Davis  wrote:
> On Fri, Jan 7, 2011 at 3:56 PM, David Richards  wrote:
>> Its really sad to hear thats happening but even more sad is the fact
>> that flac is becoming a very common format for music on the interweb
>> whilst at the same time the development has ceased. I've found some
>> severe issues with OggFLAC that essentially make it a useless format
>> for streaming, no one cared.
>
> could have fooled slimdevices/logitech, which sends FLAC to all their boxes.
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

Re: [Flac-dev] Idea to possibly improve flac?

[David Richards]

Its really sad to hear thats happening but even more sad is the fact
that flac is becoming a very common format for music on the interweb
whilst at the same time the development has ceased. I've found some
severe issues with OggFLAC that essentially make it a useless format
for streaming, no one cared.

-David
Listener of many flacs



On Fri, Jan 7, 2011 at 3:42 PM, Jørgen Vigdal  wrote:
> Hi folks!
> Due to the fact that more and more users increasingly use MP3 < 320kbps as
> their source for encoding music, and publish it as flac files, I suggest
> that something is done in the flac encoder to possible avoid this.
> My idea is kinda easy/stupid, but might work;
> Implement a function that use a FFT to check if the input has frequencies >
> 16kHz, and informs the user that the file would not be encoded unless a
> -force parameter is specified (or at least ask the user if he or she want to
> do this :) )
> Hopefully, this will reduce the number of files released on the internet,
> re-encoded from a lossy file format. Unfortunately, many users avoid using
> flac, because they think the encoder is lossy due to the poor sound on some
> files released.
> Thanks in advance.
> Sincerely,
> Jørgen Vigdal
> jor...@anion.no
> Phone: +47 91320132
> jorgenvigdal.com
> ___
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
>
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] oggflac streaming apocalypse II

[David Richards]

one might notice in ogg_decoder_aspect.c a function called
FLAC__ogg_decoder_aspect_read_callback_wrapper that wants alot of
bytes, 8192 of em, yet, back over in encoder land, your typical
constant subframe is only 613 bytes!

this means we must of course stop the decoding for a second and fall
behind while we build up silent time.

it would be nice if this made any sense.

-David
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev

[Flac-dev] OggFLAC streaming is systemically broken.

[David Richards]

Not that many people are streaming FLAC, and if they are, they are, in
my mind, undoubtedly experiencing problems. Probably the most prized
kind of software problem of all, the intermittent kind.

I am streaming FLAC. 24bit no less, and its fantastic. The future I
would like to live in, is one where lossless music is streamed and
heard by people other than myself.

It is generally not possible to stream flac correctly with the current
libflac 1.2.1, unless your into epic kludges. There is at-least one
issue in libflac, and issues in decoding clients such as VLC, mplayer
and totem.

The good news is that one can hackfix libflac on the server side and
produce a valid stream that VLC and mplayer can take in without issue.
Totem seems to have other issues I have not investigated.

There seems to be two problems conspiring together. Both have to do
with silence. Even though what we really want to do is listen to music
or someone yapping, silence manages to be very important, be it a few
second in a song or long periods of dead air. Problem number one that
when libflac is pumping out silent subframes, the ogg pages are never
getting flushed out, because they are so small. So until there is some
noise or the page is full, the client decoder is left hanging. Then
when it starts decoding again, its decoding silence, and thus falls
far behind in the stream, probably confusing itself and disconnecting.
Problem number two, is even if you flush these little guys.. the
clients still get confused, especially if there is more than one per
page.

The epic kludge solution is to just never let there be any perfect
silence, not even for a few ms, plug in an old am radio and crank it
to just barely audible and add that to the stream.

The hackfix, is to disable constant subframes, and flush any packet
less than say 700 bytes, otherwise use pageout as normal.

The sustainable solution would probably be to add an option to libflac
to force flush the stream after X number of samples, and then fix all
of the clients. Then live the dream of streaming lossless audio.

Here is my hackfix:

https://github.com/oneman/libflac/commit/67e13364032404ebc1837af143fdd1cd81786c3a

I hope you like it.

Cheers,

David Richards
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev