7 ms·

FLAC 1.5 Delivers Multi-Threaded Encoding

220 points by mikece 2y ago

masklinn 2y ago
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.
blurbleblurble 2y ago
Will this translate to low latency FLAC streaming?
- shawabawa3 2y ago
  probably not as FLAC is basically only useful for archival purposes for streaming you are better off with an optimised lossy codec
  - timcobb 2y ago
    why is that?
    - shawabawa3 2y ago
      the human ear just isn't good enough at processing sound to need lossless codecs a modern audio codec at 320kbps bitrate is more than good enough. Lossless is useful for recompressing stuff when new codecs come out or for different purposes without introducing artefacts, not really for listening (in before angry audiophiles attack me)
      - arp242 2y ago
        > a modern audio codec at 320kbps bitrate is more than good enough. MP3 V0 should already be, and is typically smaller. That said, it does depend on the quality of the encoder; back in the day a lot of MP3 encoders were not very good, even at high quality settings. These days LAME is the de-facto standard and it's pretty good, but maybe some others aren't(?)
        elabajaba 2y ago
        Hell, modern audio codecs (opus and AAC, but not the ffmpeg opus/AAC encoders) are transparent at ~160-192k. MP3 is a legacy codec these days, and generally needs ~30% more bitrate for similar quality.
      - 2y ago
jprjr_ 2y ago
The thing I'm excited about is decoding chained Ogg FLAC files. Some software wouldn't work correctly with FLAC-based Icecast streams if they used libFLAC/libFLAC++ for demuxing and decoding. Usually these streams mux into Ogg and send updated metadata by closing out the previous Ogg bitstream and starting a new one. If you were using libFLAC to demux and decode - when the stream updated, it would just hang forever. Apps would have to do their own Ogg demuxing and reset the decoder between streams. Chained Ogg FLAC allows having lossless internet radio streams with rich, in-band metadata instead of relying on out-of-band methods. So you could have in-band album art, artist info, links - anything you can cram into a Vorbis comment block.
- nullify88 2y ago
  Are there any public lossless radio streams out there?
  - longitudinal93 2y ago
    You can filter by "flac" on radio-browser: https://www.radio-browser.info/search?page=1&order=clickcount&reverse=true&hidebroken=true&tagList=flac https://www.radio-browser.info/search?page=1&order=clickcoun...
- BoingBoomTschak 2y ago
  Massive waste to use FLAC for Internet streaming, though. Opus was made for this purpose (in part).
  - deleted 2y ago
    [deleted]
  - nullc 2y ago
    HTTP streaming is pretty much inherently high latency, or at least none of the software stack is particularly agreeable. I don't think it's fair to say that Opus was made for that purpose in any way that any other general purpose audio codec wasn't. (or even... vorbis really was made for that purpose, though sure you're better off using opus for it). Lossless audio is unconditionally transparent-- you won't have coding artifacts, you won't have issues with the codec accidentally increasing the crest factor of the audio and creating clipping where there wasn't. If you have the bandwidth for it, why not? So many people are using streaming in lieu of radio-- a true broadcast medium. I think any high ground to argue efficiency was lost at that point. :) making the streams use 10x the bandwidth? meh. Maybe convincing video sites to provide an option to turn off the video would be a better use of complaint energy: it impacts more people than lossless streaming and wastes a lot more bandwidth :)
jiehong 2y ago
Interestingly, FLAC is now published as RFC 9639 [0]. [0]: https://www.rfc-editor.org/rfc/rfc9639.html https://www.rfc-editor.org/rfc/rfc9639.html
lazka 2y ago
On Windows (so libwinpthread), 8C/16T machine: $ flac --version flac 1.5.0 $ hyperfine -r5 "flac -f -8 a.wav a.flac" "flac -j16 -f -8 a.wav a.flac" Benchmark 1: flac -f -8 a.wav a.flac Time (mean ± σ): 13.148 s ± 0.194 s [User: 12.758 s, System: 0.361 s] Range (min … max): 12.934 s … 13.318 s 5 runs Benchmark 2: flac -j16 -f -8 a.wav a.flac Time (mean ± σ): 2.404 s ± 0.012 s [User: 14.126 s, System: 1.355 s] Range (min … max): 2.395 s … 2.425 s 5 runs Summary flac -j16 -f -8 a.wav a.flac ran 5.47 ± 0.09 times faster than flac -f -8 a.wav a.flac

220 points by mikece 2y ago

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.

blurbleblurble 2y ago

Will this translate to low latency FLAC streaming?

shawabawa3 2y ago
probably not as FLAC is basically only useful for archival purposes for streaming you are better off with an optimised lossy codec
- timcobb 2y ago
  why is that?
  - shawabawa3 2y ago
    the human ear just isn't good enough at processing sound to need lossless codecs a modern audio codec at 320kbps bitrate is more than good enough. Lossless is useful for recompressing stuff when new codecs come out or for different purposes without introducing artefacts, not really for listening (in before angry audiophiles attack me)
    - arp242 2y ago
      > a modern audio codec at 320kbps bitrate is more than good enough. MP3 V0 should already be, and is typically smaller. That said, it does depend on the quality of the encoder; back in the day a lot of MP3 encoders were not very good, even at high quality settings. These days LAME is the de-facto standard and it's pretty good, but maybe some others aren't(?)
      - elabajaba 2y ago
        Hell, modern audio codecs (opus and AAC, but not the ffmpeg opus/AAC encoders) are transparent at ~160-192k. MP3 is a legacy codec these days, and generally needs ~30% more bitrate for similar quality.
    - 2y ago

jprjr_ 2y ago

The thing I'm excited about is decoding chained Ogg FLAC files. Some software wouldn't work correctly with FLAC-based Icecast streams if they used libFLAC/libFLAC++ for demuxing and decoding. Usually these streams mux into Ogg and send updated metadata by closing out the previous Ogg bitstream and starting a new one. If you were using libFLAC to demux and decode - when the stream updated, it would just hang forever. Apps would have to do their own Ogg demuxing and reset the decoder between streams. Chained Ogg FLAC allows having lossless internet radio streams with rich, in-band metadata instead of relying on out-of-band methods. So you could have in-band album art, artist info, links - anything you can cram into a Vorbis comment block.

nullify88 2y ago
Are there any public lossless radio streams out there?
- longitudinal93 2y ago
  You can filter by "flac" on radio-browser: https://www.radio-browser.info/search?page=1&order=clickcount&reverse=true&hidebroken=true&tagList=flac https://www.radio-browser.info/search?page=1&order=clickcoun...
BoingBoomTschak 2y ago
Massive waste to use FLAC for Internet streaming, though. Opus was made for this purpose (in part).
- deleted 2y ago
  [deleted]
- nullc 2y ago
  HTTP streaming is pretty much inherently high latency, or at least none of the software stack is particularly agreeable. I don't think it's fair to say that Opus was made for that purpose in any way that any other general purpose audio codec wasn't. (or even... vorbis really was made for that purpose, though sure you're better off using opus for it). Lossless audio is unconditionally transparent-- you won't have coding artifacts, you won't have issues with the codec accidentally increasing the crest factor of the audio and creating clipping where there wasn't. If you have the bandwidth for it, why not? So many people are using streaming in lieu of radio-- a true broadcast medium. I think any high ground to argue efficiency was lost at that point. :) making the streams use 10x the bandwidth? meh. Maybe convincing video sites to provide an option to turn off the video would be a better use of complaint energy: it impacts more people than lossless streaming and wastes a lot more bandwidth :)

jiehong 2y ago

Interestingly, FLAC is now published as RFC 9639 [0]. [0]: https://www.rfc-editor.org/rfc/rfc9639.html https://www.rfc-editor.org/rfc/rfc9639.html

lazka 2y ago

On Windows (so libwinpthread), 8C/16T machine: $ flac --version flac 1.5.0 $ hyperfine -r5 "flac -f -8 a.wav a.flac" "flac -j16 -f -8 a.wav a.flac" Benchmark 1: flac -f -8 a.wav a.flac Time (mean ± σ): 13.148 s ± 0.194 s [User: 12.758 s, System: 0.361 s] Range (min … max): 12.934 s … 13.318 s 5 runs Benchmark 2: flac -j16 -f -8 a.wav a.flac Time (mean ± σ): 2.404 s ± 0.012 s [User: 14.126 s, System: 1.355 s] Range (min … max): 2.395 s … 2.425 s 5 runs Summary flac -j16 -f -8 a.wav a.flac ran 5.47 ± 0.09 times faster than flac -f -8 a.wav a.flac