Nevertheless information theory has nothing to say about algorithms that can losslessly compress a data stream at a predetermined number of bytes per second.
.... But, statistically this algorithm will center its statistical Gaussian peak on the selected target CBR BPS. And the longer the file, the closer it will get to the target CBR BPS...If you want to submit some math to prove me wrong, please feel free to do so.
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.
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.
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.
Congrats, you just described an ABR procedure. Nothing about that will provide a Constant Bit Rate unless you pad.
Well if you are encoding the signal in advance, you could – in principle – get a CBR at a bitrate equal to the peak. That would still save bandwidth, provided that the signal doesn't max out the bitrate anywhere.
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.
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
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).
No. This claim is defensible.
Which means that one cannot predict in advance the length of ouput file that will be generated for any input stream.
That is still ABR if you don't pad, and it still fails to address your original concern:
because one can not predict the maximum needed bitrate until the entire track is encoded.
Quote from: Porcus on 24 November, 2012, 05:36:34 AMWell if you are encoding the signal in advance, you could – in principle – get a CBR at a bitrate equal to the peak. That would still save bandwidth, provided that the signal doesn't max out the bitrate anywhere.This was why I was inquiring about bitrate histograms for lossless encodings.You might be able to shave off a little with some source material, but what do you do when you find frames with bitrates larger than their uncompressed PCM counterparts?
Actually ABR would go a long way in addressing my concern. With the method I described, if you calculated Content Length based on the target ABR then you could be sure that the actual delivered Content Length would always be greater than or equal to the calculated Content Length.
AFAIC, it confirms what has already been suggested: peak bitrates are likely going to dash hopes of worthwhile CBR/ABR implementations of lossless compression.