Skip to main content ↑ ↓
Topic: Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons (Read 50967 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #50 –
@ Bryant:

Thanks for enlightening.

And well maybe this is the weirdest reason for using WavPack, but it probably illustrates my reasoning why this is a natural monopoly situation (well, Apple might create their own market though). For those 50 hours of music which I wanted to flag as 'do not play except in foobar2000' (that includes the DTS CD too), I picked my second choice – but my point is, being everyone's second choice, does not pay off in terms of market share. When it comes to sausages, it does, because you don't want to eat the same all the time. When it comes to a file format, it doesn't.

(Except in terms of respectful thumbs-up from geeks. I suppose there are quite a few people who think WavPack is cool, but don't use it. Including myself, until I fairly recently found a (laughable?) reason to ditch my single-format principle.)

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #51 –
Quote from: Dario on
I listen mostly to neofolk, and the results I get are quite different than the ones you do. Here’s the compression for the album “Forlatt” by Vàli […] do you know how much difference that is (tip: it’s over 20%)?
Quote from: Porcus on
Those figures of yours (wow ...) don't state uncompressed size. If you ripped from CD, then bitrate (per second) is probably a better figure to state, as the uncompressed is 1440.
1411 kbps, surely?

But yeah, it would be good to have more information, such as uncompressed size/bitrate and a sample. On which note:
Quote from: Dario on
If you don't believe me, I can upload the album so you can check it out yourself. I hope you wouldn’t mind.
Hydrogenaudio limits sharing of copyrighted material to samples for use in demonstration/identification, which can be a maximum of 30 seconds long, so please don’t link any full album or even song (at least not publicly).

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #53 –
Here’s a 30-second sample of the album I was talking about. I’ve no idea why it’s such an “exotic” case—but it is.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #54 –
Apparent lowpass at 13...14 kHz and other signs of lossy encoding.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #55 –
Quote from: skamp on
Well, I measured the difference on my music collection, which turns out to be 2.19% on average. Not quite as significant as I would have thought.


Correction: a 3.52% improvement of TAK over FLAC (derived from the TAK to FLAC ratio, not FLAC to WAV minus TAK to WAV). See the linked thread.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #56 –
The Vàli upload has a peak of only 0.82, and is from a lossy source. Edit: lvqcl beat me at the latter.

Code: [Select]
auCDtect: CD records authenticity detector, version 0.8.2
Copyright © 2004 Oleg Berngardt. All rights reserved.
Copyright © 2004 Alexander Djourik. All rights reserved.
------------------------------------------------------------
Processing file:	[V…li {2004} ~ Forlatt ~ 03 ~ Et ensomt minne.wav]
Detected average hi-boundary frequency: 1.933682e+004 Hz
Detected average lo-boundary frequency: 1.443311e+004 Hz
Detected average hi-cut frequency: 1.823435e+004 Hz
Detected average lo-cut frequency: 1.397679e+004 Hz
Maximum probablis boundary frequency: 2.153600e+004 Hz
Coefficient of nonlinearity of a phase: 9.019672e-002
First order smothness: 8.209877e-001
Second order smothness: 6.141975e-001

------------------------------------------------------------
This track looks like MPEG with probability 100%

------------------------------------------------------------
Final Conclusion:
------------------------------------------------------------
These tracks looks like MPEGs with probability 100%

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #57 –
Quote from: lvqcl on
Apparent lowpass at 13...14 kHz and other signs of lossy encoding.

http://i.imgur.com/tfEKB.png

Alright then. This is a demo recording, and while I can guarantee that it was ripped from an original copy (it’s also verified by AccurateRip), I’d no idea that it was sourced from lossy files, but I’m not surprised, because it is, as I said, a demo recording.

Thank you for the clarification.

On a side note, I have a bunch of other albums that I know to be lossily-mastered (all kinds of stuff happens in the “underground” scene…), and I just realized that I get pretty much the same results (over 15% difference in compression). The album I checked now was bought as WAV from here (but is mastered from lossy files). I guess that settles it. Thanks again.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #58 –
I am not surprised that a demo from a one-man-band is kept as .mp3 and then pressed to CD if someone offers to release it.

Earlier in the thread[{POST_SNAPBACK}][/a], TBeck warns against that comparison where his codec performed also outperformed FLAC by larger margin than usual, on the grounds of the test corpus which included lossy sources.

(That said, I am a bit fascinated by the fact that lossless encoders fail so miserably at packing mp3's back to anything near mp3 size. They are obviously very far from the [a href="http://en.wikipedia.org/wiki/Shannon_entropy#Data_compression]information content on those particular samples. Then on the other hand, there are good reasons why developers of lossless codecs/encoders do not bother to tune them to for efficiency on cases everyone advises against.)

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #59 –
Quote from: Porcus on
(That said, I am a bit fascinated by the fact that lossless encoders fail so miserably at packing mp3's back to anything near mp3 size. They are obviously very far from the information content on those particular samples. Then on the other hand, there are good reasons why developers of lossless codecs/encoders do not bother to tune them to for efficiency on cases everyone advises against.)
I?m probably oversimplifying (as is customary!), but I think it?s important here to distinguish between entropy/information as is in theory vs. as it is perceived. Lossy encoding adds noise, distortion, and other features that cannot be classed as information in the sense of something that has any use ? but this nonetheless is not something that can be used as a shortcut by a subsequent lossless encoder, which has no way of identifying that it arose in such a way and has no choice but to store it (in all its content-free glory).

Also (and as you implied), there?s little point in making lossless encoding better at representing something that has already been processed by a lossy codec. Transcoding is bad, m?mkay?

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #60 –
Half a year ago I took 7 albums from my music collection and encoded them to various lossless formats. Max. difference between FLAC -8 and TAK -p4 is 3.64%, min. difference is 2.43%, average is 3.15%.

Also, the whole test (44.1/16/stereo; CPU = Intel i7 950; no multithreading, no GPU encoding; ALAC: QT 7.7.0 libraries via qaac 0.85):

encoding speed vs. compression ratio:


decoding speed vs. compression ratio:

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #61 –
as far as longevity goes, i'd use whatever appears as a decoder in ffmpeg, seems to be:

Code: [Select]
 DEA D  alac            ALAC (Apple Lossless Audio Codec)
 D A D  als             MPEG-4 Audio Lossless Coding (ALS)
 D A D  ape             Monkey's Audio
 DEA D  flac            FLAC (Free Lossless Audio Codec)
 D A D  ralf            RealAudio Lossless
 D A D  tta             True Audio (TTA)
 D A D  wmalossless     Windows Media Audio Lossless
 D A D  wavpack         WavPack
ffmpeg version N-40617-g70e9308 Copyright © 2000-2012 the FFmpeg developers
  built on May 12 2012

(but do test first if decoding is ok)

p.s. also i would slightly prefer the ones starting with DEA.

p.s.2. full list http://pastebin.com/raw.php?i=e1aWDcDZ
(hopefully i haven't missed any)

p.s.3. not only longevity, this is also a voucher for decoding your audio on almost any platform.
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #62 –
Quote from: Porcus on
Earlier in the thread[a href="index.php?act=findpost&pid=800089"][{POST_SNAPBACK}][/a], TBeck warns against that comparison where his codec performed also outperformed FLAC by larger margin than usual, on the grounds of the test corpus which included lossy sources.

Since i have read several reports of commercial CDs containing probably lossy compressed audio, i think it's ok to have a few such files in a larger test corpus, but they should contribute only a bit to the sum results.

Quote from: db1989 on
Also (and as you implied), there’s little point in making lossless encoding better at representing something that has already been processed by a lossy codec. Transcoding is bad, m’mkay?

I don't think it's totally irrelevant if a codec can compress such files well. Files with very high sampling rates like 192 KHz also "appear" low passed because there is so little natural high frequency content. Accordingly TAK compresses them very well.

This is not always true for files converted from a DSD-source, where the conversion process seems to add a lot of high frequency noise.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #63 –
Quote from: TBeck on
This is not always true for files converted from a DSD-source, where the conversion process seems to add a lot of high frequency noise.

It's not the decoding - this is inherent to DSD, being a heavily noise-shaped 1-bit format. Results would be expected to vary depending on how fancy the noise shaper was.

How's TAK's handling of 24-bit files? FLAC doesn't compress these too well.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #64 –
I doubt that any lossless encoder would do well with 24 bits. Those 8 extra bits are essentially uncompressable, uncorrelated noise.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #65 –
Quote from: stephan_g on
How's TAK's handling of 24-bit files? FLAC doesn't compress these too well.


I suspect that compression of 24-bit PCM as well as higher sample rates could be improved in FLAC without any format-breaking changes.  The encoder is non-optimal in these scenarios.

I'd also be curious if improvements from FLAKE could be added, as well as more exhaustive coefficient calculation (or a more modern algorithm).  CPU speeds have gone up drastically since FLAC's encoder was developed.

That being said, it's never going to be able to beat TAK or other formats without making format-breaking changes.

As far as future-proofing, it would be nice to add floating-point support, particularly for "studio master" files or synthetically generated files.  It would have to be part of a newer format, and it might require someone to write a fixed-point version to be able maintain good platform support like FLAC has today.  But it's definitely the main thing "missing" today from FLAC.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #66 –
Does Josh ever still, or have any intention to ever again, work on FLAC? If not, does anyone else, and/or do projects such as FLAKE have many improvements besides speed? Improvements and additions such as those mentioned by benski sound great; I’m just wondering where they’re going to come from.

[edit]

I now recall seeing recent changelogs from Xiph, but checking these now suggests that almost all of the recent changes have amounted to little more than housekeeping, rather than changes to the format itself. So, I’m still curious.

Also, lvqcl: thanks for the very interesting graphs!

[/edit]

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #67 –
Quote from: lvqcl on
Half a year ago I took 7 albums from my music collection and encoded them to various lossless formats.


I assume that the points on the graph for FLAC are the compression levels 0 through 8. Am I reading it correctly, that the encoding speed at -6 is actually _faster_ than -5?

Edit: Actually, I think I'm reading it the wrong way 'round. It looks like compression levels 0 through 8 are plotted right to left. It's interesting that there's essentially zero difference between -5 and -6.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #68 –
Quote from: stephan_g on
How's TAK's handling of 24-bit files? FLAC doesn't compress these too well.

Quote from: benski on
I suspect that compression of 24-bit PCM as well as higher sample rates could be improved in FLAC without any format-breaking changes.  The encoder is non-optimal in these scenarios.

Really? It doesn't even properly handle 24bit? I have few albums in FLAC and 24bit, what do you mean by this?

Going back to the original question, not looking at the 1% better compression and not talking about TAK in every post, what doesn't True Audio have that other formats have? Again, reading the specs it seems the absolute best, please let me understand why I shouldn't convert and keep everything in True Audio.

Can anyone add TAK's details here? http://en.wikipedia.org/wiki/Comparison_of...chnical_details

Thanks.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #69 –
Quote from: pdq on
I doubt that any lossless encoder would do well with 24 bits. Those 8 extra bits are essentially uncompressable, uncorrelated noise.


I did a test after applying a de-emphasis EQ filter and writing the output to 24-bits. (Which means, there wasn't noise in those 8 extra bits until the EQ moved the original noise in there, so I suppose that filling up with noise from the beginning, would not benefit the figures?)  Then I took the FLAC file, reduced to 16 (without dithering) and measured the ratio.

With FLAC -8, the 16 bits filesize was only 52.1% of the size of the 24-bit file. Those extra 8 bits were fairly expensive.

I didn't compute the corresponding ratios for other codecs, but I converted the 24-bit file to other formats in order to see if there was any that would perform 'by eyeballing' unexpectedly better or worse. Nope:

7 761 846 272 bytes - flac -8
7 672 954 880 bytes - WavPack high, x5   
7 629 369 344 bytes - Monkey's extrahigh   
7 582 380 032 bytes - TAK -p4
7 533 199 360 bytes - ofr extranew   

The respective percentage improvements over flac -8:
1,1 %
1,7 %
2,3 %
2,9 %

Probably a bit less than what one would expect for 16-bit files, which is natural from the hunch that the least-significant bits are more like white noise, which is incompressible regardless of codec and will push results towards equality.


(Test corpus ... WTF did I really intend to write? Anyway, the filesizes are easy to read.)

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #70 –
Quote from: eahm on
Quote from: benski on
I suspect that compression of 24-bit PCM as well as higher sample rates could be improved in FLAC without any format-breaking changes.  The encoder is non-optimal in these scenarios.

Really? It doesn't even properly handle 24bit? I have few albums in FLAC and 24bit, what do you mean by this?


I mean that the algorithm is tuned for 16bit 44,100Hz input

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #71 –
Quote from: eahm on
Going back to the original question, not looking at the 1% better compression and not talking about TAK in every post, what doesn't True Audio have that other formats have? Again, reading the specs it seems the absolute best, please let me understand why I shouldn't convert and keep everything in True Audio.

Let me ask You probably a stupid question but it's the only way to figure out if we're on the same page here.

Do You know that all lossless formats have exactly the same audible quality (100% bit-to-bit exactly CD quality in case if source was a CD) no matter the specifications and applied algorithms?

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #72 –
Yes, quality has nothing to do with it. eahm seems to have simply read the Wikipedia article linked in their first post, seen that TTA has bigger numbers, and concluded that it must be ‘the best’ (whatever that means) despite (1) its being almost unknown to laypeople and developers, and not even very well-known amongst enthusiasts such as HA users; and (2) the fact that numerical parameters mean very little when they’re almost completely nominal and should be quite trivial to increase in the code.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #73 –
Quote from: db1989 on
Yes, quality has nothing to do with it. eahm seems to have simply read the Wikipedia article linked in their first post, seen that TTA has bigger numbers, and concluded that it must be ‘the best’ (whatever that means) despite (1) its being almost unknown to laypeople and developers, and not even very well-known amongst enthusiasts such as HA users; and (2) the fact that numerical parameters mean very little when they’re almost completely nominal and should be quite trivial to increase in the code.

Exactly, asking a simple question. Not "the best" just "the most future proof".

It's funny people attach to codecs like they are the parents, we are talking about transferring the same data with a wider range, like IPv4 vs IPv6. Of course the data isn't lost during the transfer but it's also obvious a codec with a wider range will be more future proof, it's inevitable in 10 years we will have to switch FLAC to something else when people will start wondering why no one use 64bit audio etc. etc. Same story repeating.

Why’s FLAC ‘the’ lossless codec? Is it future-proof(able)? Comparisons

Reply #74 –
Quote from: db1989 on
numerical parameters mean very little when they’re almost completely nominal and should be quite trivial to increase in the code


Given FLAC's streaminfo metadata block, increasing the number of supported channels would require an update to the format, and updated decoders, though. I didn't bother to check further.
 
SimplePortal 1.0.0 RC1 © 2008-2018