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).
FLAC and TAK are within 2% of each other.......
FLAC vs TAK (http://www.hydrogenaudio.org/forums/index.php?showtopic=79388)
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.
FLAC and TAK are within 2% of each other.......
FLAC vs TAK (http://www.hydrogenaudio.org/forums/index.php?showtopic=79388)
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.
TAK 2.2.0 vs FLAC (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=88968&view=findpost&p=762706)
Between 1 and 4%......
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:
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.
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 (http://members.home.nl/w.speek/comparison.htm)
My old Pentium 3-550 could play monkeys normal-high just fine. CPU was like 5-7%. I built that machine back in 1999
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.
have you tried reporting your problems with TAK playback? the developer is active on these forums.
SyntheticSoul's speed and compression comparison as of 3 years ago: http://www.synthetic-soul.co.uk/comparison...sless/index.asp (http://www.synthetic-soul.co.uk/comparison/lossless/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 (http://www.cuetools.net/wiki/CUETools_FLAC_encoders_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 ...)
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.
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.
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.
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?
Have you set up your player for buffering? Decoding way into the future could leave it busy for a couple of seconds.
Try dsfTAKSource: http://liviocavallo.altervista.org/ (http://liviocavallo.altervista.org/)
It will enable playing TAK files quite well in all DirectShow players.
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.
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?
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?
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?
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.
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).
Sad to see that noone linked to our own wiki..
http://wiki.hydrogenaudio.org/index.php?ti...less_comparison (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison)
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?