Comparison : 24bit/192KHz/stereo FLAC vs. APE, How can it be ? Options

[foorious]

Just a simple question : do TAK, APE and Optimfrog support multichannel ?
I'm asking this because otherwise they would be quite useless for most 24/192 files : the files for my initial example were stereo, but most 24bit files are also multichannel AFAIK (e.g. DVD-A)...

This reference wiki article says TAK, APE and Optimfrog do not support multichannel (maybe it needs to be updated ?), which would make WavPack the only serious alternative to FLAC for multichannel files : http://wiki.hydrogenaudio.org/index.php?ti...less_comparison

BTW I'd really love if Josh Coalson would come across this thread. Hey, if TBeck has been able to fine-tune TAK and gain 10% in only a few hours time, maybe Josh could do something similar with FLAC ?

EDIT : PM sent to Josh to inform him about this topic.

This post has been edited by foorious: Jul 31 2008, 17:55

[vpa]

BTW I'd really love if Josh Coalson would come across this thread. Hey, if TBeck has been able to fine-tune TAK and gain 10% in only a few hours time, maybe Josh could do something similar with FLAC ?

Or Justin Ruggles. His Flake Encoder has usually a higher compression ratio at -99 compared to the FLAC reference encoder at -8.

[GeSomeone]

I'm asking this because otherwise they would be quite useless for most 24/192 files : the files for my initial example were stereo, but most 24bit files are also multichannel AFAIK (e.g. DVD-A)...

I'd like to make a correction here. On DVD-Audio only stereo tracks (groups) can be 24bit/192kHz, the max for multi channel is 24bit/96kHz but 24/48 is not uncommon.
The 192kHz sample rate is rather rare (on DVD-A) because it takes up a lot of space and often the (digital) sources were in a lower bit rate.

@TBeck, Bryant or whoelse needs 1 or 2 (classical) 192kHz files for a test, have a look on the Lyndberg Lyd (2L) HiRes Download - test bench page.

[foorious]

Yes GeSomeone, no problem, my question was only about TAK, APE and Optimfrog not supporting multichannel.

I hope this thread will remain alive until some answer comes also from the FLAC side (after all we are in the FLAC subforum aren't we ?). I'm surprised that Josh, Justin or another FLAC dev haven't replied yet... maybe they're on holiday, who knows ?

[jcoalson]

sorry, been traveling a lot lately... it's hard for me to tell what's going on with this particular sample without the sample, but I think sebastian probably has it right. flac's current lpc coefficient precision may be sufficient with different/better lpc analysis. or it's always possible to extend like the rice parameter was.

I have a big backlog of experiments to work on re: lpc analysis and they are low-priority because almost no one is using such high sample rates (probably because it's a pointless waste of space, I mean really where is 20-20khz recording going to end, 1ghz?). but if someone has time to try out sebastian's ideas I would be open to incorporating improvements into the encoder.

[foorious]

Hi josh, thanks for joining in.

I understand your point, so I'd just like to emphasize on two things :

- The "problem" with FLAC doesn't seem to be dependant on a particular sample. On my initial example, all 15 tracks showed the 20% size difference with APE. Take a look at the picture.
- I agree with you, where is 20-20Khz recording going to end ? But the fact is in the forthcoming years we are going to see more and more 48 / 88 / 96 / 176 / 192 KHz music, in 24 or even 32 bits. Why ? Because the marketing guys have decided so : they want to replace all the CDs to sell more media (like BRDs are replacing DVDs), and there's not much we can do about it. I guess a major codec like FLAC can't go against the music market, even if it's not urgent yet.
- Besides, I also think a major codec like FLAC can't afford to be distanced (by 20%, not by 2-3%) by other wide-used codecs like APE when it could probably perform as well with some (minor I hope) tweaking.

If someone has the ability to work with Josh on this one by trying out Sebastian's ideas, that would be great for FLAC's future. Thanks !

[SebastianG]

I actually tested some LP coefficient quantization schemes. There's another popular algorithm that's used for preconditioning the ILS (=integer least squares) problem called LLL. So far I've only found a buggy Matlab implementation of this algorithm that's sometimes stuck in an infinite loop. But it usually gave even better coefficients compared to what I suggested earlier. Though, I'm not sure whether using the LLL algorithm for FLAC is really worth the hassle. Still, this lattice quantization problem is kind of intriguing. I'm going to check out the other LLL implementations that are mentioned by the wikipedia article ...

Cheers,
SG

This post has been edited by SebastianG: Aug 14 2008, 09:30

[TBeck]

@TBeck, Bryant or whoelse needs 1 or 2 (classical) 192kHz files for a test, have a look on the Lyndberg Lyd (2L) HiRes Download - test bench page.

Thank you!

Especially the multi channel files will be useful for me.

Unfortunately the 192 KHz files are bad examples... I've performed a frequency analysis with cooledit and it looks quite strange: Above about 48 KHz there seems to be a lot of noise. Possibly this is due to the noise shaping mentioned at the bottom of the download page: "DSD signals further require a noise shaping process to sustain the dynamic range of 120 dB within the primary bandwidth of 20 Hz - 20 kHz but that causes the noise spectrum to increase above 22 kHz." But i am not an expert in this area.

I am sure those files will be very FLAC-friendly: Because of the high pitched noise they will not show it's inefficiency when dealing with low passed alike files.

[TBeck]

I am sure those files will be very FLAC-friendly: Because of the high pitched noise they will not show it's inefficiency when dealing with low passed alike files.

I've got time to test it:

CODE

FLAC 1.2.1
  -8               54.65
  
Monkey's Audio 3.99
  Extra            53.34
  
TAK 2.0 (Developer version)
  -p3m             53.51

Exactly what i expected.

But what are such 192 KHz files good for? Twice the space requirements than 96 KHz recordings only to add noise above 48 KHz?

[GeSomeone]

But what are such 192 KHz files good for? Twice the space requirements than 96 KHz recordings only to add noise above 48 KHz?

I forgot that L2 likes to record in (what they call) DXD, which is like DSD but twice the sample four times the data rate of DSD.
As I said I didn't bother with the 192kHz but the 96kHz 5.1 at least sounded pretty good.

BTW could there be a -A function that could improve compression of 192kHz files?

This post has been edited by GeSomeone: Aug 19 2008, 13:30

[TBeck]

But what are such 192 KHz files good for? Twice the space requirements than 96 KHz recordings only to add noise above 48 KHz?

I forgot that L2 likes to record in (what they call) DXD, which is like DSD but twice the sample rate.
As I said I didn't bother with the 192kHz but the 96kHz 5.1 at least sounded pretty good.

Thanks for the info!

The 96 KHz files don't show any abnormalities in my evaluations.

[SebastianG]

"[...] but if someone has time to try out sebastian's ideas I would be open to incorporating improvements into the encoder."

"[...] Still, this lattice quantization problem is kind of intriguing. [...]"


Just in case anyone works on this: I sent Josh and Justin some C89 source code. It's able to compute approximations and the actual optimal set of quantized LP coefficients given a desired filter order and LP coefficient accuracy.

edit: Since Josh and Justin might not have enough time at their hands to incorporate this in its current form I'm willing to share the source code with others, too (simplified BSD license).

Cheers,
SG

This post has been edited by SebastianG: Aug 16 2008, 11:32

[foorious]

Are there any upcoming developments on this matter from the FLAC side ? Thanks.

[hidn]

i encode my cd. flac compression is close to another codecs, but have greatly fast decoding speed. so flac is my choice.

[jcoalson]

Are there any upcoming developments on this matter from the FLAC side ? Thanks.

no, I don't really have the time lately for anything less than a drop-in replacement to libFLAC and even that would require tons of testing.

[foorious]

Thanks Josh. I just hope you'll keep an eye on this issue for a future FLAC release. Let it be a (small) part of your 'to do list' for the future. Thank you.

[foorious]

Hi there, are there any news on this matter ? It's been a long time, and it would be great if the next FLAC version could come with some enhancements for those 24 bit / 48-88-96-176-192 KHz files.

Josh, please don't forget this. Thank you.

[ktf]

I just noticed the last SVN Flake is on par with Monkey's Audio

I downloaded FL Studio (again) on Windows just to play around with it, and generated a 192kHz/24-bit file from one of the demo's (SolidInc - What I Found) which has quite some content at around 80.000Hz. FLAC is on par with Monkey's there. When I lowpass it at 20.000Hz and keep it in the 192kHz/24-bit and encode it with Flake it even outperforms Monkey's.

CODE

Original, not lowpassed audio file
Wave: 296,5MB, duration 4:29
FLAC -8: 57,2%, took 43 sec (encoding CPU)
Flake -8: 54,4%, took 28 sec
Monkey's -c3000: 53,4%, took 38 sec
Wavpack -hh -x4: 53,6%, took 856 sec

lowpassed
FLAC -8: 53,9%, took 41 sec
Flake -8: 44,1%, took 29 sec
Monkey's -c3000: 44,7%, took 37 sec
Wavpack -hh -x3: 50,2%, took 187 sec
Wavpack -hh -x4: 27,0%, took 842 sec

Of course this isn't an in-depth analysis, but it shows that it is indeed a problem with the reference encoder, not with the FLAC format. As you can see, Wavpack's custom filters compress surprisingly better.

This post has been edited by ktf: May 19 2009, 19:30