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

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 (Porcus @ Jun 24 2012, 21:25)

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 (Dario @ Jun 24 2012, 20:21)

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

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.

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

(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?

Earlier in the thread, 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 (db1989 @ Jun 25 2012, 13:36)

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.

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.

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.

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.

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.

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:

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

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?

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.

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.