Re: Lossless codec comparison update
Reply #9 – 2023-08-31 19:42:27
encode faster than they decode Why ask when I can reproduce and confirm , ... Actually, so is the case for TAK as well. It is visible in ktf's charts, and on this computer on high resolution (96 and 192), both TAK -p0, -p1, -p2 and -p3 would encode faster than decoding. Moreover, still on high resolution, -p0 would encode/decode at FLAC -0 speeds, although that is the absence of MD5 calculations. Isn't really surprising to me. On encoding, all data is available, and that means you can either do SIMD or use superscalar capabilites better. At least with FLAC, quite a lot of operations are independent. On decoding, you really need to do stuff sequential, because you don't yet have all the data. On a really FLAC fast preset, there is almost no brute-forcing going on, which means the advantage mentioned above is visible. With the slower presets, there is some sort of brute-forcing, meaning some calculations are not used in compression because it turned out a different route resulted in better compression. Combine that with the fact that FLAC has seen most optimizations happen for the slowest presets on encoding (i.e. the brute-forcing) and that optimizations for decoding have been much more general (i.e. parsing), and you see why the focus on the fast presets resulted in this.But it might be the case for TAK -p0 on CDDA too? @ktf , you got the numbers ... ? I tested it on this computer, and differences are very small - but then, this computer has also small speed differences between TAK -p0 and TAK -p1. I didn't. I just hacked my script to give me the raw data. Just the main graphs, not the 96kHz and 5.1 graphs. Colums are: codec, preset, encoding CPU speed, encoding speed (wall time), decoding CPU speed, decoding speed (wall time), compression