What are the settings i should use in FLAC to get the bets possible compression? doesn't have to stream, and compression time isn't an issue, i can deal with some long encodeing times.

i know --lax, and --no-padding help, but are there more options i can use to decrease resulting file size?

and i might aswell also ask, does useing -V ensure that the compressed data is teh same as the input wav file? like 100%, no possiblity for -v to not catch a error?

Thanks in advance.

Really there aren't a whole lot. Just use --best, which itself won't get you more than about a 1-2% benefit over the default settings. I'm not sure --lax will help much.

Both --best and -8 should yield identical results. However, I would recommend avoiding the --no-padding switch; the few bits you'll save are not noticeable, and if you later want to add FLAC tags the entire file will have to be re-written (whereas when one uses padding the padded space is overwritten with the tag, and the rest of the file remains unmodified).

- M.

Try

--super-secret-totally-impractical-compression-level

Well, yeah, that would do it... but fer cryin' out loud, it was Fallen_Knight's first post!

- M.

I'm not sure what you mean here? My post was not a joke.

Garf's right...

--super-secret-totally-impractical-compression-level
is equivalent to
--lax -P 4096 -b 4608 -m -l 32 -e -E -p -q 0 -r 0,16

Sorry for the apparent confusion. I know the post was not a joke, and I've played with that setting in the past. But over a 50+ Mb file, the typical savings I saw was in the range of 8 kb (No, I'm not joking either!). Since the time trade-off was monumental, I didn't even think of suggesting this; the "totally-impractical" part of the setting's name is there for a reason.

The reference to it being Fallen_Knight's first post was merely a joking reminder that we shouldn't suggest such things to those who might, as "newbies," take our suggestions as the soundest available advice... but on reflection, I must admit that --super-secret-totally-impractical-compression-level is exactly what Fallen_Knight requested. I stand thus corrected.

- M.

Whoa! That was the first time I heard of such a switch...

What a fantastic name for a compression profile!

Garf, you told!

Just kidding. Little bit of trivia: that used to be -9 but people kept complaining how slow FLAC was. Some users will always use the highest compression level without analyzing the tradeoff, and then complain. That's what is happening with MAC Insane.

Josh

when using via shntool (shntool conv flac *.wav) what compression level am I using?

thanks.

Shntool uses the default setting of -5, although you can enable a higher compression by using the "cust" format module.

For example, this line will output FLACs with the default compression level:

... while this line will use the -8 (--best) setting:

... and if you are really, really desperate to shave off a few extra bytes, then here's the "totally-impractical" version:

- M.

thanks for the info.

Thanks for the info, and yea i did try that --super-secret-totally-impractical-compression-level
, its utterly slow on my computer (xp 2500+)

so i stuck with -8, --lax --no-padding(4kb per track! woohoo! and i don't mind haveing to rewrite the entire file, it doesn't really take all that long)

Figure that if anything better comes up i'll just reencode bceause hey, its lossless=) Thou i do worry how well my CD-RW is reading the CDs.... but not much i can do about that.

Thou there was one other thing, any advantage to useing a huge block size? I was looking thru the docs and saw that you could use a block size of 32768. Or to useing a really small one?

The optimal blocksize depends again on the input. There is a thread on the flac-dev list about an experiment using an exhaustive search algorithm for finding the optimal blocksize (very slow). I think it made a difference of at most ~1% for some CD samples.

Josh

hmm, a bit impractical, /me thinks...

flac default setting is just fine. going higher just increases encoding time 10x and saves only a few KB.

In my opinion FLAC is not the best lossless compressor, so why you using it ? The only good thing is that FLAC is not symmetric so if you spend for example 30 mins for compression you don't need these 30 mins to decompress. So if you
have quite strong PC - better use MAC or other ...

Probably because not everyone shares your opinion. For example, in my opinion FLAC is the best lossless compressor, so why aren't you using it?

"Best" is highly subjective since it aggregates many tradeoffs.

Josh

Why I'm not using FLAC ?

First: poor compression. You may tell that this is not the main thing but what is the main ?
That is FLAC ported to many platforms and it's open source or it supports streaming ?
Thruly speaking I don't care because I using Mustdie \ I have no FLAC related hardware \ I'm
not a programmer and I'm not a fool to listen to the FLAC's fat stream from net. So I repeat:
it's only my opinion and my suggestion, so why you're so angry ? Or maybe you just feel yourself that FLAC is not the best ?

Second: I tired to digging in all of these command line parameters trying to find optimal block
size and LPC predictor realizing that one effects another.

Third: No GUI. Of course there are some frontends but no one normal.

So what I can say: FLAC is not the worst but not the best. Now is your turn !

So in essence: FLAC is not the best because it, uh, is the best at several things (streaming, quick decompression, open source, compatibility, choice of GUIs, cross-platform compatibility, simplified command line options), but there are features you don't care about.

Great argument.

You might have a valid argument someplace, but it certainly hasn't been posted on here for the rest of us to see.

Brrr Guys ! Let's stop it. We can argue till the end of time. We're here to help each other, isn't it?

PS: I want to ask something: is it possible to implement variable block size coding in FLAC ?

Skymmer, I'm not mad, but you totally missed the point, so I'll be explicit. I wasn't asking you to tell me why you don't use FLAC, I was trying to demonstrate that, just like my statement didn't convince you to use FLAC, your statement won't convince anyone else not to use it. So for a gratuitous statement of your personal opinion you managed to turn a thread about something else into a debate on formats. Please think before you post stuff like that next time.

Josh

Yes, I already said it's been done as an experiment. Search the flac-dev list for the thread to see why it is not worth it.

Josh

So what's the size/speed tradeoff detween the default and -8? I searched the boards a bit, but haven't really foud a compelling reason to switch from the default settings. But, if you have one, do tell!

http://flac.sourceforge.net/comparison.html

Is this equivalent to VBR in an MP3 file? Because when I play a flac file with xmms, the bitrate changes while playing the song just like a VBR MP3 file.

No, all lossless compression will be VBR. The variable block size refers to the input blocking, not the output rate.

Josh

Use LA(www.Lossless-audio.com), is the best in compression although is slow when comparing to flac or ape encoding time.

My test (i have an AMD 2.0GHZ And 756MB DDR 3200)

Compression

wav - 100%
Flac - more or less 52 -53%
Ape - more or less 49 -50%
LA - more or less 46 -47%


Speed Average(between this three)

APE is the fastest
FLAC take second place (Near to ape)
LA is the slowest (SLOW)


I use LA, because i want compression And Quality, works with foobar/winamp and xmms (linux), so is great to me, i have 768mb ram, so the heavy playback it requires don't bother me.

Flac it was an option but i don't use stream, and i don't care for encoding time.

i apply replaygain with foobar (album gain) in to la files, although with Flac isn't necessary because the frontend already come with RG.

La support for foobar2000 is broken and left in an unsupported status.

There seems to be no development either, as of recent years.

A shame, really.

Does the 2-3% make that big of a difference?

I'm using FLAC as the standard format for archiving (I digitize vinyl records). I found that '6' is the best compression in terms of time spent.

I got lot of loading and saving with Adobe Audition and Foobar2000, '7' and '8' will be too slow for me. And one more reason: FLAC v1.1.3 improves compression so '6' compress even better.

If you want to minimize your archive and you don't need lots of compress/decompress, you can go for '8' but you need to spend more time. Time is the most precious besides size.

I'm curious - how long does a FLAC encode at -6 take on your system?

Mine average 30 seconds or less for a 6-8 minute track at --best (-8). That's less time than it takes to rip the track with EAC.

Do you really save that much time at -6?

In my comparison -6 encodes over 3.5x faster than -8.

I agree that -6 seems to be the "sweet spot".

Interesting. -6 is clearly faster in this test.

However, with FLAC -8 -A x2 on 512 MB of RAM and relatively slow Athlon XP 2400+, Win 2K, the encoding times are roughly 2x longer than what I'm seeing (FLAC -8 -V, 2GB RAM, 3.4 Ghz Dual Core P4, Win XP Sp2)

With a more up to date system, you get far better performance - to the point that -8 -V encoding time is equal to or less than ripping time. Any faster won't speed up the overall conversion process.

On the other hand, -8 isn't much smaller than -6, so it doesn't matter either way :-)

I agree. When i was doing secure ripping, the max ripping speed i got out of EAC was ~12X. In my tests, Flac at -8 encodes at about 13X which would be fine for my purposes.

Did anyone tested ffmpeg flac encoder?
It compress pretty fast with default setting(~16x on P4 2.4GHz),
and the compressed flac file size is about equal to official flac encoder -8 too
plus a lot of options to play.

EDIT: it beat gharris999's icl P4 compiled flac encoder encoding speed.

ffmpeg flac encoder is named 'flake'. It also exists as standalone encoder and was tested and discussed here. It's already included in Winamp. It compresses well and is really fast.

Thx for the info
Downloaded the flake source code and compiled

Can you rip and encode at the same time with EAC?

Yes. With an external encoder like FLAC, EAC rips to wav files in a queue. The queue then feeds the command line encoder.

It happens sequentially, but continuously. Track 2 is ripping while track 1 is encoding, and so forth.

If the ripper and the codec both write to the harddrive, doesn't that lead to heavy fragmentation?

Using XP leads to heavy fragmentation. What you use it for is incidental.

But seriously, not in my experience, as long as you have a decent amount of space available, say more than 15%. And I use diskkeeper to de-frag so I never worrry about it.