Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: help with compressing to flac using eac and flac 1.42 (Read 4849 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

help with compressing to flac using eac and flac 1.42

Hi everyone.
I am wondering if I can get some advice please. I use exact audio copy to rip my cds, and recently I upgraded the flac encoder that the program uses using the windows executable from the flac downloads page on its website, though I didn't do anything with the dll also included. But when I went to rip some cds using it it seems as though they have changed something with how the encoder works that has broken my eac command line options.
the options I currently use are as follows,
-T "artist=%artist%" -T "title=%title%" -T "album=%albumtitle%" -T "date=%year%" -T "tracknumber=%tracknr%" -T "genre=%genre%" -8 %source%
now I am fairly good with computers generally, but admittedly I don't understand most of that above command string, I just got it from an eac setup guide, because I simply wanted the highest level of compression when making flacs which I know -8 will give me. So actually if someone could explain what that above line does that would be great. But anyway since I changed to flac 1.42 eac doesn't seem to like that command line string any more. when I am ripping a cd it outputs the following error, so I would really appreciate knowing what I need to do to fix the command string to bring it in line with whatever the changes are that were made to 1.42.
the error says
Warning
The external compressor returned an error!
Options : -T "artist=Big Finish" -T "title=1-01 Big Finish Ident"
-T "album=Gallifrey War Room Vol 1 Part 1" -T "date=2022" -T
"tracknumber=01" -T "genre=" -8 "0tmp1!542.wav"
File : D:\Gallifrey - series 13 - War Room 1 - Allegiance eac flac
log cue\cd1\01 1-01 Big Finish Ident.wav

thank you so much for any help with updating my command line options.

Re: help with compressing to flac using eac and flac 1.42

Reply #2 –
Your commandline options look fine to me, but this caught my attention:

Quote from: alexwallis on
I upgraded the flac encoder that the program uses using the windows executable from the flac downloads page on its website, though I didn't do anything with the dll also included.

The official releases of FLAC 1.4.x need libFLAC.dll to be in the same folder as flac.exe (this is just how it works). If you want a build that doesn't rely on the .dll, get the one from RareWares. There are other similar builds to be found on this forum but the RareWares ones are quite bulletproof :)

Re: help with compressing to flac using eac and flac 1.42

Reply #3 –
Edit: Paul Eye was quicker.
Quote from: alexwallis on
I upgraded the flac encoder that the program uses using the windows executable from the flac downloads page on its website, though I didn't do anything with the dll also included.
from the FLAC 1.4.2 README
Quote
The directories Win32 and Win64 contain 32-bit and 64-bit builds
respectively. Each directory contains flac.exe, metaflac.exe,
libFLAC.dll and libFLAC++.dll. The executables depend on libFLAC.dll
but not on libFLAC++.dll. If you just need the executables to work,
you can delete libFLAC++.dll
So flac.exe from the official site is dependent on libFLAC.dll. You must have both files together for flac.exe to work.
korth

Re: help with compressing to flac using eac and flac 1.42

Reply #4 –
thank you so much for those replies, putting the dll in the correct place appears to have fixed the error and eac is compressing again. Guess there will now probably be a lot of frustrated people out there experiencing the same issue, especially considering all the old eac guides floating around out there.

Out of curiosity why might I want a version that doesn't want the dll present? this doesn't bother me though.

Also, what do the command line options I have specified do? the only one I understand is -8 for compression level. I must admit I do get frustrated sometimes when I don't include an artist and some of the file names have - where an artist name would normally be. I suppose I should make more of an effort to understand the available command line options. But I am not a serious audio geek, I just want to have the best flac compression and as accurate cd rips as possible to be future proof and for archiving without getting into all the really technical stuff if that makes sense. Though I don't mind experimenting with new builds to get better compression and so on. It has actually been a thought I should reencode my flac collection especially as some rips were done over 5 years ago and some by friends who certainly didn't use -8, but having just looked at a thread tonight about that very subject it sounds like I could either create potential trouble for myself with corruption or just it might be very time consuming as I don't want to have to nurse a reencode I want to set it all running then deal with any errors after.

Re: help with compressing to flac using eac and flac 1.42

Reply #5 –
https://xiph.org/flac/documentation_tools_flac.html
Quote
-T FIELD=VALUE, --tag=FIELD=VALUE
    Add a FLAC tag. The comment must adhere to the Vorbis comment spec; i.e. the FIELD must contain only legal characters, terminated by an ‘equals’ sign. Make sure to quote the comment if necessary. This option may appear more than once to add several comments. NOTE: all tags will be added to all encoded files.

https://wiki.hydrogenaud.io/index.php?title=EAC_placeholders
Quote
Track artist    %artist%
Track title    %title%
CD title    %albumtitle%
Year    %year%
Track number    %tracknr% (same as %tracknr2%)
MP3 music genre     %genre%
   
Quote
Source filename    %source%
korth

Re: help with compressing to flac using eac and flac 1.42

Reply #6 –
Quote from: alexwallis on
thank you so much for those replies, putting the dll in the correct place appears to have fixed the error and eac is compressing again. Guess there will now probably be a lot of frustrated people out there experiencing the same issue, especially considering all the old eac guides floating around out there.

Out of curiosity why might I want a version that doesn't want the dll present? this doesn't bother me though.

Also, what do the command line options I have specified do? the only one I understand is -8 for compression level. I must admit I do get frustrated sometimes when I don't include an artist and some of the file names have - where an artist name would normally be. I suppose I should make more of an effort to understand the available command line options. But I am not a serious audio geek, I just want to have the best flac compression and as accurate cd rips as possible to be future proof and for archiving without getting into all the really technical stuff if that makes sense. Though I don't mind experimenting with new builds to get better compression and so on. It has actually been a thought I should reencode my flac collection especially as some rips were done over 5 years ago and some by friends who certainly didn't use -8, but having just looked at a thread tonight about that very subject it sounds like I could either create potential trouble for myself with corruption or just it might be very time consuming as I don't want to have to nurse a reencode I want to set it all running then deal with any errors after.

I recently started barking up the tree of wanting to re-encode much of my collection to compress more efficiently (I have some rips dating back to the early 2000’s!) but I figured maybe it’s not best to immediately do that, it’ll just be too time consuming and not as hands-off as I imagined. Maybe many years from now we’ll have processors that can shred through a task like that, with possibly even better compression. And then the task will be somewhat less intimidating. Anyway, right now I have limited I/O bandwidth on my drives so that would be a major bottleneck.

That said, if you want improved compression for any rips you do going forwards, you can use -8ep instead of -8. It will take longer - a LOT longer in some cases - to compress, but if your rig has some serious cojones the difference might be negligible - say, 5 seconds for a -8 encode and 10 seconds for an -8ep encode. In the end you have to wait for a rip to complete anyway so if you are EAC ripping and encoding in the background, it’s not *really* taking any longer than it already would have.


I should note, 1.4.x already implemented compression improvements over previous versions of the encoder that basically made one of those commands (either the e or the p, I forget which) more or less obsolete, but it won’t hurt to have it enabled anyway. Also, the gains over a regular old -8 will be pretty small but if you rip a lot of CDs, it will add up.

Re: help with compressing to flac using eac and flac 1.42

Reply #7 –
Quote from: MrRom92 on
I should note, 1.4.x already implemented compression improvements over previous versions of the encoder that basically made one of those commands (either the e or the p, I forget which) more or less obsolete, but it won’t hurt to have it enabled anyway. Also, the gains over a regular old -8 will be pretty small but if you rip a lot of CDs, it will add up.
-e is more or less dead on CDDA material. And -8pe is so slow that yes it will hurt, even when you are ripping a CD: I tested and it took half an hour for a CD (six hrs for 12 CDs), while -8p took two minutes and a half. (And ... does EAC start encoding until done? And can you rip the next CD?)

I did some more testing here: https://hydrogenaud.io/index.php/topic,123025.msg1016761.html#msg1016761
-8p -A subdivide_tukey(5) will outperform -8pe in a fraction of the time. On a Ryzen-equipped laptop, -r 7 was a bit slow, but on an Intel it could be worth it. Try then (with or without the quotation marks, depending on what does not throw an error when invoked from EAC):
-8pr7 -A "subdivide_tukey(5)"

Re: help with compressing to flac using eac and flac 1.42

Reply #8 –
Thank you for the further advice, so what does this command actually do? -A "subdivide_tukey(5 and should I use -8p and r7 and -A "subdivide_tukey(5 together? I have a fairly good laptop and I don't really care how long the process takes I want the best compression I can get assuming eac will accept the commands.

Re: help with compressing to flac using eac and flac 1.42

Reply #9 –
Quote from: alexwallis on
Thank you for the further advice, so what does this command actually do?
This is becoming a FLAC question and not an EAC question, but:
-8 is shortform for a sequence of options that lets it predict from the 12 past values (the maximum allowed within FLAC subset), blocksize 4096 (typically optimal), windowing with the subdivide_tukey(3) functions and for encoding the residual, splitting the 4096 samples into at most 2^6=64 subpartitions (each of 32 samples then) which are allowed to have their own Rice exponent parameter.
The "-r7" makes another attempt at subdividing into partitions of 16 in case it helps (-r8 is the maximum that the subset allows for, but it very rarely helps enough to be worth it).
The -A [etc] beefs up the number of windowing functions attempted.
Quote from: alexwallis on
-A "subdivide_tukey(5 and should I use -8p and r7 and -A "subdivide_tukey(5 together?
You can use them together as
-8pr7 -A "subdivde_tukey(5)"
(try drop the quotation marks if EAC isn't happy about them).


Quote from: alexwallis on
I have a fairly good laptop and I don't really care how long the process takes
Oh yes you do. There is no practical limit to how much you can slow down FLAC. Someone put their computer at work for testing this: https://hydrogenaud.io/index.php/topic,123025.msg1018796.html#msg1018796
Nearly a week to process a double album, and it didn't save 3 MB over what took 20 seconds.
 

Re: help with compressing to flac using eac and flac 1.42

Reply #10 –
I'm using -8 -p -r7 -A "subdivide_tukey(9)" in my CD ripping script.  On my Ryzen 5850U, it averages about ~18 seconds to encode a track.  In most cases, the encoding is finished before the next CD track is ripped and ready to be encoded.

I'm using these settings going forward, but for me, it doesn't seem worth it to re-encode my whole collection, even if I use multi-threading to do it.  Even with more aggressive options, the amount of space I'd save is minimal. 

This album was encoded with flac 1.2.1 (from 2007?) using -8.  It took about 8 minutes to re-encode the album on a single thread with flac 1.4.2 using the options I mentioned above.
Code: [Select]
Nine Inch Nails - [01] - Somewhat Damaged.flac: wrote 33654856 bytes, ratio=0.995
Nine Inch Nails - [02] - The Day The World Went Away.flac: wrote 26700962 bytes, ratio=0.991
Nine Inch Nails - [03] - The Frail.flac: wrote 6581086 bytes, ratio=0.984
Nine Inch Nails - [04] - The Wretched.flac: wrote 35994732 bytes, ratio=0.991
Nine Inch Nails - [05] - Were In This Together.flac: wrote 47328717 bytes, ratio=0.995
Nine Inch Nails - [06] - The Fragile.flac: wrote 32433435 bytes, ratio=0.997
Nine Inch Nails - [07] - Just Like You Imagined.flac: wrote 25696493 bytes, ratio=0.994
Nine Inch Nails - [08] - Even Deeper.flac: wrote 36104145 bytes, ratio=0.995
Nine Inch Nails - [09] - Pilgrimage.flac: wrote 22751654 bytes, ratio=0.994
Nine Inch Nails - [10] - No, You Dont.flac: wrote 27377668 bytes, ratio=0.996
Nine Inch Nails - [11] - La Mer.flac: wrote 26210802 bytes, ratio=0.991
Nine Inch Nails - [12] - The Great Below.flac: wrote 26299670 bytes, ratio=0.993
Nine Inch Nails - [13] - The Way Out Is Through.flac: wrote 22067255 bytes, ratio=0.995
Nine Inch Nails - [14] - Into The Void.flac: wrote 32962655 bytes, ratio=0.994
Nine Inch Nails - [15] - Where Is Everybody.flac: wrote 39777858 bytes, ratio=0.993
Nine Inch Nails - [16] - The Mark Has Been Made.flac: wrote 27728217 bytes, ratio=0.994
Nine Inch Nails - [17] - Please.flac: wrote 26985585 bytes, ratio=0.996
Nine Inch Nails - [18] - Starfuckers, Inc.flac: wrote 36265575 bytes, ratio=0.997
Nine Inch Nails - [19] - Complication.flac: wrote 16843937 bytes, ratio=0.996
Nine Inch Nails - [20] - Im Looking Forward To Joining You, Finally.flac: wrote 24459830 bytes, ratio=0.992
Nine Inch Nails - [21] - The Big Come Down.flac: wrote 28669232 bytes, ratio=0.991
Nine Inch Nails - [22] - Underneath It All.flac: wrote 19357036 bytes, ratio=0.996
Nine Inch Nails - [23] - Ripe (With Decay).flac: wrote 36489328 bytes, ratio=0.994

Another album encoded with 1.2.1 using -8, re-encoded with the options above, about 6 minutes to re-encode everything
Code: [Select]
Tool - [01] - Stinkfist.flac: wrote 35353440 bytes, ratio=0.994
Tool - [02] - Eulogy.flac: wrote 56701800 bytes, ratio=0.996
Tool - [03] - H.flac: wrote 37368807 bytes, ratio=0.995
Tool - [04] - Useful Idiot.flac: wrote 3571819 bytes, ratio=0.998
Tool - [05] - Forty Six & 2.flac: wrote 39854605 bytes, ratio=0.994
Tool - [06] - Message To Harry Manback.flac: wrote 6553806 bytes, ratio=0.996
Tool - [07] - Hooker With A Penis.flac: wrote 31281746 bytes, ratio=0.995
Tool - [08] - Intermission.flac: wrote 2362788 bytes, ratio=0.973
Tool - [09] - Jimmy.flac: wrote 36163718 bytes, ratio=0.995
Tool - [10] - Die Eier Von Satan.flac: wrote 13157919 bytes, ratio=0.995
Tool - [11] - Pushit.flac: wrote 66222090 bytes, ratio=0.996
Tool - [12] - Cesaro Summability.flac: wrote 7831486 bytes, ratio=0.996
Tool - [13] - Ænema.flac: wrote 44853803 bytes, ratio=0.994
Tool - [14] - (-) Ions.flac: wrote 18514293 bytes, ratio=0.986
Tool - [15] - Third Eye.flac: wrote 88095875 bytes, ratio=0.994

This one also encoded with 1.2.1 with -8, re-encoded again using only -8.  About 9 seconds to encode.
Code: [Select]
KMFDM - [01] - Ultra.flac: wrote 35213468 bytes, ratio=0.998
KMFDM - [02] - Juke-Joint Jezebel.flac: wrote 43994089 bytes, ratio=0.996
KMFDM - [03] - Flesh.flac: wrote 42083963 bytes, ratio=0.999
KMFDM - [04] - Beast.flac: wrote 38514083 bytes, ratio=0.997
KMFDM - [05] - Terror.flac: wrote 39284504 bytes, ratio=0.999
KMFDM - [06] - Search & Destroy.flac: wrote 26919731 bytes, ratio=0.999
KMFDM - [07] - Disobedience.flac: wrote 36137786 bytes, ratio=0.997
KMFDM - [08] - Revolution.flac: wrote 31781324 bytes, ratio=0.995
KMFDM - [09] - Brute.flac: wrote 35945874 bytes, ratio=0.997
KMFDM - [10] - Trust.flac: wrote 28797189 bytes, ratio=0.996
KMFDM - [11] - Nihil.flac: wrote 12857833 bytes, ratio=1.000

flac 1.2.1 to flac 1.4.2, both using -8.  About 12 seconds to encode.
Code: [Select]
Metallica - [01] - Blackened.flac: wrote 46543144 bytes, ratio=0.998
Metallica - [02] - And Justice For All.flac: wrote 68783948 bytes, ratio=0.998
Metallica - [03] - Eye Of The Beholder.flac: wrote 45070016 bytes, ratio=0.998
Metallica - [04] - One.flac: wrote 49976424 bytes, ratio=0.998
Metallica - [05] - The Shortest Straw.flac: wrote 47933198 bytes, ratio=0.999
Metallica - [06] - Harvestor Of Sorrow.flac: wrote 38636827 bytes, ratio=0.996
Metallica - [07] - The Frayed Ends Of Sanity.flac: wrote 55901275 bytes, ratio=0.999
Metallica - [08] - To Live Is To Die.flac: wrote 64237808 bytes, ratio=0.997
Metallica - [09] - Dyers Eve.flac: wrote 38629219 bytes, ratio=0.999

Re: help with compressing to flac using eac and flac 1.42

Reply #11 –
I beat you by 45 seconds linking to your NIN test ...

1.4 doesn't improve that much over 1.3 on CDDA except for special material with very low high frequency content. On high resolution it can do quite a lot: https://hydrogenaud.io/index.php/topic,120158.msg1014183.html#msg1014183 (high sampling rate can have "high frequency content" that CDDA cannot, but there is also a greater chance that the top octave is empty, which is where the higher precision of 1.4 comes into play).

Variable block size is being tested and the author can now accomplish improve over -8p by a third of a percent size in less than double the time. I guess hard drive prices will have dropped even more when variable block size is production ready and one can maybe save up to a percent over 1.2.0 -8 ...

Quote from: alexwallis on
so what does this command actually do?
I forgot what -p does.
If twelve predictor coefficients are stored with 15-bit precision each, that takes up 22.5 bytes per block (mono, for simplicty - and then a typical block is 8 kilobytes uncompressed). If they are stored with 5-bit precision instead, fifteen bytes are saved. But usually, lower precision leads to a worse prediction. That is a trade-off that -p tries to brute-force optimize by checking all possible precisions. It shouldn't matter much - like, around 0.15 percent.
However, what happens in practice is that the round-off could by chance improve the predictor, and therefore -p quite often gives better than ratio = 0.999.

Re: help with compressing to flac using eac and flac 1.42

Reply #13 –
Quote from: Porcus on
Quote from: MrRom92 on
I should note, 1.4.x already implemented compression improvements over previous versions of the encoder that basically made one of those commands (either the e or the p, I forget which) more or less obsolete, but it won’t hurt to have it enabled anyway. Also, the gains over a regular old -8 will be pretty small but if you rip a lot of CDs, it will add up.
-e is more or less dead on CDDA material. And -8pe is so slow that yes it will hurt, even when you are ripping a CD: I tested and it took half an hour for a CD (six hrs for 12 CDs), while -8p took two minutes and a half. (And ... does EAC start encoding until done? And can you rip the next CD?)

I did some more testing here: https://hydrogenaud.io/index.php/topic,123025.msg1016761.html#msg1016761
-8p -A subdivide_tukey(5) will outperform -8pe in a fraction of the time. On a Ryzen-equipped laptop, -r 7 was a bit slow, but on an Intel it could be worth it. Try then (with or without the quotation marks, depending on what does not throw an error when invoked from EAC):
-8pr7 -A "subdivide_tukey(5)"


I’m guessing this might be heavily processor dependent, but on my Ryzen 5950X, compressing a track of typical length in EAC with -8ep doesn’t take anywhere even near that long - it’s still really only a matter of seconds. So I find it really inconsequential to leave it enabled, even with “e” still part of the equation.


EAC can (and on any relatively modern system; should) be configured to start compressing a track immediately after it’s ripped, and it can be configured to multithread too. So even if you’re ripping in burst mode, as I often do, it can have a few tracks compressing in the background at once while it’s still ripping through the rest of the disc.

It’s really only the last track you’re ever going to be waiting for, and that’s especially true if you’re ripping in the (usually much slower) secure mode. Regardless, it’ll probably finish compressing that last track before you even manage to hit the eject button, let alone insert the next disc (though that wouldn’t be a problem either - I’ve been able to start ripping the next disc just fine in instances where I was still waiting for a ~25 minute long classical track to finish compressing, or anything like that)


-8ep is such a quick and easy way to get slightly better than -8 compression, I say to just try it and see how it works. And if it really takes anyone so much more time than a standard -8 that it affects their ripping workflow somehow, - which I don’t see happening unless the PC is reaallll old - just backspace those 2 letters and the problem is solved. It’s worth a shot!


Of course, I say this as someone whose knowledge pales in comparison to yours and many of the real contributors here. I have a very light understanding of all the command line options. So when it comes to subdivide this, and turkey that… I get lost very quickly, the only turkey I know anything about is the one I’ll be eating this Thursday. But you give me the option of “use 2 letters. make slow but more good.” and I have no trouble wrapping my caveman brain around that.

Re: help with compressing to flac using eac and flac 1.42

Reply #14 –
Yeah, if you are using a gaming rig and compressing multithreaded and want few letters ... try two more for
-8per8

Quote from: MrRom92 on
- which I don’t see happening unless the PC is reaallll old -
Not age, but priority? Not everyone is using a CPU benchmark-scored at 45825 and which costs more than my brand new home computer equipped with something scoring slightly above 10k. Also work just equipped me with a new not-exactly-cheap laptop with a CPU benchmarking 11k.
A quarter of the score, a quarter of the cores&threads, a quarter of the heat dissipation. That's not age, they are both produced this year - it is just matter of priority.

Now said test was done single threaded on a Ryzen 2500U scoring 6526, in a laptop that a couple of years ago cost about the same (for the entire laptop yes) as your CPU. Sure if you have paid to sextuple that, ... use it. At least if you are in the Northern hemisphere with winter coming right up and the heat isn't wasted  ;)

Re: help with compressing to flac using eac and flac 1.42

Reply #15 –
Quote from: Porcus on
Yeah, if you are using a gaming rig and compressing multithreaded and want few letters ... try two more for
-8per8

Quote from: MrRom92 on
- which I don’t see happening unless the PC is reaallll old -
Not age, but priority? Not everyone is using a CPU benchmark-scored at 45825 and which costs more than my brand new home computer equipped with something scoring slightly above 10k. Also work just equipped me with a new not-exactly-cheap laptop with a CPU benchmarking 11k.
A quarter of the score, a quarter of the cores&threads, a quarter of the heat dissipation. That's not age, they are both produced this year - it is just matter of priority.

Now said test was done single threaded on a Ryzen 2500U scoring 6526, in a laptop that a couple of years ago cost about the same (for the entire laptop yes) as your CPU. Sure if you have paid to sextuple that, ... use it. At least if you are in the Northern hemisphere with winter coming right up and the heat isn't wasted  ;)

I’m not sure if there’s actually a direct correlation with benchmark scores or processor speed vs time spent on an -8ep encode, but for the sake of argument assuming it took 4 times longer than my rig on a PC with only 1/4 the power… we’re still talking seconds rather than minutes for a 16/44.1 CD track of average length, and definitely not on the scale of hours. So that’s why I think this is mostly inconsequential when you’re performing a mostly linear task like ripping a CD and have to wait for that to complete anyway - say, ~3 or so minutes for a burst rip and possibly in the neighborhood of 20-40 minutes for a secure rip of the same disc on a drive with audio caching. Even if only ripping directly to WAV and no compression is being performed at all, it’s the act of of ripping itself that serves as the real time bottleneck.

Of course I know the horrors of -8ep on a less powerful system all too well. Especially fed with higher res content. Sometimes I’d recompress a 24/192 album at -8ep on my older Toshiba laptop (circa 2009?) and that task might take all day. Definitely much slower than real time.

If I may ask, what does the “8” in that r8 command do differently than -8 or -8ep without specifying that? I understand that r can be specified between 0-15,  but what exactly does this function do and what is the effect of both extremes, say r0 vs r15?

Re: help with compressing to flac using eac and flac 1.42

Reply #16 –
Edit: accidental double post

Re: help with compressing to flac using eac and flac 1.42

Reply #17 –
Quote from: MrRom92 on
If I may ask, what does the “8” in that r8 command do differently than -8 or -8ep without specifying that? I understand that r can be specified between 0-15,  but what exactly does this function do and what is the effect of both extremes, say r0 vs r15?
If you want to stay within FLAC subset, 8 is the max.
When FLAC has done the "prediction", i.e. found a parametrized form that is not way off the signal, it has to encode every sample's residual - namely the difference between true value and predicted value.
The TL;DR of this is that -r 7 does all the work of -r6 plus splits the residual into twice as many partitions to see if that improves. If it doesn't ... then it has only done extra work only to see that "oh, order six [or five or ... zero] was better for this block, stick to that". -r 6 is auto-selected by -8, but if you give -8 -r 7 the -r 7 will override. -r 8 will again split in two compared to -r 7. More extra work, and - as far as my testing indicates anything - very little gain except very special signals. -r 8 splits each block (defaulting to 4096, and for CDDA you apparently want to stick to 4096) into 2^8=256, meaning it chooses the so-called Rice parameter once per 16 sample. That means it has to store twice as many such parameters as -r 7, that is the downside. But if it isn't offset by better fit to signal, then the encoder will fall back to order seven. Or six if that was even better. Or five. Or four. Or ... zero.

So in most cases, -r8 only spends time. If you encode high resolution material, the story needs another chapter, but for CDDA you stick to the block size that -8 chooses for you.

And then:
The encoder allows you to write -8per7 for -8 -p -e -r 7. They are the same. Similar for -8per8.

Re: help with compressing to flac using eac and flac 1.42

Reply #18 –
Quote from: Porcus on
Quote from: MrRom92 on
If I may ask, what does the “8” in that r8 command do differently than -8 or -8ep without specifying that? I understand that r can be specified between 0-15,  but what exactly does this function do and what is the effect of both extremes, say r0 vs r15?
If you want to stay within FLAC subset, 8 is the max.
When FLAC has done the "prediction", i.e. found a parametrized form that is not way off the signal, it has to encode every sample's residual - namely the difference between true value and predicted value.
The TL;DR of this is that -r 7 does all the work of -r6 plus splits the residual into twice as many partitions to see if that improves. If it doesn't ... then it has only done extra work only to see that "oh, order six [or five or ... zero] was better for this block, stick to that". -r 6 is auto-selected by -8, but if you give -8 -r 7 the -r 7 will override. -r 8 will again split in two compared to -r 7. More extra work, and very little gain.

... in most cases. If you encode high resolution material, the story needs another chapter, but for CDDA you stick to the block size that -8 chooses for you.

And then:
The encoder allows you to write -8per7 for -8 -p -e -r 7. They are the same.


Ahhh I see, okay thank you for the explanation. I may experiment with that a bit (staying at 8, due to the subset reasons you mentioned) to see where it gets me - could be interesting!

Re: help with compressing to flac using eac and flac 1.42

Reply #19 –
In my testing, -r8 only shaved off a few bytes over -r7 while taking much longer to encode. 

Re: help with compressing to flac using eac and flac 1.42

Reply #20 –
Yeah, and that is due to most of how FLAC works: It doesn't "layer up" with complexity, it tries a whole lot of "simple" methods and picks the one that happens to give smallest size. All the other work is just ... work for nothing. -r 8 means try more of something beyond what usually helps - and only every now and then (= for a very few blocks) that improves.

Downside to this approach: compression that can only be accomplished with "complex" patterns (i.e. taking a lot of CPU to decompress), will not happen.
Upside: ultra-light CPU footprint on decoding. FLAC is likely the fastest-unpacking algorithm in widespread use.

... now, nearly twenty years ago, I guess may did believe that this asymmetric way (light footprint on decoding) just couldn't achieve WavPack/Monkey's/OptimFROG level compression. Then along came TAK.
And WavPack started employing asymmetric algorithms on top of it (the -x switches) and even OptimFROG does that now - although it isn't fast.