Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Lossless Compression Test (Read 116990 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lossless Compression Test

Reply #25
I suppose that in practice, users just want their music collection to fit on your old 2TB drive rather than having to buy a new 3TB drive, right?

Let's not forget the plus one for the pot... hem for the backup: I always sum twice (at least) the space when think about my laburiously ripped lossless collection and still cloud storage services aren't a feasible alternative to doubling physical disks.

Quote
(By the way, I use a 2nd lossless to distinguish those CDs which came with pre-emphasis. As I don't convert them, merely tag them (and decode on-the-fly), I want to be insured against accidentally deleting tags.)

A little obsessive on the matter? Me getting  too... 
... I live by long distance.

Lossless Compression Test

Reply #26
I'd agree with skamp. There's a saving of 10GB between FLAC -8 and LA-HIGH which is nothing. I think it comes down to whether you're using older hardware or not as encoding speed even at these levels is a fraction of ripping time too.

I'll stick with FLAC

Actually the difference is 9GB and between LA -HIGH and FLAC -5 and 8.33GB between LA -HIGH and FLAC -8. Considering the speed between -8 and -5 I'll stick with -5.

Apple did a good thing with ALAC, it didn't create confusion. They compared different algorithms, speeds and codecs and left only one for the user. I am sure whoever uses ALAC got over the headache of which "compression" to use, just to save few MBs, the first day.

Lossless Compression Test

Reply #27
Quote
I suppose that in practice, users just want their music collection to fit on your old 2TB drive rather than having to buy a new 3TB drive, right? (And all the other features of a modern lossless, like tagging capabilities.)

Yikes! A compression increase of 33% above the average of these codecs' results?


Precisely. There's a “what's your compression ratio?” thread at http://www.hydrogenaudio.org/forums/index....showtopic=97125 . My FLACs clock in at slightly above 900.
While space certainly was more of an issue at the time when you had to build a computer which had enough space and mobo for the drives (anyone who needs an IDE card or two?), it kinda still is: even if I were to buy drives now, I would save me a couple of hundred dollars from audio compression, plus the video part of the DVDs.


Lossless Compression Test

Reply #29
Considering the speed between -8 and -5 I'll stick with -5.


I actually use flac -8 because even at that setting encoding is still so much faster than my cd drive can read that it doesn't matter. Also, encoding is something I only do one time so even IF it made a difference (within reason) I'd still use -8. Decoding speed and efficiency are the big issues.

Lossless Compression Test

Reply #30
The TAK -p4m run is done.
Code: [Select]
Codec          GB        Compression
TAKC -P4M    189.49        64.59%

Now on to OtimFrog and WavPack.
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.

Lossless Compression Test

Reply #31
May i ask you the correct parameters to use the .la high conversion??

Lossless Compression Test

Reply #32
Lots of people around here seem to be interested in turning on all the slowest brute-force options. But you're not using anywhere near enough brute force here! Clearly, since you aren't looking at encode or decode time, the right thing to do is run a program that, using an enumeration of all Turing machines, simulates more and more of them for increasing periods of time, checking whether the TM halted with the entirety of your music collection in its output. The compressed format of your music is then just a description of the shortest TM you discover that does that.*

Since a significant amount of data in your lossless files is below the instantaneous noise floor and therefore effectively random, doing this may still not give you tremendous savings over FLAC. (If FLAC compresses to 50% and 1/4 of the bits of the original are effectively random noise, it's entirely impossible for any lossless compressor, no matter how miraculous, to beat FLAC by a factor of 2; this is kinda like Amdahl's Law, with "incompressible part" taking the place of "nonparallelizable part.")

Also, of course, decode time might be rather long and encode time is likely to be many times longer than the lifespan of the universe. But hey, you saved a few gigs! Surely that's worth it!

*See wikipedia's article on Kolmogorov complexity. Note that even then you are unlikely to be able to guarantee you've come up with the shortest description, since some shorter TMs which seem like they're not going to halt could eventually output your music collection and halt. To prove you've got the shortest you would have to prove that all shorter programs either halt without reproducing your music collection or never halt, and the halting problem is in general uncomputable.

Lossless Compression Test

Reply #33
Lots of people around here seem to be interested in turning on all the slowest brute-force options. But you're not using anywhere near enough brute force here! Clearly, since you aren't looking at encode or decode time ...

  I see only one contributor to this thread to whom your above statements apply. I, for example, don't consider FLAC -8 a brute-force option - if it were, it would try to find e.g. the optimal LPC order via brute-force... which it doesn't. And I completely agree with yourlord.

Chris
If I don't reply to your reply, it means I agree with you.


Lossless Compression Test

Reply #35
Since a significant amount of data in your lossless files is below the instantaneous noise floor and therefore effectively random, doing this may still not give you tremendous savings over FLAC. (If FLAC compresses to 50% and 1/4 of the bits of the original are effectively random noise, it's entirely impossible for any lossless compressor, no matter how miraculous, to beat FLAC by a factor of 2; this is kinda like Amdahl's Law, with "incompressible part" taking the place of "nonparallelizable part.")

How do you measure the noise floor?
Because I suspect you don't and if you don't - the quote above is rubbish.

Lots of people around here seem to be interested in turning on all the slowest brute-force options.

I partially agree with this...partially because testing codec speed is something that anybody can do easily. It's imperfect, but much faster than large scale tests.

2 A_Man_Eating_Duck:
Could you please update the first post?
Not necessarily after each new codec tested, but I guess many people won't look farther than that.


Lossless Compression Test

Reply #37
May i ask you the correct parameters to use the .la high conversion??
i used this
Code: [Select]
LA.exe -high "%inputfile%" "%outputfile%"



2 A_Man_Eating_Duck:
Could you please update the first post?
Not necessarily after each new codec tested, but I guess many people won't look farther than that.
I'm going to wait for all the other encodes to finish, make some new graphs and ask a mod to update the original post.
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.

Lossless Compression Test

Reply #38
Personally I don't care too much if encoding time gets longer for insane settings, as long as the speed is still acceptable, like flac's -8 or takc's -p4m. But if it gets too crazy like WavPack's -hh -x6, or the decoding speed reduced to a too costly rate, like falling from 15x to 3x, I would like to avoid those settings.

Lossless Compression Test

Reply #39
May i ask you the correct parameters to use the .la high conversion??
i used this
Code: [Select]
LA.exe -high "%inputfile%" "%outputfile%"



This works if i convert a file with the command line (cmd.exe), i was looking to the foobar2000 version of the "code" 


Lossless Compression Test

Reply #41
i was looking to the foobar2000 version of the "code" 
PS: i just realized i can't even play .la files in my foobar2000!!!
Where should i take the right input .la component? 



Foobar decoder: http://www.mediafire.com/download.php?f2bk6qitzu47qbd
But it is buggy


Thank you!! The conversion works good!!
The playback of a .la instead made my foobar2000 crash. really buggy!

Lossless Compression Test

Reply #42
On the topic of insane settings, I found flake -12 (r264 ,SVN version) to be the best CPU-based flac encoder I came across compression wise.

I wouldn't expect the size reduction to be relevant compared to -8. But in such a big collection, and with very small differences between various codecs, who knows?

 

Lossless Compression Test

Reply #43
Interesting comparison. 

During 2003 the prices of DVD drives and discs have gone down. People have moved to FLAC from Monkey Audio. Before that people cared about each MB when CD had only 700 MB.
http://imageshack.us/photo/my-images/206/ha1fg1.png/

Since 2003 FLAC is the most popular lossless format.

2009 ripping/encoding general poll
2012 ripping/encoding general poll

Fast decoding speed is appreciated much more than 4-5%  of better compression.

Lossless Compression Test

Reply #44
On the topic of insane settings, I found flake -12 (r264 ,SVN version) to be the best CPU-based flac encoder I came across compression wise.

I wouldn't expect the size reduction to be relevant compared to -8. But in such a big collection, and with very small differences between various codecs, who knows?
Damn you, i forgot about Flake, i'll add -9 + to the results as well
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.

Lossless Compression Test

Reply #45
http://www.cuetools.net/wiki/CUETools_FLAC...ders_comparison
Quote
libFlake and FlaCuda are tuned differently, so libFlake -5 might in fact compress better than libFLAC -8. They also support additional compression levels 9-11, however their use is not recommended, because those levels produce so called non-subset files, which might not be supported by certain e.g. hardware implementations.

Lossless Compression Test

Reply #46
double damn, ok i'll put all of them in for flake
Who are you and how did you get in here ?
I'm a locksmith, I'm a locksmith.

Lossless Compression Test

Reply #47
FLAC also has some addtional parameters those  help a little bit.

Like:  -8 -A tukey(0.5) -A flattop
Like here http://www.synthetic-soul.co.uk/comparison...sion&Desc=0

Maybe compression vs decoding speed is not less interesting (if not more) than pure compression comparison.

Lossless Compression Test

Reply #48
During 2003 the prices of DVD drives and discs have gone down. People have moved to FLAC from Monkey Audio.
...
Fast decoding speed is appreciated much more than 4-5%  of better compression.

Just wanted to mention my experience with lossless files on disc usually the max speed of the CD/DVD drive is the limiting factor. To clarify, when converting files made with TAK -p4m from CD/DVD to LAME MP3 the CPU is not hitting 100%.

I agree that I would spend the extra time spent on the encode side for some savings as long as decode speed is not terribly affected, but I doubt I would notice any decoding speed difference between TAK -p4m and FLAC -0 with files on a disc.
"Something bothering you, Mister Spock?"

Lossless Compression Test

Reply #49
May i ask you the correct parameters to use the .la high conversion??
i used this
Code: [Select]
LA.exe -high "%inputfile%" "%outputfile%"
Although if you're into purism, -high -noseek will squeeze out another few bytes by sacrificing seekability.  Which for .la files is worth doing, since the format, if anything, is good for archiving, without the immediate need for playability (i.e. fast decoding).  The latter is what you'd be using FLAC, TAK, ALAC of WavPack for.
Quote from: La 0.4b documentation link=msg=0 date=
input-filename(s) [output-filename(s)]
Flags
-high    -    high compression mode - slower, but better compression
(snip)
-noseek    -    disable seeking (improves compression slightly)