3 ms·

>It's a minimum of 3x faster than its contemporaries. Ok, but what would make that useful?

by prvc 3y ago

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 ago
  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.
  - 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
    - prvc 3y ago
      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.
      - sgbeal 3y ago
        > ... 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.
      - HakanAbbas 3y ago
        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.
        prvc 3y ago
        >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?
        HakanAbbas 3y ago
        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.
adzm 3y ago
Lower latency for real time streaming over the Internet, for one
- jstsch 3y ago
  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.

>It's a minimum of 3x faster than its contemporaries. Ok, but what would make that useful?

by prvc 3y ago

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

prvc 3y ago
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.
- 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
  - prvc 3y ago
    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.
    - sgbeal 3y ago
      > ... 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.
    - HakanAbbas 3y ago
      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.
      - prvc 3y ago
        >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?
        HakanAbbas 3y ago
        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.

adzm 3y ago

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

jstsch 3y ago
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.