IMHO 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.

I am still at the beginning of the road in terms of compression rate and speed. There may be changes in subsequent versions.

> IMHO that's still a "so what?"

This is addressed in another response in this same thread regarding electricity usage.

It 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.

Qobuz also offers flac downloads for albums, but also linnrecords does that.

A yawn? Is there any alternative that even has 10% of the mindshare of FLAC?

Just that providers of flac are few and far between. The only reliable source of flac files are those you make yourself.

Found the Apple user.

Why would an Apple user be using flac?

I must've misread the last part of the post. My bad.

According to the author, right? Those results aren't backed up by Porcus's comments in that thread.

Maybe not x3-5, but Porcus confirms that it is still very fast:

> Though it is fast indeed! The decoding speeds are outright impressive given how FLAC is the fastest thing we ever saw ...

Yes, but thise "very fast" speeds are marginally faster than flac.

>It's a minimum of 3x faster than its contemporaries.

Ok, but what would make that useful?

> 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.

Yes, 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.

> ... 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

Nobody is going to use this at Google scale without source code! However knowing that something exists elsewhere can push somebody to re-invent it locally.

Yes, but this must be weighed against increased storage costs, not to mention the computational cost of transcoding (and others to do with the proliferation of formats). Within the parameters of this application and taking into account the relative costs of compute and storage (in money or energy), it is not clear to me that there would be any advantage to switching.

> ... it is not clear to me that there would be any advantage to switching.

Indeed, getting an accurate answer would require looking at the whole constellation for a given use case.

The compression rate in audio compression is really limited. In most cases it is difficult to decrease below 50 percent.

Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs. As a result, high processing times are high energy.

>Therefore, it is not a logical choice to increase the process rate in order to provide a few percent more compression between audio codecs.

Why not? And for what applications? Example: for a media streaming service, where each file is transferred many times, the bandwidth costs dominate, so it is worthwhile to spend a great deal of time on encoding to maximize efficiency. In the case of an archive, where a large amount of information is stored, accessed infrequently, storage space becomes the constraint, once again. In general, 1 marginal second of CPU time is usually cheaper than 10Mib of marginal storage (or whatever the figure works out to be). Finally, why not just write a fast FLAC encoder?

The only reason Flac is the most popular sound code is that both compression and code -solving is faster than others. The same applies to many formats such as JPEG, MP4, MP3, Rar, Zstandart. What is fast is always advantageous and is a reason for preference. Even if they are not free. As you mentioned, of course, it does not apply to every situation.

Flac is already existing. There are also a lot of workers on it. I always want to try independent and different things.

Saving a small fraction of a second millions of times over, or a handful of cycles a trillion times over, is so much more impactful than saving a dozen seconds per hour-long recording.

Also your link doesn't explain what they changed?

> Saving a small fraction of a second millions of times over, or a handful of cycles a trillion times over, is so much more impactful than saving a dozen seconds per hour-long recording.

At a large-enough scale, all savings are significant.

> Also your link doesn't explain what they changed?

They changed a function signature to use an output argument instead of a return value. i don't recall the exact signature, but it was conceptually like:

    v8::Value foo(...);

to

    void foo(..., v8::Value &result);

Why? Because their measurements showed a microscopic per-call savings for the latter construct.

PS: i wasn't aware that source code for this codec is not available. That of course puts a damper on it.

> At a large-enough scale, all savings are significant.

Yes, but not every tradeoff between compression speed and compression ratio is something that makes sense to scale in the first place.

Lower latency for real time streaming over the Internet, for one

Whilst faster decoding is always useful, most audio decoding can easily happen within the typical output buffer size (e.g. 512 samples at 44.1KHz ~ 12ms). As long as your machine can decode within that timeframe, there is no difference in latency.

FLAC 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.

I 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.

> 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.