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: FLAC 1.1.3 settings (Read 19966 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC 1.1.3 settings

These are the setting I use with FLAC 1.1.3 with EAC and thet work very well to get better then default -8 compression...

-8 -A tukey(0.25) -A gauss(0.1875) -b 4096 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s --sector-align

And if you were using FLAC on the command line, you would use ...

flac -8 -A tukey(0.25) -A gauss(0.1875) -b 4096 -V --sector-align filename.wav

Now does anyone else have any better overall settings? I think my settings are pretty good. Have a go and try for yourself.

FLAC 1.1.3 settings

Reply #1
Code: [Select]
flac.exe --best --cuesheet=sheet.cue --tag-from-file=CUESHEET=sheet.cue

The "--best" option indubitably proves that my parameters string is the best

FLAC 1.1.3 settings

Reply #2
I would not use --sector-align with CD rips.  in the best case it will do nothing, in error cases (improper rips) it could move samples between tracks which you might not notice happening.  that option was made for etree so they can break recordings up on CD sector boundaries.

it is usually possible to get (diminishingly) better compression by adding more window functions but the encoding time drastically goes up with each one.  rarely worth it.

Josh

FLAC 1.1.3 settings

Reply #3
I didn't realize the -A option could be used multiple times.

FLAC 1.1.3 settings

Reply #4
I didn't realize the -A option could be used multiple times.
Bear in mind though that each additional window will drastically increase encoding time, with relatively little improvement in compression.

Josh put a lot of thought into picking the default window used.  It will give very good performance for most music types, and additional windows really aren't worth the benefit, IMHO.
I'm on a horse.

FLAC 1.1.3 settings

Reply #5
The rectangular window is well worth it when encoding 8-bit audio.

FLAC 1.1.3 settings

Reply #6
I feel the additional time is worth it because once it's done, it's done and the smaller files will always be smaller files. If you don't do it and later on decide you want to do it then you have to do it. That takes even more time to do it. But what I do sometimes is rip to WAV and wait and do it when I won't be using the computer so it doesn't matter that it's slower. The additional compression is worth it to me.

FLAC 1.1.3 settings

Reply #7
And if you were using FLAC on the command line, you would use ...

flac -8 -A tukey(0.25) -A gauss(0.1875) -b 4096 -V --sector-align filename.wav

I tested this setting with (only) two albums. Compression was a little worse than the standard -8. What are your results?

FLAC 1.1.3 settings

Reply #8
the difference is probably due to the blocksize more than anything else.


FLAC 1.1.3 settings

Reply #10
Because 1.1.3 has the dot/comma bug, I'd like to have cleared up a few things.

1. Is -8 -V identical to --best -V in 1.1.3 (1.1.) and also in 1.1.2 (1.2.) ?

2. What is bugged by the dot/comma bug in 1.1.3 ?
2.1.  If only standard settings like -8 -V (plus tag settings) or --best -V (plus tag settings) are used eg. through EAC, mareo.exe or foobars discwriter, there isn't any bug ?
2.2. Does the bug take in action, when there is a comma in commandline like in special tuned commands like A/tukey 2,5 respectively 2.5 ? (the 2.5 just as example for a number)

3. Is Case's flac 1.1.3 safe to use for windows, bit identical outputs, anybody done some tests, experiences so far ?

4. If or when might there be an offcial flac 1.1.3 bugfix release, update to 1.1.4 or 1.1.3.1 or however you wanna call it?

FLAC 1.1.3 settings

Reply #11
1.1. Yes.

1.2. No, due to the new apodisation feature.

2. If you do not specify an -A (apodisation) switch FLAC defaults to -A tukey(0.5).  On systems that use the comma as the decimal separator this is deemed ill-formed and ignored (FLAC falls back to the old rectangular window), so the results are not the same as a system which uses the full stop (period).

2.1. Yes, there is a bug.  See 2.

2.2. If you specify the -A switch using the correct notation for your locale everything should be fine.

3. I've performed a test on the RW corpus at -5 and both encoders produce files of the same size.  I know this isn't conclusive.

4. No idea.

Edit: For clarification on 2 and 2.2 this post may be of use.
I'm on a horse.

FLAC 1.1.3 settings

Reply #12
1.2. No, due to the new apodisation feature.

that means:
flac113 -8 = --best
flac112 -8 >= --best ; -8 less compression than --best, but clearly lower encoding time for flac112 -8 vs. --best ?

2. If you do not specify an -A (apodisation) switch FLAC defaults to -A tukey(0.5) .  On systems that use the comma as the decimal separator this is deemed ill-formed and ignored (FLAC falls back to the old rectangular window), so the results are not the same as a system which uses the full stop (period).

I understand this as following:
if flac113 is used in default standard switches like -5 , -8/--best , it causes mistakes on comma-systems.
Only, if on these systems the command would be -8 -A tukey(0,5) , it would produce the correct result ?
If my assumption 2. is correct  this way, this bug is a serious one, and flac113 should not be offered for dl to the general JoeAverage out there
(like me, though I even followed roughly the dev topics here at HA and waited seriously for this new great promising flac, if it wouldn't have this bug)),
because you cannot "sell" an additional switch to be used instead of -5 or -8/--best.
I think, there are 1000s of guides with flac example commandlines, and 1000s of "users", who have their flac commandlines unchanged since ages in EAC, foobar etc.
This was one big advantage of flac, that it was so stable over years, ie. regarding switches.

I suggest as solutions, to remove the dangerous flac1.1.3 from public download pages,
and replace by some bug-free version eg. that one of Case, or is there already another official one ?
If this solution cannot be made for some reason,
then it is better to stick to 1.1.2 and offer no 1.1.3-update-bug-fixed-version, until such an update/bug-free version is available.





3. I've performed a test on the RW corpus at -5 and both encoders produce files of the same size.  I know this isn't conclusive.
Have you made a quick binary comparison eg. by total commander, as you ahd the files ? Done for 1-2 files eg. an -5 and -8 encode, this proving by example should be sufficient until proven otherwise lol.




Edit: For clarification on 2 and 2.2 this post may be of use.
well, I had read the official flac topics in news forum, and that had lead to above questions, as it remained unclear for me. And if you consider that people using flac reading here at HA and people using using flac not reading HA, will be very likely total different amounts, ie. HA-flac-users will be a minority to the non-HA-flac-users out there, who will be stunned, that new flac 113 produces less compression than ol' 112, flac might lose it's stable reputation.



btw., this topic has an interesting title "best flac settings":
For the lossy formats such topics make sense, obviously less sense for the Lossless formats, because Lossless is Lossless is Loslsess qualitywise.
The differences amongst Loslsess formats or different settings of one L-format, ly between the encoding (soemtimes also decoding) times and achieved compression ratios.
And everybody (the devs of course too for some offered standard possibilities/settings) has to select the best compromise for themselves regarding compression ratio and en-/de-coding times.
So, there is no "best" setting for flac, but the best compromise for each individual, whilst obviously new 113 --best/-8 setting will be the best for JoeAverage (imo), if it behaves roughly like 112 -8 setting regarding encoding times/cpu power.
But that a general "best" setting needs additional switches like tukey/comma, this is opposite to the good usability of previous flac versions.
Nobody might get the idea, that a standard switch like -5 or -8/--best, might need an additional switch or some workaround.
This bug should not be there for a longer time in public release 1.1.3,
because JoeAverage will downlaod and install obviously latest available release, which is buggy 1.1.3 at the moment ?

FLAC 1.1.3 settings

Reply #13
that means:
flac113 -8 = --best
flac112 -8 >= --best ; -8 less compression than --best, but clearly lower encoding time for flac112 -8 vs. --best ?
I don't really understand the above.  You can't really compare 1.1.2 and 1.1.3, as 1.1.3 has the totally new apodisation feature.  All you can say is:

1.1.2 -8 === 1.1.2 --best
1.1.3 -8 === 1.1.3 --best

I understand this as following:
if flac113 is used in default standard switches like -5 , -8/--best , it causes mistakes on comma-systems.
Only, if on these systems the command would be -8 -A tukey(0,5) , it would produce the correct result ?
Yes, that's right.

Have you made a quick binary comparison eg. by total commander, as you ahd the files ? Done for 1-2 files eg. an -5 and -8 encode, this proving by example should be sufficient until proven otherwise lol.
No, and the test was at work and I'm now at home.  However, I did compare the MD5 hash of the decoded files to the source, and on those where there were no extra RIFF headers they matched (you wouldn't expect a match on the others).  Perhaps someone who uses FLAC may want to do a more comprehensive test?
I'm on a horse.

FLAC 1.1.3 settings

Reply #14
synthetic soul's reply answered everything perfectly.

user, I think you're making too much out of a little thing here, the -A bug only affects you if your locale doesn't use '.' for the decimal point, and then the worst is that the compression is the same as 1.1.2 would be unless you add the correctly-formatted -A option (simple workaround).  all other switches are the same as they have always been.  it's not any worse than using 1.1.2 so I don't see the need to pull 1.1.3 or go back to 1.1.2.

Josh

FLAC 1.1.3 settings

Reply #15
I suggest as solutions, to remove the dangerous flac1.1.3 from public download pages,
and replace by some bug-free version eg. that one of Case, or is there already another official one ?
If this solution cannot be made for some reason,
then it is better to stick to 1.1.2 and offer no 1.1.3-update-bug-fixed-version, until such an update/bug-free version is available.


Calling it "dangerous" is unnecessary.  It doesn't cause bad audio, or effect the losslessness.  When the bug is triggered, it just doesn't compress as well.

-brendan

FLAC 1.1.3 settings

Reply #16
okay, dangerous is a vocable used as non-native speaker, call it suboptimal then. Obviously I meant "dangerous" not in a technical Lossless sense, but in the sense of flac's reputation to a broader public.
If the output of bugged 113 has same size as 112 (iirc, I read in other topics, that 113 made bigger files even than 112) with same setting like -8 vs -8 or -5 vs -5, it's still okay, though.. suboptimal, as the 113 flac is very promising and surely the step forward regarding "competition" with other Loslsess formats like ape, wavpack.  Soon I'll try 113 or whats availble then eg. by Case and try out, how it performs on a standard winXP_non_UK system, which should be affected by the locale thing.
My concern as described above targets the broader public who doesn't read here, as someone else described here at HA, the comma locale guys might be more widespread, than English or Northern Americans think.

FLAC 1.1.3 settings

Reply #17
I don't understand the reluctance to fix the bug even if its no 'big deal'. After all its best dealt with now before everyone gets around to updating.

 

FLAC 1.1.3 settings

Reply #18
My concern as described above targets the broader public who doesn't read here, as someone else described here at HA, the comma locale guys might be more widespread, than English or Northern Americans think.
Yes, the comma local guys might be more widespread, but seriously, if comma locale guys don't specify the 'bugfix'... how worse off will they be?

If the difference is only in the order of 0,1% (heh, yes I'm a comma-locale), I don't really think anyone will care.


FLAC 1.1.3 settings

Reply #20
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
Code: [Select]
 -5 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=EAC Flac 1.1.2 -5" %s

Should I just stick to this setting or is there any settings I can add? If so please post the edited string, for a quick cut & paste. Thx guys.

FLAC 1.1.3 settings

Reply #21
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
Code: [Select]
 -5 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=EAC Flac 1.1.2 -5" %s

Should I just stick to this setting or is there any settings I can add? If so please post the edited string, for a quick cut & paste. Thx guys.


Why save the codec in a comment tag? FLAC already stores the encoder version in a tag.

FLAC 1.1.3 settings

Reply #22
Why save the codec in a comment tag? FLAC already stores the encoder version in a tag.

Eh, some people like to put it where they can easily see it. Notice he also says "EAC" there. I do a similar thing, except also add my initials and date so I can easily sort and recall what bits of my music came from where.

AFAIK "comment" = whatever you feel like putting there.

FLAC 1.1.3 settings

Reply #23
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
Code: [Select]
 -5 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=EAC Flac 1.1.2 -5" %s

Should I just stick to this setting or is there any settings I can add? If so please post the edited string, for a quick cut & paste. Thx guys.
If you use the comma as your decimal separator you will want to add -A tukey(0,5).  So:

Code: [Select]
 -5 -V -A tukey(0,5) -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=EAC Flac 1.1.3 -5" %s
I'm on a horse.

FLAC 1.1.3 settings

Reply #24
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
Code: [Select]
 -5 -V -T "ARTIST=%a" -T "TITLE=%t" -T "ALBUM=%g" -T "DATE=%y" -T "TRACKNUMBER=%n" -T "GENRE=%m" -T "COMMENT=EAC Flac 1.1.2 -5" %s

Should I just stick to this setting or is there any settings I can add? If so please post the edited string, for a quick cut & paste. Thx guys.


using 1.1.3 here is the string for EAC that I reccomend for those using a period as a decimal.
Code: [Select]
-8 -A tukey(0.25) -A gauss(0.1875) -b 4096 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


and here is the same EAC string for those using a comma as a decimal
Code: [Select]
-8 -A tukey(0,25) -A gauss(0,1875) -b 4096 -V -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


Yes this compression string takes longer, but if does give better compression then -5 and once done, you'll be saving disk space.