Live data from Hacker News

FLAC 1.3.4

xiph.org

71–80 of 165 posts

Re: FLAC 1.3.4

#71
post #51

Earlier quoted context omitted.

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.

What are you doing with it that opus decoding complexity is any kind of barrier?

Re: FLAC 1.3.4

#72

Earlier quoted context omitted.

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.

Well, I say "black magic" because at least to me it's a quite mysterious creation. But I'm no audio engineer.

It's a lossy codec that's for some reason fixed rate, and shrinks audio by exactly 1/4th. The resulting quality is very good (works perfectly fine for music), and it's much faster than Opus. It retains stereo and high frequencies and sounds just fine. I'm sure there's a tradeoff somewhere, but it's certainly good enough to hold music events without people complaining.

I think it might be possibly related to codecs like AptX.

So far I've not found anything competitive that we could use -- stuff is either closed, or far more CPU intensive.

Re: FLAC 1.3.4

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

Funny how a 200€ Xiaomi phone has 256 GB of storage these days. No idea though if that is fake HDD somehow.

Re: FLAC 1.3.4

#74

Earlier quoted context omitted.

I see If your point is that most users of FLAC would be happier with AAC/Opus etc I agree (and with a more significant savings) And yeah if you're looking at longer archival times, PCM probably makes more sense. But I think FLAC suffers way less rot than, for example WMA

FLAC bitrots less than WAV, because WAV doesn't have checksums.

If you're concerned about bitrot (and I feel everyone should be), you're going to checksum at the filesystem level, so it doesn't make a difference

Re: FLAC 1.3.4

#75
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

Reminds me of https://pngquant.org/

Same concept just for making images more efficient for PNG

Re: FLAC 1.3.4

#76

Earlier quoted context omitted.

>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 is beyond insulting, especially since modern flagships also lack microSD expansion. They'll do everything they can to push people into using their cloud services. It erodes the concept of ownership when you have to ask for permission from another party to access your own stuff. The more dependent they can make you on them the better. Plus when I listen to an MP3 stored on my phone, there's no opportunity for 3…

Nothing about downloading an MP3 that says they can't put a targeted ad in it; there's podcasts that do that based on your IP. I assume the reason most don't is just how much more trustworthy it sounds when the host reads an ad script live in the episode.

(I swear there was an episode of The Weeds where they read an ad for a therapy service for dogs.)

Re: FLAC 1.3.4

#77

Earlier quoted context omitted.

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.

Checksumming isn't enough to make something a good archival format. You need to go beyond being able to detect data corruption to being able to correct or cope with data corruption. For a FLAC file, if you flip a bit in the file, then the checksum will detect that the file has been corrupted, but that chunk of the file will be unrecoverable. If you flip a bit in PCM data, likely you won't even hear the difference. If you want to know whether corruption has occurred, you can always run md5sum on it. For FLAC, if you want to be able to cope with data corruption, you'll need to create something like par2 recovery data.

Re: FLAC 1.3.4

#78
post #30

Earlier quoted context omitted.

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

LOL I didn't write that part since HN has a long and what I think is pointless argument last time we discussed bluetooth and audio.

Re: FLAC 1.3.4

#79

Earlier quoted context omitted.

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.

Well, I say "black magic" because at least to me it's a quite mysterious creation. But I'm no audio engineer. It's a lossy codec that's for some reason fixed rate, and shrinks audio by exactly 1/4th. The resulting quality is very good (works perfectly fine for music), and it's much faster than Opus. It retains stereo and high frequencies and sounds just fine. I'm sure there's a tradeoff somewhere, but it's certainly…

Yeah, it sounds like ADPCM with a fixed ratio like that. It's extremely simple and adds no latency, which are both good for streaming.

Usually a fixed compression ratio is a terrible tradeoff, but for streaming it kind-of makes sense.

Re: FLAC 1.3.4

#80

Earlier quoted context omitted.

Core Audio added support for FLAC in High Sierra, macOS 10.13, in 2017. Apple has supported "ALAC" for longer, which unlike FLAC uses only integer math and is therefore less power hungry on mobile devices. You can transcode losslessly between FLAC and ALAC.

The FLAC decoder has been almost completely integer for a long time (and may now be completely so). Apple Music and iOS still do not play FLAC, which is one significant reason why I won't buy an iPhone. Transcoding my entire music library certainly isn't "just works".

iOS supports FLAC, you can play it in Safari and the Files app. It's true you can't add it to the Music app, but you can use another app.

Also, the $9 Apple headphone dongle is objectively superior to most audiophile DACs, which isn't surprising since it has a larger R&D budget than that entire industry. (Same goes for Google's IIRC.)

Post reply on HN