Live data from Hacker News

FLAC 1.3.4

xiph.org

41–50 of 165 posts

Re: FLAC 1.3.4

#41
post #2

How cheap does storage have to get before people stop bothering to use FLAC? By my calculations, $65 will buy you a 4TB hard drive which can hold over 6,000 hours of uncompressed CD quality PCM. With FLAC you might squeeze 9,000-12,000 hours in. But, is that really worth the bother? I know it’s not obviously relevant to consumers, but an uncompressed PCM .wav file is a format that any high school coder can figure out…

> How cheap does storage have to get before people stop bothering to use FLAC?

Having cheap storage is not a valid reason to not to use that space efficiently.

With today's, even last decade's processors, encoding FLAC at ripping speed is not even a CPU saturating task, and decoding is merely a blip on processor's queue. If I can store the same bitstream on a smaller space, why shouldn't I?

If we're not compressing anything, why not forego lossless compression completely? Let's not GZ/XZ our log files. These 20MB files will become 30-40GB, but heck, a 4TB drive is just $65.

Similarly, let's not compress gigabytes, even terabytes of genomic data, scientific outputs and other stuff. They're just ASCII or Unicode strings, a high-schooler can figure these out. Why invest time in lossless compression tools like XZ and ZStd? They just use CPU cycles needlessly.

Re: FLAC 1.3.4

#42
post #2

How cheap does storage have to get before people stop bothering to use FLAC? By my calculations, $65 will buy you a 4TB hard drive which can hold over 6,000 hours of uncompressed CD quality PCM. With FLAC you might squeeze 9,000-12,000 hours in. But, is that really worth the bother? I know it’s not obviously relevant to consumers, but an uncompressed PCM .wav file is a format that any high school coder can figure out…

"complexity of FLAC"? As complex as gzipping a file Sounds like the people who are surprised at their end of month AWS bill because they couldn't bother to optimize anything.

Optimization is about trade offs. My career has been data processing pipelines for commercial game engines. I’m quite familiar with the trade offs of compressing all kinds of formats, including audio.

FLAC is at least as complex as OGG+gzip. That’s reasonable to deal with because there are libraries with many thousands of hours of effort put into them freely available.

But, trivial is trivial. Anyone who has had to deal with format support rot will sing praises of trivial.

My argument is that it’s a disappointing archive format given that any teenage coder can come within 30-50% of it in an afternoon by doing the most trivial thing possible.

Expectedly, few people here are arguing with me about archives. Instead we’re talking about streaming podcasts over 4G. Even for for high-end music, saying your personal bandwidth ethics/budget necessitates FLAC but not Opus seems more than a bit of a stretch, in my opinion.

Re: FLAC 1.3.4

#43
post #6

Earlier quoted context omitted.

I'm surprised to hear this perspective. I feel like FLAC is to PCM as PNG is to BMP. Why not just work with FLAC directly? Half the file size in exchange for negligible processing time. As a practical use case, FLAC is the only way I can fit my song library on my phone. Flagship phones today come with 128GB of storage, about 90GB is actually usable. Every additional 128GB is $100 more.

>Flagship phones today come with 128GB of storage IMO, one of the biggest scams in the mobile space currently. My old OnePlus 3T flagship from 2016 came with 128GB of storage and it "only" cost €480. Also, best phone I ever owned by far BTW. Today, nearly 6 years later, Apple and Samsung flagships (I'm staying away from OnePlus nowadays) are charging huge markups for more than the base 128GB of storage, on phones tha…

This’ll be because since 2016 it’s now expected you’ll stream more media than you’ll did back then, so not much much storage needed.

Re: FLAC 1.3.4

#44
post #16

Shoutout to LossyWAV (formerly LossyFLAC) [1]. It's a preprocessor to lossless codecs shaping noise such that higher compression ratios can me reached. It works out much better than that sounds like. 1. https://wiki.hydrogenaud.io/index.php?title=LossyWAV

> It's a preprocessor to lossless codecs shaping noise... So it's a lossy compression? Why use FLAC then?

Sounds more like trellis quantization in near-lossless H.264, explicitly trading coding cost of details against psychovisual impact of said details.

Re: FLAC 1.3.4

#45
post #16

Shoutout to LossyWAV (formerly LossyFLAC) [1]. It's a preprocessor to lossless codecs shaping noise such that higher compression ratios can me reached. It works out much better than that sounds like. 1. https://wiki.hydrogenaud.io/index.php?title=LossyWAV

> It's a preprocessor to lossless codecs shaping noise... So it's a lossy compression? Why use FLAC then?

It's just a hobby project, and the structure isn't too different from how other lossy codecs work. (Or lossless ones - you can construct one of those from any lossy one just by sticking the difference from the original on the end.)

Most codecs sacrifice transparency to reach a bitrate and this one does the opposite.

Re: FLAC 1.3.4

#46
post #35
post #16

Shoutout to LossyWAV (formerly LossyFLAC) [1]. It's a preprocessor to lossless codecs shaping noise such that higher compression ratios can me reached. It works out much better than that sounds like. 1. https://wiki.hydrogenaud.io/index.php?title=LossyWAV

This reduces the bitrate by about 3 times. Even at the lowest bitrate at about 300 kbps I can't even hear the slightest difference to the original. Impressive, but I wonder what it would sound like when you reduce the bitrate even further. Would it be competitive with mp3?

This at 300kbps vs opus 300kbps? mp3 is not a good comparison target

Re: FLAC 1.3.4

#47

Earlier quoted context omitted.

> How cheap does storage have to get before people stop bothering to use FLAC? It's not about the storage, it's about the transfer. Streaming services are only just beginning to support lossless at all. Improved lossy codecs like Opus provide indistinguishable-from-lossless audio at 128Kb/s, so the formula is store the audio losslessly, then transcode it to lossy (on the fly, even) for streaming.

I found an use for lossless streaming: A weakness in the open source landscape I found is that there's a lack of fast codecs. If you want to encode in real time (eg, streaming speech or an artist playing in the moment), and encode per client for positional audio in a 3D world, then Opus becomes a bottleneck. FLAC according to some preliminary tests helps by being faster than Opus to encode.

Both FLAC and Opus[0][1] have a dial to trade efficiency against CPU time. Have you even tried? I doubt FLAC remains a superior choice at low-complexity Opus settings. The library also has a complexity setting for the encoder.

[0] https://opus-codec.org/docs/opus-tools/opusenc.html [1] > Set encoding computational complexity (0–10, default: 10). Zero gives the fastest encodes but lower quality, while 10 gives the highest quality but slower encoding.

Re: FLAC 1.3.4

#48
post #2

How cheap does storage have to get before people stop bothering to use FLAC? By my calculations, $65 will buy you a 4TB hard drive which can hold over 6,000 hours of uncompressed CD quality PCM. With FLAC you might squeeze 9,000-12,000 hours in. But, is that really worth the bother? I know it’s not obviously relevant to consumers, but an uncompressed PCM .wav file is a format that any high school coder can figure out…

> How cheap does storage have to get before people stop bothering to use FLAC? Having cheap storage is not a valid reason to not to use that space efficiently. With today's, even last decade's processors, encoding FLAC at ripping speed is not even a CPU saturating task, and decoding is merely a blip on processor's queue. If I can store the same bitstream on a smaller space, why shouldn't I? If we're not compressing a…

I’m not clear how you are jumping from “30% of a few hundred gigs is a bad complexity trade off” to “100000% of terabytes is worthless” :p

Thanks for at least arguing against the use case I argued for. Even if you were a bit hyperbolic.

I get that I’m being a cranky old engineer. As someone who has spent a couple decades optimizing and maintaining bespoke high performance file formats, the particular use case of FLAC as an archive format still seems like a bad complexity vs benefit trade.

I’d rather have something that’s trivial for any software to work with everywhere forever. I know FLAC feels like forever. But, so did a lot of dead formats I used to work with.

Re: FLAC 1.3.4

#49
post #2

How cheap does storage have to get before people stop bothering to use FLAC? By my calculations, $65 will buy you a 4TB hard drive which can hold over 6,000 hours of uncompressed CD quality PCM. With FLAC you might squeeze 9,000-12,000 hours in. But, is that really worth the bother? I know it’s not obviously relevant to consumers, but an uncompressed PCM .wav file is a format that any high school coder can figure out…

Most desktops nowadays use SSD and the price of 4Gb SSD converted to dollars is about $500 where I live while salaries are significantly lower than in the US. Why not to use FLAC given that decoding doesn't require too much processing power?

Re: FLAC 1.3.4

#50
post #16

Shoutout to LossyWAV (formerly LossyFLAC) [1]. It's a preprocessor to lossless codecs shaping noise such that higher compression ratios can me reached. It works out much better than that sounds like. 1. https://wiki.hydrogenaud.io/index.php?title=LossyWAV

> It's a preprocessor to lossless codecs shaping noise... So it's a lossy compression? Why use FLAC then?

Other lossy compression methods generally happen in the frequency domain and, depending on the type of music, can introduce audible distortions.

This preprocessor on the other hand throws away some of least significant bits to save data. This increases the quantization noise but has no other sort of artifacts. The quantization noise can be dithered to fall in the higher frequencies (noise shaping) and is generally not perceptible.

Post reply on HN