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

61–70 of 165 posts

Re: FLAC 1.3.4

#61

Post by raverbashing »

corysama wrote: post #42
raverbashing wrote: post #26

Earlier quoted context omitted.

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

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

Re: FLAC 1.3.4

#62

Post by dale_glass »

namibj wrote: post #47
dale_glass wrote: post #19

Earlier quoted context omitted.

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

I have tried it. It works, but the difference in my experience isn't a huge one.

Complexity 0 is about twice as fast as 10. Which isn't bad, but if you want to go really fast it still leaves something to be desired.

Re: FLAC 1.3.4

#63

Post by autoexec »

ChuckNorris89 wrote: post #15
lazyjeff wrote: 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 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 3rd parties to track what I'm listening to and how often or to push ads at me.

Re: FLAC 1.3.4

#64

Post by astrange »

LeoPanthera wrote: post #13
grumpyprole wrote: post #11

Earlier quoted context omitted.

What would make life simpler is the industry standardising on at least one format. For example Apple doesn't actually support FLAC, despite it being the most popular lossless format.

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.

All lossless codecs use only integer math or else they wouldn't be lossless due to hardware/compiler optimization rounding differences.

…is what I want to say, but IIRC Lagarith actually does use floating point so you have to emulate x87 to decode it.

Re: FLAC 1.3.4

#65

Post by bayindirh »

astrange wrote: post #59
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…

Who says your filesystem isn't compressing data under you? Actually, who says the disk itself isn't? (Sometimes they both are.)

> Who says your filesystem isn't compressing data under you?

Me, because we don't use transparent compression anywhere.

> Actually, who says the disk itself isn't?

I'm not very sure about that, to be honest. SSDs do that to prolong their life, but the saved space doesn't return as more space on FS level. It just returns as endurance, which is more important in my case.

So, disk's transparent compression doesn't mean very much from a sysadmin/OS operations perspective.

Re: FLAC 1.3.4

#66

Post by astrange »

raverbashing wrote: post #61
corysama wrote: post #42

Earlier quoted context omitted.

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

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.

Re: FLAC 1.3.4

#67

Post by joveian »

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.

There does seem to be at least some de facto standard, at least checking my collection for stuff I haven't converted to flac yet I found the Wingspan soundtrack in wav format with, according to kid3, an ID3v2.3.0 tag (including cover art) and RIFF info. It works with mpv and VLC, I didn't try anything else (well, I tried a couple of command line id3 utilities that didn't show the tags). I've seen tagged wav files a few other places as well so it doesn't seem super uncommon. However, checking quick it doesn't seem like flac notices the tags when converting.

Re: FLAC 1.3.4

#68

Post by Dylan16807 »

corysama wrote: post #42
raverbashing wrote: post #26

Earlier quoted context omitted.

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

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

Anyone who has had to deal with finding and recovering old data should appreciate the ability to fit significantly more on a disk. More redundancy and cheaper storage means more data survives.

> teenage coder [...] in an afternoon

Finding a FLAC decoder is very unlikely to take longer than that, even 50 years from now.

Re: FLAC 1.3.4

#69

Post by autoexec »

grumpyprole wrote: post #28
LeoPanthera wrote: post #13

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

> Apple Music and iOS still do not play FLAC, which is one significant reason why I won't buy an iPhone.

You can't just install VLC on an iphone?

Re: FLAC 1.3.4

#70

Post by out_of_protocol »

sprash wrote: post #51
out_of_protocol wrote: post #46

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.

Would be interesting. Unlikely to work out though. On other note, opus 128 kbps is transparent (in my tests i can distinguish 100kbps files at most), with safety margin 256 kbps should be enough for all practical purposes (except archiving).

There are other worser codecs around, e.g. LDAC (best Bluetooth codec) 660kbps vs 990kbps is very noticable (cant setup the same way to compare 990kbps LDAC vs 128kbps opus)

Post reply on HN