Are there any efforts in the direction of "real time" FLAC?

The idea is that audio data is coming in at a constant rate (e.g. audio card). The compressor gets a limited amount of time to chew on each block of audio and writes out the best so far when the next block arrives. Sort of "interrupted" operation. Since FLAC basically boils down to "compress a block in 200 different ways and take the best one" it should be very well suited for such a mode of operation. The overhead of encoding the residue and writing out the compressed block will be taken away from the time to encode the next data block.

The compression ratio you'll get will depend on the CPU power, not on any preset value.

Very useful for recording application (save disk space), and a very efficient way to spend all those otherwise wasted CPU cycles while recording an LP.

Foobar2000 + foo_record + foo_flaccer allow you to record and compress to flac in one step.

I've been successfully doing that, but found out that large flac files have some seeking issues (with large jump foobar was usually stopping playback instead of doing the seek) and switched to foo_monkey which works perfect.

In practice I find there isn't much end result difference between "medium" which compresses at manyXrealtime and high which is much slower. This might be a good approach for realtime encoding on portables where CPU power is more limited.

I think what you mean by "real-time" depends all on the speed of the hardware you're running. The reference flac encoder encodes at real-time speed with the default settings even on what would be considered a really slow PC now (I get >5x realtime encoding on a 1998 P2 333 Mhz PC).

If you're talking about managing the recording and encoding processes so that this can be effected, this is more of a OS kernel and hardware problem. e.g. rawrec can record directly from card to FLAC on Linux with no problems.

Josh

I guess you were both missing the point here. Yes, on a fast machine you can get it to run in realtime. But that is not what I meant.

The idea is that, rather than instructing the compressor to "compress this block and try 50 different predictors" you instruct it to "compress this block in 1 second" or "compress this block until I tell you to stop".

This is very useful in applications where the available horsepower is much more limited, such as portable devices, but also for CD ripping, as the audio data is allowed to pass continuously without ever interrupting the flow, giving less chance of jitter, but still yielding the best possible compression.

Mike.

I think what you mean is basing an encoder on encoding time, rather than quality or bitrate.

I think this would be useful, and while it would not be feasible for lossy encoders as the quality of the resultant file would differ greatly, FLAC is lossless, so the only difference in the resulting files would be size, not content. Obviously on a faster machine, the files would be smaller, and vice versa. I think this is a great idea.

A good start may be specifying a certain X realtime (I think you obviously mean 1x realtime) and going from there. Maybe it would be possible to specify something like 4x realtime and use it with EAC (or maybe more like 12x in my case, although 4-6x isn't unusual with EAC secure in my experience.)

This could be an easy and transparent way to save a lot of space on a computer when recording sound, and eventually maybe in recording hardware.

-spase

I haven't gotten any feedback that the lack of such a thing is holding back adoption of FLAC encoding on portables. It's a nice idea though.

As for use with ripping, I don't see how jitter enters into it. Audio data doesn't need to pass continuously without interrupting the flow because a PC has essentially limitless flow control and buffering ability.

Josh

Yea i think it would be kind of a cool idea too. It would have a LOT of practical applications.