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.
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.
Indeed, getting an accurate answer would require looking at the whole constellation for a given use case.
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.
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?
Flac is already existing. There are also a lot of workers on it. I always want to try independent and different things.
Also your link doesn't explain what they changed?
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(...);
void foo(..., v8::Value &result);
PS: i wasn't aware that source code for this codec is not available. That of course puts a damper on it.
Yes, but not every tradeoff between compression speed and compression ratio is something that makes sense to scale in the first place.