Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FLAC 1.3.4

xiph.org

Post reply on HN
Print view View original

51–60 of 165 posts

Re: FLAC 1.3.4

#51

Post by sprash »

out_of_protocol wrote: post #46
sprash wrote: post #35

Earlier quoted context omitted.

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

Since the decoder complexity of flac is much lower than that of opus LossyWAV easily wins this competition at 300 kbps. I just wonder what the compression artifacts with LossyWAV would sound like if you push the bitrate down further (like e.g. 128 kbps). Sadly the command line tool does not allow that.

Re: FLAC 1.3.4

#52

Post by astrange »

namibj wrote: post #44
adastra22 wrote: post #40

Earlier quoted context omitted.

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

That's psy-rd (in x264 terms).

Trellis quantization is just a more optimal way to divide numbers - think of it like rounding to nearest instead of down. "optimal" means "optimal rate-distortion tradeoff" and "distortion" means whatever you want it to, but usually it's difference between original and compressed pixels (absolute error/SAD/PSNR).

That can look blurry, because given all alternatives with the same SAD, blurry ones compress more. So psy-rd changes the definition of distortion to add a "has similar amount of noise" factor. That's very far from human optimal (if anything it's SSIM optimal) but it's free detail. Uses the same quantization to get there, though.

Re: FLAC 1.3.4

#53

Post by kevin_thibedeau »

ksec wrote: post #30
corysama wrote: 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…

> It is an engineering marvel There are lots lossless audio compression. Each with different set of priorities and trade offs. From Compression Ratio, Decoding and Encoding Speed etc. I agree FLAC is a very good codec, especially for consumers. But I am not entirely sure it is a "marvel". Arguably WavePack does somethings better, especially when doing it patent free. ( Sort of irrelevant now at this point in time ) T…

Gotta give the audiophools lossless so they can listen over compressed Bluetooth audio.

Re: FLAC 1.3.4

#54

Post by kevin_thibedeau »

chungy wrote: post #24
corysama wrote: post #17

Earlier quoted context omitted.

.wav files are really just https://en.m.wikipedia.org/wiki/Resource_Interchange_File_Fo... It’s trivial to put a metadata chunk into that. And, trivial to ignore or blindly carry it along if your software doesn’t specifically support it.

It's that last statement that makes it completely impractical. There isn't even a de facto standard for metadata with wav files. Most players/software don't even bother at all. FLAC pretty firmly settled on the ogginfo format and literally everything that supports FLACs use that same metadata format.

Good luck getting VLC to read an embedded cue sheet for track locations.

Re: FLAC 1.3.4

#55

Post by magicalhippo »

dale_glass wrote: post #39
magicalhippo wrote: post #25

Earlier quoted context omitted.

What are the use-cases for pre-baked positional audio? Ie where the client can't do the positional audio processing itself.

Not pre-baked. I work on https://vircadia.com/ -- it has to give every user their own audio mix to account for their 3D position. This means codec costs add up fast. You can't just encode once and stream the same thing to a dozen people.

Oh right, I read that wrong. Thought you did per-voice 3D positional encoding on server but mixing on client.

Interesting use-case, got my brain racing off to find silly solutions.

Re: FLAC 1.3.4

#56

Post by corysama »

hulitu wrote: post #8
corysama wrote: 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…

There is also other storage like memory cards for cars or portable players.

…which is more expensive than $65 for 4TB. Thus, the question is framed around price.

Re: FLAC 1.3.4

#57

Post by astrange »

dale_glass wrote: post #38
boolemancer wrote: post #36

Earlier quoted context omitted.

By "fast to encode" do you mean that in terms of low latency or low CPU usage? I ask because I know Opus is used quite commonly in real-time applications (e.g. voip), and I remember when researching in the past that it is actually capable of lower inherent latency because of support for smaller frame sizes than some of its competition. I haven't looked into how expensive it is to encode in terms of CPU time, so I ass…

Both, primarily the first. Low latency is definitely a requirement, but no issues with Opus on that account. > I haven't looked into how expensive it is to encode in terms of CPU time, so I assume maybe you're taking about a bottleneck in terms of the number of simultaneous streams you can support on a single CPU? Yup! I work on https://vircadia.com/ -- we have to compress audio in real time and every user gets their…

There's no way their proprietary codec is less black magic than Opus is. I've rarely if ever seen a closed source codec designed by people who really know what they're doing; they're usually just whatever the cowboy they hired thought would be cool. It's not like management is going to be able to tell if it's state of the art or not.

Re: FLAC 1.3.4

#58

Post by Dylan16807 »

erdewit wrote: post #50
adastra22 wrote: post #40

Earlier quoted context omitted.

> 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 no…

Doesn't 16 bit audio already require dithering to capture the full audible dynamic range? That makes me worry somewhat about cutting more bits and layering dithers on dithers.

Re: FLAC 1.3.4

#59

Post by astrange »

bayindirh wrote: post #41
corysama wrote: 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…

Who says your filesystem isn't compressing data under you? Actually, who says the disk itself isn't?

(Sometimes they both are.)

Re: FLAC 1.3.4

#60

Post by astrange »

corysama wrote: post #48
bayindirh wrote: post #41

Earlier quoted context omitted.

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

FLAC isn't an unmaintainable "engineering marvel", the algorithm is pretty simple and all the data is checksummed. That's enough to make it a better archival format than WAV.
Post reply on HN