Skip to main content

Topic: Recommend me a lossless codec—looking for a nice compression–to–speed  (Read 9373 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Dario
  • [*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Howdy, people from Hydrogenaudio

As per the topic's title, I am looking for a lossless codec that offers a nice compression (something around Monkey's Audio's High) along with a nice encoding/decoding speed (I am more concerned about the decoding). I initially stumbled upon TAK, which had everything I could ask for, but much to my demise, I found out that the playback of TAK is rather buggy—the official Winamp plug-in does not work well with 24/96 files (even though the TAK format supports high resolutions). Furthermore, I would ideally want the codec to be stable.

I would be very grateful to anyone who helps.

PS: Before mentioning FLAC, I have to say that I am dissatisfied with the compression it offers, as my storage space is pretty limited (and won't be improving until this summer at earliest).

  • Ouroboros
  • [*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #1
FLAC and TAK are within 2% of each other.......

FLAC vs TAK

  • Soap
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #2
If decoding speed is an issue you apparently aren't using a desktop or tethered laptop for playback, so at the minimum you've left out one important piece of information.  More details needed - you've made an unusual request and don't appear to have adequately explained what your constraints are.
Creature of habit.

  • Dario
  • [*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #3
FLAC and TAK are within 2% of each other.......

FLAC vs TAK

That test was made with TAK 2.0.0, the later versions (2.1.0 and 2.2.0) improved both compression and speed by a nice amount. As a matter of fact, TAK offers a much nicer compression than FLAC—even higher than Monkey's Audio's High (albeit by a tiny bit) on most of the albums I had ripped.

If decoding speed is an issue you apparently aren't using a desktop or tethered laptop for playback, so at the minimum you've left out one important piece of information.  More details needed - you've made an unusual request and don't appear to have adequately explained what your constraints are.

I am using a desktop, but it's pretty old (Pentium D @ 3 GHz, 2 GB DDR2 RAM), so decoding and playing back a file compressed with Monkey's Audio's Very High (or something similar) is a—pardon my language—pain in the ass.

I remember trying WavPack with the -x 6 switch, but the encoding took way too much time.
  • Last Edit: 25 January, 2012, 06:53:40 PM by Dario

  • Ouroboros
  • [*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #4
TAK 2.2.0 vs FLAC

Between 1 and 4%......

  • Dario
  • [*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #5
3–4% is quite a nice amount, at least in my eyes. I really don't know what's wrong with the decoding library, but 24/96 rips (from vinyl) showed incorrect duration and sampling rate. Well, even the author himself stated in the readme:

Quote
Because of my very old sound card, i could not test 24-bit playback. Futhermore: Some visualization plugins don't support 24-bit data. It has to be converted to 16 bit before sending it to those plugins. This has not been implemented yet! It's very easy to do, but i don't want to include code, which i am not able to test. I will soon buy a better soundcard.

  • Soap
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #6
I am using a desktop, but it's pretty old (Pentium D @ 3 GHz, 2 GB DDR2 RAM), so decoding and playing back a file compressed with Monkey's Audio's Very High (or something similar) is a—pardon my language—pain in the ass.

Monkey's Audio High decoded at 14x realtime (7% CPU) on MUCH older hardware than yours back in 2005.  I am having a hard time believing its CPU consumption is a problem.

http://members.home.nl/w.speek/comparison.htm
Creature of habit.

  • shadowking
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #7
My old Pentium 3-550 could play monkeys normal-high just fine. CPU was like 5-7%. I built that machine back in 1999
  • Last Edit: 25 January, 2012, 08:47:22 PM by shadowking
wavpack -b4x4s1c

  • shadowking
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #8
You could try wavpack -h or -hh should be close to monkeys. Very fast encoding and still decent decoding considering the compression. Wavpack is mature, stable  supported on all platforms. Its supposed to have the best support for hi-res audio.
wavpack -b4x4s1c

  • marc2003
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #9
have you tried reporting your problems with TAK playback? the developer is active on these forums.

  • Porcus
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #10
SyntheticSoul's speed and compression comparison as of 3 years ago: http://www.synthetic-soul.co.uk/comparison...sless/index.asp
In that test corpus, you could not simultaneously improve both decoding speed and compression ratio over Monkey's High.

Notice that there are 3rd party FLAC implementations which improve on compression. Brief overview at http://www.cuetools.net/wiki/CUETools_FLAC...ders_comparison – if you really want to save those extra percents, you would probably not worry about going outside the Subset.


However ...
* There are very few tests done with a 24/96 vinyl rip test corpus.
* You have noticed that some of the codecs (you mention TAK) are not optimized for that resolution ...
* ... and certainly not for the content, where, frankly, you are paying to store a lot of noise. Probably makes a bit more sense for professionals' archives than for a consumer ...

If you insist on 24/96, you would probably have to test for yourself to get an idea of compression ratios. (By all means, post results here – even though myself I think it has limited practical relevance, I am a curious geek, and not the only one in this forum ...)
  • Last Edit: 25 January, 2012, 10:09:00 PM by Porcus

  • washu
  • [*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #11
I am using a desktop, but it's pretty old (Pentium D @ 3 GHz, 2 GB DDR2 RAM), so decoding and playing back a file compressed with Monkey's Audio's Very High (or something similar) is a—pardon my language—pain in the ass.


As someone who has used Monkey's Audio extra high since a PIII was a fast computer I find this comment strange.  Even on my single core Atom netbook playback takes an insignificant amount of CPU.

Now conversion is another matter, I wouldn't want to use my Atom regularly for that.

  • Dario
  • [*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #12
Whenever I try to open a file encoded in Monkey's Audio Very High, my CPU needs like 2-3 seconds to start playing back—the same happens with seeking. I don't really like that (I don't like it at all), seeing as I use lossless files for listening purposes as well as for archiving.

  • probedb
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #13
Whenever I try to open a file encoded in Monkey's Audio Very High, my CPU needs like 2-3 seconds to start playing back—the same happens with seeking. I don't really like that (I don't like it at all), seeing as I use lossless files for listening purposes as well as for archiving.


But that's not necessarily the CPU, slow hard disc drive, fragmented drives, there could be any number of reasons but as others have said it's not the codec.

  • dhromed
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #14
Whenever I try to open a file encoded in Monkey's Audio Very High, my CPU needs like 2-3 seconds to start playing back


Strange. Based on your specs alone, that really shouldn't be happening. Just by numbers, your computer is quite sufficient by a very wide margin to decode audio instantly.

Does it also happen with the other higly compressed lossless formats? What about other formats? Other applications? Video playback? Have you checked DPC latency?
  • Last Edit: 26 January, 2012, 09:55:22 AM by dhromed

  • Porcus
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #15
Have you set up your player for buffering? Decoding way into the future could leave it busy for a couple of seconds.

Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #16
Try dsfTAKSource: http://liviocavallo.altervista.org/
It will enable playing TAK files quite well in all DirectShow players.

  • n0v!ze
  • [*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #17
For years, I've been using FLAC and only recently switched to True Audio. Two to five out of hundred rips didn't play properly in Winamp with cue_in, some songs stopped right in the middle. Time display is always a few seconds behind. Well, this may all be related to cue_in or other things related to my machine and not to FLAC. Don't want to blame FLAC here, it's a great tool.

The True Audio Encoder ttaenc has two perceived disadvantages: Nearly no compression options and inability to redirect output to a pipe. For the type of music I listen to, which is mostly Heavy Metal, I found that the generated files sizes of .flac and .tta are nearly identical when compression to FLAC is done with second best ratio (Q 7 out of 8). Both encoding and decoding speed are at least on the same level, my (unverified) impression is that True Audio is often faster. Should I ever need the pipe output, I will apply the patch provided by the sox developer.

An advantage of True Audio is that it supports ID3 Tags. I create both lossless and lossy files when I rip. Having the very same id3 tags in both formats makes file management easier (for example file and folder name generation from tags). True Audio lacks a metatta utility but I didn't use metaflac anyway so I'm not missing it. True Audio is Open Source Software like FLAC is. Like FLAC, it lacks active development for a couple of years. Perhaps WavPack is the better, actively developed alternative? I don't know.

  • db1989
  • [*][*][*][*][*]
  • Global Moderator
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #18
For years, I've been using FLAC and only recently switched to True Audio. Two to five out of hundred rips didn't play properly in Winamp with cue_in, some songs stopped right in the middle. Time display is always a few seconds behind. Well, this may all be related to cue_in or other things related to my machine and not to FLAC. Don't want to blame FLAC here, it's a great tool.
This is probably due to TTA. Another reason to ask why you bothered to switch?

Quote
The True Audio Encoder ttaenc has two perceived disadvantages: Nearly no compression options and inability to redirect output to a pipe. For the type of music I listen to, which is mostly Heavy Metal, I found that the generated files sizes of .flac and .tta are nearly identical when compression to FLAC is done with second best ratio (Q 7 out of 8). Both encoding and decoding speed are at least on the same level
Again, why?

Quote
Both encoding and decoding speed are at least on the same level, my (unverified) impression is that True Audio is often faster.
This is a contradiction in terms. Are they the same, or is TTA better?

Quote
An advantage of True Audio is that it supports ID3 Tags. I create both lossless and lossy files when I rip. Having the very same id3 tags in both formats makes file management easier (for example file and folder name generation from tags).
What is the benefit of having ID3 rather than Vorbis Comments? There are applications that can use the latter to name files/folders, too.

  • Porcus
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #19
True Audio is Open Source Software like FLAC is. Like FLAC, it lacks active development for a couple of years. Perhaps WavPack is the better, actively developed alternative? I don't know.


Whether stability or active development is better, is a matter of opinion and subject to the need for development of the particular applications. Now if my impression is correct, much of last few years' development of WavPack, is on the lossy or hybrid features. Anyway, the developer himself is an active member of this forum (well, FLAC's Josh Coalson is here too, but not very active ... and I seem to recall some TTA devs in old threads). The TAK developer is also here.


Both encoding and decoding speed are at least on the same level, my (unverified) impression is that True Audio is often faster.


If you are curious about decoding speeds, then foobar2000 has a speed tester. On a fairly recent computer with a moving-parts harddrive (as opposed to a portable device or SSD), then decoding could very well be constrained by the harddrive, as FLAC is very fast (never tested TTA, but on my computer, FLAC usually decodes at least 50% quicker than mp3.)

Encoding? If you are switching formats every now and then, you would worry about that. But most of us do encode an average of 1-point-something times


mostly Heavy Metal,
[...]
An advantage of True Audio is that it supports ID3 Tags.


... so that you can have a tagging scheme which disallows AC/DC 
(Seriously, who the f(x) designed that?)


If you could see yourself using Linux, then there is the MP3FS virtual file system, which creates mp3s on-the-fly from FLAC (currently only that format supported).

  • Jan S.
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #20
Sad to see that noone linked to our own wiki..

http://wiki.hydrogenaudio.org/index.php?ti...less_comparison

  • Porcus
  • [*][*][*][*][*]
Recommend me a lossless codec—looking for a nice compression–to–speed
Reply #21
Sad to see that noone linked to our own wiki..


... sorry. But I did use it to find sources I linked to, does that count?