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.exe --best --cuesheet=sheet.cue --tag-from-file=CUESHEET=sheet.cue
The "--best" option indubitably proves that my parameters string is the best
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
I didn't realize the -A option could be used multiple times.
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.
The rectangular window is well worth it when encoding 8-bit audio.
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.
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?
the difference is probably due to the blocksize more than anything else.
1.1.3 final (http://flac.sourceforge.net/changelog.html#flac_1_1_3) has been released
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?
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=49182&view=findpost&p=453681) may be of use.
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 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=49182&view=findpost&p=453681) 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 ?
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?
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
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
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.
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.
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.
if comma locale guys don't specify the 'bugfix'... how worse off will they be?
about one percent for the -8 level.
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
-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.
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
-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.
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.
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
-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:
-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 just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
-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.
-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
-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.
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 Lossless quality wise. The differences amongst Loslsess formats or different settings of one L-format, ly between the encoding (sometimes 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 Joe Average (IMHO), 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 Joe Average will downlaod and install obviously latest available release, which is buggy 1.1.3 at the moment ?
What I meant by best settings is the settings that give the best overall compression for the widest range of music/audio. Yes, I know lossless is lossless no matter how it was compressed. Heck, -1 is lossless, but it's far from optimal. I know some don't care about squeezing the last bit out of FLAC 1.1.3. But this thread is not for those people. It's for people like myself who want that extra bit of compression. I do not understand people who feel the need to use say -5 because -8 takes too long to compress. Once the compression is done, it's done and the space savings are permanent. And if you feel you don't have the time to perform better compression, do it at a time when you can just let the computer go and compress. Start it going when you are not really using the computer like say during dinner. I have a bat file I use to recompress my FLAC without losing the tags. I can start it recompressing and then walk away from the computer. If I was to be doing a lot of directories of FLAC files for a recompress I can do it while I'm in bed. There are always solutions to the "It takes too long to compress at a higher compmpression level so I'll do it at a lower one and make larger files" issue.
I agree with you, JWolf. I always try to tweak compression to the extreme maximum (losslessly of course).
Although truthfully, I no longer use FLAC.
That said, I do have a batch file that will compress a directory full of .wav's into FLAC, WavPack, LA, and OptimFrog, choose the smallest, and kill the others.
Losslessly compressing a CD ripped into .wav's took a whole night, but IMO it's worth it.
I'm such a space-saving-freak
I agree with you, JWolf. I always try to tweak compression to the extreme maximum (losslessly of course).
Although truthfully, I no longer use FLAC.
That said, I do have a batch file that will compress a directory full of .wav's into FLAC, WavPack, LA, and OptimFrog, choose the smallest, and kill the others.
Losslessly compressing a CD ripped into .wav's took a whole night, but IMO it's worth it.
I'm such a space-saving-freak
I don't have much of choice. My Rio Karma plays FLAC files so if I want lossless, FLAC is my choice.
pepoluan, how much space do you think you save on average by that method? It sounds too extreme for me!
Even though this bug could hardly be considered critical, I think it should be fixed as soon as possible. I hope a new bugfix version is released soon addressing this issue.
For instance, my locale uses comma for decimal separation, making me subject to the bug. I've compared some files, and while the individual filesize certainly is negligible, in a large library that 1% difference can suddenly become very significant: My library of 934 files is ~172 MB larger using default flac settings (ignoring tukey(0,5)).
I'm sure you agree that makes some difference.