Hello,

I set my flac encoder to 8, and this is the command parameters it adds

"--delete-input-file -P 4244 -b 4608 -m -l 12 -e -q 0 -r 0,6 -V"

Will this yield the most compression possible?
Is their any way to change the parameters to get smaller files?
BTW, the input file is a Wav, 44.1k, 16 bit. A normal rip from a music cd.

Thanks

I did a test with Flac set to 8 and set to 5. Flac at 8 took longer to encode than 5, but the resulting file was the same size. I only tried this on one file though so this is probably not the case all the time. I would stick with 5 though.

flac.exe --super-secret-totally-impractical-compression-level

(which uses: --lax -P 4096 -b 4608 -m -l 32 -e -E -p -q 0 -r 0,16)


Edit: Warning...this setting results in vvvveeeeeerrrrryyyyy sssllllooowwwwwwww processing. My P4 2.0GHz takes 1 minute to compress 5% of a 7-1/2 minute track, hence ~20 minutes for the whole track (and that's only one song, mind you).

Edit 2: Compared with simply using -8, the above setting compressed my sample track at a ratio of 99.829% compared to an instance compressed with -8 (48931KB vs. 49015KB), and the latter compressed much more quickly (40 seconds vs. 20 minutes). The moral of the story...use -8.

Not that it will compress noticeably better, but will definately take MUCH longer

-Eugene

Is their anyway i can convert my already compressed and taged flac files to the "--lax -P 4096 -b 4608 -m -l 32 -e -E -p -q 0 -r 0,16" method directly?

Thanks

I don't know of a way to convert directly from FLAC --> FLAC with different settings. AFAIK you have to convert to PCM WAV first. You could batch the two steps together, decoding to WAV followed by (re)encoding to FLAC with your desired settings.


Edit: oops...I do know of a way. Use dBpowerAMP Music Converter (and also download the FLAC codec plug-in from "codec central" at the top of the linked page). And it does carry tag info with file conversions if you check the Preserve ID Tags box.

Just use a program that compresses from one format to another (e.g. multi frontend). Of course, it must decompress to wave while compressing to the new FLAC but from your standpoint it is going direct FLAC->FLAC and conserves tags.

I would not even think of it! Just tried one song at 4:13 min playtime.
Here is the result:
* FLAC --best = 26 791 928 bytes
* FLAC --super-secret-totally-impractical-compression-level = 26 761 864 bytes

Total compression time on my Pentium 4-m 1.8GHz 18min. vs. 30sec.
Compression time 40x to cut of 30KB! No way!!

Don't bother. --super-secret-totally-impractical-compression-level is really for testing, to exercise all paths of the encoder. The only chance you'll do significantly better than -8 is to tune the various parameters to match your input, and you'll have to read about and understand the format spec to do that.

Josh

instead of this --super-(waiting)-secret-totally-impractical-compression-level i would use Monkey Audio.

Thanks for your opinion, but that is off-topic in this thread.

What? Off-topic? Alright, the original question dealt with FLAC compression, but proposing another lossless codec that provides better compression than Flac -8 doesn't seem off-topic to me; considering that the topic title says "Better compression than flac on 8", to which the answer "Monkey's audio" is a valid answer. (If the title had been "Better compression than -8 on flac" it would have meant something else). On the other hand, the topic starter didn't specify that using FLAC was an absolute must. Considering that s/he is a relative newbie and may not have heard of other lossless codecs, proposing another lossless codec that does what s/he asks for, seems the right thing to do.
Anyway, so that my post isn't regarded as off-topic, too; I'll address the question:

@caster: Is there are reason why you need to use FLAC to compress your music? Since maximum compression seems to be of importance to you and not so compression time, I would suggest you to use Monkey's Audio at High or Extra High compression or, if saving the last bit is critical, perhaps OptimFROG or La. Bear in mind that the higher compression of the latter codecs has negative side-effects, such as slower decoding times or bad seekability.

Considering the topic and the original post, it seems to me that the poster asks specific tweaked FLAC settings which result better compression than the FLAC -8 setting. Also considering this, he is aware of Monkey's Audio already.

I used APE for awhile, and then switched over to flac. The reason i did this is because i liked the tagging that flac did better, and also that i could encode flac at maximum compression and have it play back with minimum CPU load. This was a big concern because if i have to much load on my CPU my music skips alot. Also i see that Flac is getting alot of commercial attention, such as from RIO.

I'm having a problem getting "--super-secret-totally-impractical-compression-level" to work with EAC. My normal compression settings work correctly (which is pretty much -8 compression), but the "--super-secret-totally-impractical-compression-level" for some reason will not work. Any one else encounter this problem?

Also, dBpowerAMP Music Converter won't let me use command parameters with the encoding, otherwise i would convert all my -8's into the "--super-secret-totally-impractical-compression-level". Anyone have a workaround for this, or another program suggestion?

Thanks

Under Additional command line options, use...

--super-secret-totally-impractical-compression-level %s %d

I confirmed that this works for me. (Leaving off the %s %d is my own most common mistake with calling external compressors in EAC.)

Also, for Parameter passing scheme be sure to specify "User Defined Encoder", and confirm the path to your flac.exe.


Edit: Also, re: using command line options in dMC...I'm not aware of any downloadable CLI encoder plug-ins for dBpowerAMP Music Converter, but here's a page that describes how to create one. Also, you'll likely need an in_flac.dll from one of the FLAC bundles available at Rarewares.

OK,

I have EAC using " --super-secret-totally-impractical-compression-level -V %s %d -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" " with success. i had to shuffle the %s and %d around to get it to work.

I was curious how many "Simultaneous compression threads" i can use with EAC, considering that these files take long to compress. I have a P4 2.6ghz with a 400FSB and 512k of RDRAM.

I am going to take a guess at the outcome of this. I'm guessing that it will take the same amount of time no matter what. Lets say you have 2 songs, and it takes 30 minutes to compress them 1 at a time. Well, if you do 2 at the same time, since the CPU resource would be split, it would still take 30 minutes, just each would get done at 50% speed each.

The only thing that i can think of is that the fact that EAC can start the encoding right after a additional track is added might get the job done faster. Does anyone have input on this?

(Addition) i see that their are only 4 max theads you can have now. i'm guessing 4 is optimal since it's probably not alot of load on the CPU over just 1.

Depends if you have a P4 with hyperthreading.

ok, i do not have hyper-threading

i am doing an extraction with 4 threads and each process is getting about 25% cpu power.

I'm guessing that i'm gonna have to experiment myself to see which method is faster, but does anyone know if i should keep 4, or go to something like 2?

Thanks

Leave it at 1, HT or not.

More than one means more system overhead in managing the extra I/Os and processes. Yes, this overhead is going to be immesurably small, but the point is that 2 tasks will both run twice as slow as one task.

FLAC encoding is CPU bound. Running more than one process at once will not speed it up. Buying a faster CPU (or moving to a multi-processor system) will.

HT is of little to no use here.

On my PC (VAIO notebook, P4m 2.0GHz, 400MHz FSB, 512MB RAM), I run four compressions at the same time with flac.exe (-8), lame.exe (--alt-preset standard) or oggenc2.exe (-q 5).

I've tried one, two, three and four tasks simultaneously to at least get an idea of speed differences, and I noticed only moderate differences for each additional compression task (for each format), so I just let it do four at a time (whenever I use EAC as my compression front-end, anyway).

For me, it was more a question of "Can I do other work in the foreground while it's compressing?" than "How fast will it compress four-at-a-time?" My machine apparently has just enough juice to handle four compression tasks (at what I consider an acceptable speed), plus an extraction, either WaveGain or MP3Gain, an occasional mass-tagging task in Tag&Rename, without keeping me from doing other things in the foreground at the same time. Your machine is faster than mine, and unless your normal active process list is a lot longer than mine is, you should expect similar-or-better performance (I would think...though there are other things that can affect performance).

I'm amazed that you actually find "--super-secret-totally-impractical-compression-level" to have enough practical use to want to convert already compressed files (using -8, no less), considering the enormous amount of extra time required to yield an insignificant amount of space savings.

ff123

Actually... you hit that one right on the nose. Lol. I have decided not to compress my files any farther than -8. If it compressed better (better meaning not as slow, lol) i would use it. It does compress it farther, no doubt. But the time is too much, i do other things on my computer, and i need that CPU time for that.

Thanks for everyones help in my exploration of this method.