5 ms·
Tip for those who are looking at the compression ratios thinking "so what?": look at the run-times. It's a minimum of 3x faster than its contemporaries.
by sgbeal 3y ago
Tip for those who are looking at the compression ratios thinking "so what?": look at the run-times. It's a minimum of 3x faster than its contemporaries.
- harshreality 3y agoAccording to the author, right? Those results aren't backed up by Porcus's comments in that thread.
- fbdab103 3y agoIt seems the world made a collective yawn about flac. Hard to imagine that would change much with a new format. I personally keep everything in flac, but Bandcamp is seemingly the only service where that is a given.
- jiehong 3y agoQobuz also offers flac downloads for albums, but also linnrecords does that.
- chungy 3y agoA yawn? Is there any alternative that even has 10% of the mindshare of FLAC?
- fbdab103 3y agoJust that providers of flac are few and far between. The only reliable source of flac files are those you make yourself.
- moogly 3y agoFound the Apple user.
- prvc 3y ago>It's a minimum of 3x faster than its contemporaries. Ok, but what would make that useful?
- sgbeal 3y ago> Ok, but what would make that useful? Lower run-time means less electricity and less tying up of the CPU, making it available for other things. As a real-life example: i frequently use my Raspberry Pi 4 to convert videos from one format to another. This past week i got a Pi 5 and moved the conversion to that machine: it takes maybe 1/4th as much time. The principle with a faster converter, as opposed to faster hardware, is the same: the computer isn't tied up for as long, and not draining as much power.
- prvc 3y agoYes, but there's a threshold for effective improvements. If the more compatible and more efficient format only uses 16 seconds to encode 1 hour of audio, it's hard to imagine this making a big difference in any real use case, offline or real-time.
- sgbeal 3y ago> ... it's hard to imagine this making a big difference in any real use case, offline or real-time. Google once, back in 2013, made an API change to their v8 engine because it saved a small handful of CPU instructions on each call into client-defined extension functions[^1]. That change broke literally every single v8 client in the world, including thousands of lines of my own code, and i'm told that the Chrome team needed /months/ to adapt to that change. Why would they cause such disruption for a handful of CPU instructions? Because at "Google Scale" those few instructions add up to a tremendous amount of electricity. Saving even 1 second per request or offline job, when your service handles thousands or millions of requests/jobs per day, adds up to a considerable amount of CPU time, i.e. to a considerable amount of electricity, i.e. to considerable electricity cost savings. [1]: https://groups.google.com/g/v8-users/c/MUq5WrC2kcE https://groups.google.com/g/v8-users/c/MUq5WrC2kcE
- bsder 3y agoFLAC level 5 encode times should be WAY longer than decode times. FLAC level 0 to FLAC level 5 is a huge step up and encoding should be way longer (like factor of 3). Under no circumstances should FLAC level 5 decode be faster than FLAC level 0 decode. These are basic sanity checks. Something is wrong in the benchmark.
- HakanAbbas 3y agoI was very surprised to this situation, but Flac Level 5 (Default mode) results gave quick results in all my tests. I've tried this hundreds of times. You can try it with any converter and see it. I think much more improvements have been made on this mode.
- RaisingSpear 3y ago> Under no circumstances should FLAC level 5 decode be faster than FLAC level 0 decode. I don't know about FLAC, but from my knowledge of compression, this result seems sensible to me. Smaller file = less bits to process = faster. FLAC level 5 is expected to give a smaller file than level 0, so it makes sense that decoding it will be faster. Of course, it's possible that some codecs enable more codec features at higher compression levels, which makes decoding slower, so it's not always a given, but higher compression giving faster decode doesn't seem unreasonable.
- userbinator 3y agoIMHO that's still a "so what?". I see audio compression as having two primary purposes: realtime and archival, and speed is only vaguely relevant for the former. In realtime applications, any processor within the last decade is far more than powerful enough to encode and decode in realtime. The first set of tracks in the results is 2862s long and even the slowest WAVPACK manages to encode it in >113x realtime and close to 250x realtime for decode. For archival, high compression is important, but this codec doesn't compress better than WAVPACK either.
- sgbeal 3y ago> IMHO that's still a "so what?" This is addressed in another response in this same thread regarding electricity usage.
- HakanAbbas 3y agoI am still at the beginning of the road in terms of compression rate and speed. There may be changes in subsequent versions.
- deleted 3y ago[deleted]