flac compression level

[jls001]

I guess I muddled up the definition of "real time".

Real time with respect to a song file would be if the processing on that file happens as fast as the song plays.

I tried an experiment - I converted a .wav file of 60.56 MB size into Monkey's Audio. Playing time of this track is exactly 6 minutes (360 secs). Time taken to compress it into .ape is approximately 6 secs. I say approximately because it was difficult to keep an eye on the conversion and the countdown clock simultaneously and note down exact duration. The reverse also took about the same time.

So for my computer configuration, compress or decompress time is 6/360, which is measly 1.667% of play time.

The above is done using Monkey's Audio's own software at Normal Compression/Decompression.

I tried similar conversion to FLAC using MediaCoder 2011 Build 5220 - takes about 2 secs for the same file with compression set to LOWEST. On changing compression level to middle (4), it still takes the same amount of time. When compression is taken to highest (8), it needs 10 secs.

Lastly, I used MediaCoder's built-in Monkey's Audio codec. It took 6 secs for the compression (with compression set to HIGH which is the middle setting on a scale of 1 to 5). But when moving up the compression level dial to the highest INSANE level (5), it takes 42 seconds for the same task.

 

[kumarab]

Can't believe this discussion is still going on. As I already said FLAC decoding is not a problem for even smartphone procs in real-time.

For reference, it takes a little more than 5 minutes for a Pentium II 333Mhz (with 256MB RAM) machine to decode a a full 14 track CD converted to FLAC. That's like 12-15 times faster than real-time. Please go to FLAC's sourceforge page and check the specifics yourself. Monkey's takes a little more than 14 minutes, that's still about 5x faster than real-time.

If someone has issues with any media player (hardware or software) with real time decoding of any audio codec/container/format, then something is seriously screwed up in their system.

EDIT: @jls001--Was a little late; I see you're clear about the real-time bit.

 

[alpha1]

To everyone:

If FLAC is not being decoded in real-time, then how do I hear the file in real time???
There is no stopping, no buffering happening (like streaming audio) while I listen to the FLAC file.

In fact, lets say I have a FLAC file in external media - and play it.
While playing, I pull the external media off - the FLAC file still plays for a few seconds before stopping.

This shows that the decoding takes place faster than what I can hear - and file is stored temporarily in audio buffer/RAM/temp, and played from there.

The smallest 'piece' that flac decodes is a subframe and a number of these are assembled to create a frame. One or more of these frames is then played as they represent the audio data. Of course lots of other things happen for eg., channel separation for stereo sources or error correction... during this time.

You mean you hear the individual microseconds of music interspersed with microseconds of silence when the FLAC file is being played?

 

[Thad E Ginathom]

I'm not sure about your diagnosis, because we don't have a way of knowing where in the processing chain, or for what reason, buffering is happening.

Can't believe this discussion is still going on. As I already said FLAC decoding is not a problem for even smartphone procs in real-time.

Yes, I agree. FLAC is perfectly listenable to. What surprises me is that, outside of those already mentioned who outlaw compression for no technically good reason, I always thought that FLAC was an audiophile-approved format! However, such discussions often raise interesting technical points and ideas.

Latency... nothing happens instantaneously. It takes time for bits to be read from a hard disk, be processed by whatever, be passed to a sound card or DAC and get converted to analogue sound that we can actually hear. The thing about latency is that it does not matter at all. (Unless you are doing studio work like laying down a track while you listen to another, in which case it matters desperately).

It is nice if there is not a perceptible lag between operating play/pause/stop and something happening. In fact, it is not at all nice if there is! But that is the only practical effect of latency.

Some people read a whole song into RAM before playing: how's that for latency?

 

[nandac]

i have been ripping a bunch of CDs. just noticed that most of them sample size shows as 16 bit. is that the best you can get?

i checked some of the newer CDs i had ripped - like john mayer's continum. even that's showing 16 bit.

appreciate any insights.

 

[reignofchaos]

FLAC decompression is a non issue. Even a 600MHz arm proc is more than enough for decoding flac in realtime. Even an atom CPU would be able to decode ten or more flac streams at the same time if required.

@nandac : all CDs are 16bit/44.1kHz.

 

[jls001]

My personal conclusion is that the delay caused by the decompression process is a non-issue. My simple experiment showed that it takes about 2 secs to decompress a file that has playing time of 360 secs.

This can be achieved in the traditional 2 sec break between CD tracks. I am assuming ('cause I don't know the exact process followed) here that the player decompresses the file completely, store it in some temporary memory location, then starts playing it. Alternatively, the process could also be that it decompress a chunk, play it, then decompress more chunks and play it, and so on. I would be glad if someone can point out the actual process used by media players.

Also, as long as the time delay during playback is constant and the actual pace of the music is not affected, the listener will not feel anything unusual because he doesn't have a faster reference.

All this is of course academic. We all know that foobar (or whatever is your media player of choice) plays flac files beautifully. So decompression works as intended. But it is good to minutely examine, as far as our limited knowledge and capabilities allow us, things we take for granted. I have taken away a lot from this discussion.

 

[alpha1]

i have been ripping a bunch of CDs. just noticed that most of them sample size shows as 16 bit. is that the best you can get?

i checked some of the newer CDs i had ripped - like john mayer's continum. even that's showing 16 bit.

appreciate any insights.

Online Audible Dynamic Range Sound Test
Why not take a test here, and see if 16 bit is too much or too less for our ears.


Higher bits like 24 are required when you wish to do mathematical manipulations (like mixing etc). In that case higher bit rates result in errors in Least significant bits that can be truncated in the final 16 bit - and you get final result without any "noise" or "distortions"

In fact if you have time, http://people.xiph.org/~xiphmont/demo/neil-young.html, check this up too.

 

[Thad E Ginathom]

My personal conclusion is that the delay caused by the decompression process is a non-issue. My simple experiment showed that it takes about 2 secs to decompress a file that has playing time of 360 secs.

This can be achieved in the traditional 2 sec break between CD tracks. I am assuming ('cause I don't know the exact process followed) here that the player decompresses the file completely, store it in some temporary memory location, then starts playing it.

I doubt it, because sometimes there is no gap when listening to live recordings, for instance, hence my ranting against non-gapless software players.

Compression is closely related to cryptography, and, I'm afraid that, with such mathematical sciences, my eyes glaze over within a minute, and my brain seizes up shortly afterwards. However, I can remember this much theory about compression...

One of the ways that it works is by not storing repeated patterns in full each time, but only storing a pointer to a note of the pattern. IIRC, this requires a certain amount of header data to be loaded before the file is read, so that these references can be found when required. The principle is the same for any sort of data, as far as I know: in practice, the music-compression algorithms must be optimised for, err, music. I guess that they must also have the fact that stopping to think about it is not acceptable built into them. If anyone comes across a description of the process aimed at a six-year-old who can't do sums, then it would probably suit me.

Why not take a test here, and see if 16 bit is too much or too less for our ears.

And, having done that, try some of other tests on that site. Fascinating and revealing stuff!