Streaming FLAC over the Internet, Split from "The Future of FLAC" Options

[andrewfg]

IMHO flac has one technical weakness that will prevent it taking off as THE standard -- namely it only has Variable Bit Rate compression algorithms. Which means that one cannot predict in advance the length of ouput file that will be generated for any input stream.

This is a problem when you want to transcode another format of audio file to flac and stream it over Http. The Http protocol requires sending a Content Length (number of bytes) header at the start of the streaming process. With flac you cannot know the number of bytes until after the full file has been transcoded. So this means that Http must either wait until the full transcoding has been completed, or alternatively if it wants to start streaming the data immediately, then it must provide some guessed value in its Content Length header (and this is not conformant to the Http specifications, and may cause problems in some music players...)

By contrast, if you are (say) transcoding to mp3 and streaming that via Http, then the transcoder can select a Constant Bit Rate compression algorithm. And in such a case, the Http Content Length is easily calculated in advance as being the input audio file's duration (in seconds) multiplied by the CBR rate (in bytes per second).

So if the flac standard were extended to allow both the existing Variable Bit Rate compression algorithm plus a new Constant Bit Rate option, then it would become much better suited for online streaming.

This post has been edited by andrewfg: Nov 22 2012, 12:07

[greynol]

If you want to submit some math to prove me wrong, please feel free to do so.

That's a use of the flying spaghetti monster defense we don't typically see with some argument from authority sprinkled in which we do typically see.

Despite your insistence that you're smarter than the rest of us, I think I'll wait until I see your idea put into action and take note of what those CBR bitrates actually are, thanks. I won't be holding my breath on the bitrates being interesting, let alone the idea being implemented; in other words, I think we'll chalk this up as a fail on your part after it is all said and done.

In the meantime, does anyone know of a program that displays a histogram of bitrates from flac and hopefully some of the other more popular lossless formats?

There we go a CBR Lossless format

Sure, but we already covered that.

This post has been edited by greynol: Nov 24 2012, 01:19

[andrewfg]

Despite your insistence that you're smarter than the rest of us,

Hey look, I am certainly NOT insisting that I am smarter than the rest of you.

I was merely reacting (badly) to the post of "soap" in which he wacked a wiki url ("spaghetti monster") at me and thereby claimed that he is smarter than me.

I think I'll wait until I see your idea put into action and take note of what those CBR bitrates actually are, thanks. I won't be holding my breath on the bitrates being interesting, let alone the idea being implemented; in other words, I think we'll chalk this up as a fail on your part after it is all said and done.

I don't think you should chalk any such "fail" to me. The OP had asked about the future of flac. And I indicated that there is a specific weakness of flac in relation to its use for online streaming that could be detrimental to its future penetration in media servers and renderers. And I have proposed a possible solution. I don't think it is a "fail" on my behalf if that proposed solution would not be implemented. But it would sadly be a "fail" on behalf of the flac community, if the format were to die out because the community failed to look into this weakness.

It would be nice if others on this thread would be a little more humble in listening to criticisms, rather than (try to) shoot the messenger...

[Soap]

I was merely reacting (badly) to the post of "soap" in which he wacked a wiki url ("spaghetti monster") at me and thereby claimed that he is smarter than me.

Well, "andrewfg", I'd love a cite of where I claimed I was smarter than you, but that is beside the point:

And I indicated that there is a specific weakness of flac in relation to its use for online streaming that could be detrimental to its future penetration in media servers and renderers.

You mentioned a specific weakness of VBR encodings where the stream length is undetermined, not a weakness in a particular format but (as was pointed out) a weakness in any VBR compressed format. You went on to claim (and this is the meat of the issue) that one could make a lossless compressed format which was CBR. This is the claim which was responded to and quoted by me, and the claim which is indefensible. Curiously it is also the discussion you are currently choosing to ignore.

[andrewfg]

You mentioned a specific weakness of VBR encodings where the stream length is undetermined, not a weakness in a particular format but (as was pointed out) a weakness in any VBR compressed format.

No that is absolutely is NOT what I said. Please read my OP again. I actually said that a weakness of flac is that it does not offer a CBR option.

You went on to claim (and this is the meat of the issue) that one could make a lossless compressed format which was CBR. This is the claim which was responded to and quoted by me, and the claim which is indefensible.

No. This claim is defensible.

Let us start with some basic information theory. If you have a data stream containing maximal information such that its content appears to be random then indeed by definition such content cannot be losslessly compressed. However if you have a data stream containing to some extent redundant and repeating patterns, then that data can be losslessly compressed; essentially this is done by using short codes and lookup tables to substitute for the original longer repeating patterns. Music contains a lot of redundancy and repeating patterns, and it therefore lends itself well to being losslessly compressed. And flac is a good algorithm for maximally compressing music.

When a lossless compression algorithm processes a data stream, it reads the data block by block, and it creates and writes out the resulting short codes and lookup tables for each block successively. Depending on the redundancy and repetition in the content of each block, the resulting output block will tend to be shorter in size than the input block. But there are two extremes: a) if a particular block contains no redundancy and repetition, (i.e. it is indiscernible from random data), then the output block will be at maximum the same size as the input block plus some overhead due to the compression algorithm's framing mechanics, and b) if a particular block contains 100% redundancy and repetition then the output block will be at minimum zero plus some overhead due to the compression algorithm's framing mechanics. And typically the output block size will be somewhere in between these two maximum and minimum limits i.e. somewhere in the range between the overhead due to the compression algorithm's framing mechanics, and the size of the original input data plus the overhead due to the compression algorithm's framing mechanics. Or in other words, given an input block's size "I", and the overhead due to the compression algorithm's framing mechanics "M" then the output block's size "O" will be as follows:

M <= O <= (I + M)

And the compression factor "V" for each block is defined as:

V := O / I resulting in V(minimum) := (I + M) / I and V(maximum) := M / I

So indeed V is variable (VBR) within the range V(minimum) to V(maximum), depending on the redundancy and repetition in the content of each block. As the algorithm processes more and more blocks the individual V values for each block will average out to a value such that:

V(minimum) < V(average) < V(maximum)

The actual value of V(average) will be highly specific to the content of the specific data stream. And indeed its value is not predictable in advance.

The flac algorithm has 9 different aggressivity grades of compression, and on the same data stream each grade will result in a different V(average) compression rate. Let us call these V(average_0) through V(average_8), and so:

V(minimum) < V(average_0) < V(average_1) < ... < V(average_7) < V(average_8) < V(maximum)

Now let us say we want to target on a fixed bit rate over the whole data file. Or as another poster mentioned a fixed average bit rate. This is equivalent to targeting a fixed (average) compression factor. Let us call this A(target), and let us choose it so that:

V(average_0) < A(target) < V(average_8)

Then the compression algorithm, as it processes over each individual block in the input data, would start processing at grade 8 compression, and it will probably determine that it is delivering a higher net average compression than A(target). So for the next few blocks it could back off to say grade 0 compression, and those blocks would deliver a lower net average compression than A(target). And then again for the next few blocks it could select grade 8 compression again. And so on. The compression algorithm would juggle the compression grades so that the net-net average compression over all processed blocks would get close to A(target). And indeed the longer the file, the closer the algorithm will get to A(target).

Now obviously, as we have already seen, the V(average) of any track depends on the degree of redundancy and repetition in the content. So it is indeed possible that if one has bad luck in the choice of source material, then the chosen A(target) might not lie within the bandwidth V(average_0) < A(target) < V(average_8) for that particular source material. This means that the actual delivered level of compression could end up less than the selected A(target). The trick would obviously be to choose an A(target) that is closer to V(minimum) than it is to V(maximum). So in other words there will nevertheless always be some outlier cases where A(target) is not achieved. But if you are not too aggressive and don't have too much bad luck on source material choice, it would work fine.

[greynol]

if a particular block contains no redundancy and repetition, (i.e. it is indiscernible from random data), then the output block will be at maximum the same size as the input block plus some overhead due to the compression algorithm's framing mechanics

Here is where we run into problems with information theory. My suspicion is that problems arise even when dealing with signals that still contain what you casually refer to as redundancy, especially since you have to figure out how to implement something with real-world constraints in terms of things like making a signal easy enough to decompress (and compress for live streaming) and other considerations which need to be taken into account in order to satisfy playback requirements.

Again, a simple histogram will show the feasibilty of creating a codec similar in function as flac that employs a CBR mode.

This post has been edited by greynol: Nov 24 2012, 19:06