8 ms·

That’s nice although probably not of much use to most people: iirc FLAC encoding was 60+x realtime on modern machines already so unless you need to transcode yo

That’s nice although probably not of much use to most people: iirc FLAC encoding was 60+x realtime on modern machines already so unless you need to transcode your entire library (which you could do in parallel anyway) odds are you spend more time on setting up the encoding than actually running it.

flounder3 2y ago
Was about to say the same thing. It was already blazingly fast, with a typical album only taking seconds.
diggan 2y ago
> That’s nice although probably not of much use to most people Doesn't that depend on the hardware of "most people"? Even if you have a shit CPU, you probably have at least more than 1 core, so this will be at least little bit helpful for those people, wouldn't it? Edit: Just tried turning a ~5 minute .wav into .flac (without multithreading) on a Intel Celeron N4505 (worst CPU I have running atm) and took around 20 seconds, FWIW
- _flux 2y ago
  But even a smaller number of people have individual very long raw audio files. I've converted a bunch of sound packs (for music production) to flac and it really takes next to no time at all. I suppose those are quite short audio files, but there's a lot of them, 20 gigabytes in total (in flac). Perhaps the person who wrote this improvement did have a use case for it, though :).
- johncolanduoni 2y ago
  In most situations you’d be encoding more than one song at a time, which would already parallelize enough unless you had a monster cpu and only one album.
  - diggan 2y ago
    I dunno, when I export a song I'm working on, it's just that one song. I think there are more use cases for .flac than just converting a big existing music collection.
- stonemetal12 2y ago
  FLAC is more than 20 years old at this point. At least according to wikipedia it doesn't look like they haven't changed the algorithm to much in the mean time, so just about anything should be able to run it today.
- masklinn 2y ago
  > this will be at least little bit helpful for those people, wouldn't it Probably not, because they're unlikely to have enough stuff to export that it's relevant. > Edit: Just tried turning a ~5 minute .wav into .flac (without multithreading) on a Intel Celeron N4505 (worst CPU I have running atm) and took around 20 seconds, FWIW Which is basically nothing. It takes more time than that to fix the track's tagging.
  - diggan 2y ago
    I mean, you're again assuming the only use case is "encode and tag a huge music collection", encoding is used for more than that. For example, I have a raspberry pi that is responsible for recording as soon as it powers up. Then I can press a button, and it grabs the last 60 recorded minutes, which happens to be saved as .wav right now, which I'm fine with, the rest of my pipeline works with .wav. But if my pipeline required flac, I would need to turn the wav into flac on the raspberry pi at this point, for 60 minutes of audio, and of course I'd like that to be faster if possible, so I can start editing it right away.
2OEH8eoCRo0 2y ago
Even still, it was no issue saturating all CPU cores since each core could transcode a track at a time.
dale_glass 2y ago
I have a possible use for FLAC for realtime audio. We (Overte, an open source VR environment) have a need for fast audio encoding, and sometimes audio encoding CPU time is the main bottleneck. For this purpose we support multiple codecs, and FLAC is actually of interest because it turns out that the niche of "compressing audio really fast but still in good quality" is a rare one. We maingly use Opus which is great, but it's fairly CPU heavy, so there can be cases when one might want to sacrifice some bandwidth in exchange for less CPU time.
dijital 2y ago
For folks working in bioacoustics I think it might be pretty relevant. I'm working on a project with large batches of high fidelity, ultrasonic bioacoustic recordings that need to be in WAV format for species analysis but, at the data sizes involved, FLAC is a good archive format (~60% smaller). This release will probably be worth a look to speed the archiving/restoring jobs up.
Lockal 2y ago
It could be useful for audio editors like here: https://manual.audacityteam.org/man/undo_redo_and_history.html https://manual.audacityteam.org/man/undo_redo_and_history.ht... - many steps require full save of tracks (potentially dozens of them). It is possible to compress history retrospectively, but why, if we can be done in parallel?
- CyberDildonics 2y ago
  If you have multiple tracks you would just put different tracks on different threads anyway and parallelization is trivial.
Doohickey-d 2y ago
There's also a usecase of using flac for non-audio data: anything that looks like a waveform compresses quite well. e.g. analog signals, data logging, etc. One example is https://github.com/oyvindln/vhs-decode https://github.com/oyvindln/vhs-decode - capturing high-bandwidth signals directly from analog tape with SDR-like hardware, for later software demodulation. Those waveform signals compress quite well with flac. Currently there's flacCL, which compresses on the GPU, so this is one more option.

flounder3 2y ago

Was about to say the same thing. It was already blazingly fast, with a typical album only taking seconds.

diggan 2y ago

> That’s nice although probably not of much use to most people Doesn't that depend on the hardware of "most people"? Even if you have a shit CPU, you probably have at least more than 1 core, so this will be at least little bit helpful for those people, wouldn't it? Edit: Just tried turning a ~5 minute .wav into .flac (without multithreading) on a Intel Celeron N4505 (worst CPU I have running atm) and took around 20 seconds, FWIW

_flux 2y ago
But even a smaller number of people have individual very long raw audio files. I've converted a bunch of sound packs (for music production) to flac and it really takes next to no time at all. I suppose those are quite short audio files, but there's a lot of them, 20 gigabytes in total (in flac). Perhaps the person who wrote this improvement did have a use case for it, though :).
johncolanduoni 2y ago
In most situations you’d be encoding more than one song at a time, which would already parallelize enough unless you had a monster cpu and only one album.
- diggan 2y ago
  I dunno, when I export a song I'm working on, it's just that one song. I think there are more use cases for .flac than just converting a big existing music collection.
stonemetal12 2y ago
FLAC is more than 20 years old at this point. At least according to wikipedia it doesn't look like they haven't changed the algorithm to much in the mean time, so just about anything should be able to run it today.
masklinn 2y ago
> this will be at least little bit helpful for those people, wouldn't it Probably not, because they're unlikely to have enough stuff to export that it's relevant. > Edit: Just tried turning a ~5 minute .wav into .flac (without multithreading) on a Intel Celeron N4505 (worst CPU I have running atm) and took around 20 seconds, FWIW Which is basically nothing. It takes more time than that to fix the track's tagging.
- diggan 2y ago
  I mean, you're again assuming the only use case is "encode and tag a huge music collection", encoding is used for more than that. For example, I have a raspberry pi that is responsible for recording as soon as it powers up. Then I can press a button, and it grabs the last 60 recorded minutes, which happens to be saved as .wav right now, which I'm fine with, the rest of my pipeline works with .wav. But if my pipeline required flac, I would need to turn the wav into flac on the raspberry pi at this point, for 60 minutes of audio, and of course I'd like that to be faster if possible, so I can start editing it right away.

2OEH8eoCRo0 2y ago

Even still, it was no issue saturating all CPU cores since each core could transcode a track at a time.

dale_glass 2y ago

I have a possible use for FLAC for realtime audio. We (Overte, an open source VR environment) have a need for fast audio encoding, and sometimes audio encoding CPU time is the main bottleneck. For this purpose we support multiple codecs, and FLAC is actually of interest because it turns out that the niche of "compressing audio really fast but still in good quality" is a rare one. We maingly use Opus which is great, but it's fairly CPU heavy, so there can be cases when one might want to sacrifice some bandwidth in exchange for less CPU time.

dijital 2y ago

For folks working in bioacoustics I think it might be pretty relevant. I'm working on a project with large batches of high fidelity, ultrasonic bioacoustic recordings that need to be in WAV format for species analysis but, at the data sizes involved, FLAC is a good archive format (~60% smaller). This release will probably be worth a look to speed the archiving/restoring jobs up.

Lockal 2y ago

It could be useful for audio editors like here: https://manual.audacityteam.org/man/undo_redo_and_history.html https://manual.audacityteam.org/man/undo_redo_and_history.ht... - many steps require full save of tracks (potentially dozens of them). It is possible to compress history retrospectively, but why, if we can be done in parallel?

CyberDildonics 2y ago
If you have multiple tracks you would just put different tracks on different threads anyway and parallelization is trivial.

Doohickey-d 2y ago

There's also a usecase of using flac for non-audio data: anything that looks like a waveform compresses quite well. e.g. analog signals, data logging, etc. One example is https://github.com/oyvindln/vhs-decode https://github.com/oyvindln/vhs-decode - capturing high-bandwidth signals directly from analog tape with SDR-like hardware, for later software demodulation. Those waveform signals compress quite well with flac. Currently there's flacCL, which compresses on the GPU, so this is one more option.