Hacker News Reader

Comment by masklinn | Hacker News Reader

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.

View on HN

> 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

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

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.

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.

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.

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

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.

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.

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

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.

It could be useful for audio editors like here: 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?

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

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

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

Reply on news.ycombinator.com