IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
FLAC 1.1.3 settings, Best settings?
JWolf
post Nov 1 2006, 18:20
Post #1





Group: Members
Posts: 65
Joined: 3-May 05
Member No.: 21842



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.
Go to the top of the page
+Quote Post
Egor
post Nov 1 2006, 18:46
Post #2





Group: Members
Posts: 826
Joined: 29-September 04
Member No.: 17374



CODE
flac.exe --best --cuesheet=sheet.cue --tag-from-file=CUESHEET=sheet.cue

The "--best" option indubitably proves that my parameters string is the best tongue.gif
Go to the top of the page
+Quote Post
jcoalson
post Nov 2 2006, 00:04
Post #3


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



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
Go to the top of the page
+Quote Post
graue
post Nov 8 2006, 21:45
Post #4





Group: Members
Posts: 22
Joined: 24-June 06
Member No.: 32195



I didn't realize the -A option could be used multiple times.
Go to the top of the page
+Quote Post
Synthetic Soul
post Nov 8 2006, 23:46
Post #5





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (graue @ Nov 8 2006, 20:45) *
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.

This post has been edited by Synthetic Soul: Nov 9 2006, 12:53


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
graue
post Nov 12 2006, 07:11
Post #6





Group: Members
Posts: 22
Joined: 24-June 06
Member No.: 32195



The rectangular window is well worth it when encoding 8-bit audio.
Go to the top of the page
+Quote Post
JWolf
post Nov 13 2006, 02:24
Post #7





Group: Members
Posts: 65
Joined: 3-May 05
Member No.: 21842



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.
Go to the top of the page
+Quote Post
BoraBora
post Nov 13 2006, 20:01
Post #8





Group: Members
Posts: 116
Joined: 17-November 04
From: Paris, France
Member No.: 18179



QUOTE (JWolf @ Nov 1 2006, 18:20) *
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?
Go to the top of the page
+Quote Post
jcoalson
post Nov 13 2006, 23:51
Post #9


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



the difference is probably due to the blocksize more than anything else.
Go to the top of the page
+Quote Post
windmiller
post Dec 2 2006, 06:10
Post #10





Group: Members
Posts: 205
Joined: 6-March 04
From: Chapel Hill, NC
Member No.: 12500



1.1.3 final has been released

This post has been edited by windmiller: Dec 2 2006, 06:10


--------------------
www.losslessaudioblog.com
Go to the top of the page
+Quote Post
user
post Dec 4 2006, 17:26
Post #11





Group: Members
Posts: 873
Joined: 12-October 01
From: the great wide open
Member No.: 277



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?

This post has been edited by user: Dec 4 2006, 17:31


--------------------
www.High-Quality.ch.vu -- High Quality Audio Archiving Tutorials
Go to the top of the page
+Quote Post
Synthetic Soul
post Dec 4 2006, 17:59
Post #12





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



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.

This post has been edited by Synthetic Soul: Dec 4 2006, 18:05


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
user
post Dec 4 2006, 19:54
Post #13





Group: Members
Posts: 873
Joined: 12-October 01
From: the great wide open
Member No.: 277



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 ?

This post has been edited by user: Dec 4 2006, 20:10


--------------------
www.High-Quality.ch.vu -- High Quality Audio Archiving Tutorials
Go to the top of the page
+Quote Post
Synthetic Soul
post Dec 4 2006, 20:10
Post #14





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (user @ Dec 4 2006, 18:54) *
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

QUOTE (user @ Dec 4 2006, 18:54) *
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.

QUOTE (user @ Dec 4 2006, 18:54) *
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.
Go to the top of the page
+Quote Post
jcoalson
post Dec 4 2006, 20:46
Post #15


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



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
Go to the top of the page
+Quote Post
bhoar
post Dec 4 2006, 20:52
Post #16





Group: Members (Donating)
Posts: 612
Joined: 31-May 06
Member No.: 31326



QUOTE (user @ Dec 4 2006, 13:54) *
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

This post has been edited by bhoar: Dec 4 2006, 20:52


--------------------
Hacking CD Robots & Autoloaders: http://hyperdiscs.pbwiki.com/
Go to the top of the page
+Quote Post
user
post Dec 4 2006, 21:13
Post #17





Group: Members
Posts: 873
Joined: 12-October 01
From: the great wide open
Member No.: 277



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.

This post has been edited by user: Dec 4 2006, 21:21


--------------------
www.High-Quality.ch.vu -- High Quality Audio Archiving Tutorials
Go to the top of the page
+Quote Post
quackalist
post Dec 4 2006, 21:13
Post #18





Group: Members
Posts: 42
Joined: 18-July 03
Member No.: 7846



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.
Go to the top of the page
+Quote Post
pepoluan
post Dec 5 2006, 13:12
Post #19





Group: Members
Posts: 1455
Joined: 22-November 05
From: Jakarta
Member No.: 25929



QUOTE (user @ Dec 5 2006, 03:13) *
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.


--------------------
Nobody is Perfect.
I am Nobody.

http://pandu.poluan.info
Go to the top of the page
+Quote Post
Egor
post Dec 5 2006, 13:15
Post #20





Group: Members
Posts: 826
Joined: 29-September 04
Member No.: 17374



QUOTE (pepoluan @ Dec 5 2006, 18:12) *
if comma locale guys don't specify the 'bugfix'... how worse off will they be?

about one percent for the -8 level.
Go to the top of the page
+Quote Post
mario620
post Dec 7 2006, 21:04
Post #21





Group: Members
Posts: 62
Joined: 4-September 03
Member No.: 8679



I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
CODE
-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.

This post has been edited by mario620: Dec 7 2006, 21:05
Go to the top of the page
+Quote Post
Jebus
post Dec 7 2006, 23:04
Post #22





Group: Developer
Posts: 1293
Joined: 17-March 03
From: Calgary, AB
Member No.: 5541



QUOTE (mario620 @ Dec 7 2006, 12:04) *
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
CODE
-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.
Go to the top of the page
+Quote Post
Klyith
post Dec 8 2006, 05:31
Post #23





Group: Members (Donating)
Posts: 352
Joined: 10-July 04
From: Albany NY USA
Member No.: 15259



QUOTE (Jebus @ Dec 7 2006, 17:04) *
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.
Go to the top of the page
+Quote Post
Synthetic Soul
post Dec 8 2006, 08:30
Post #24





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



QUOTE (mario620 @ Dec 7 2006, 20:04) *
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
CODE
-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
-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


This post has been edited by Synthetic Soul: Dec 8 2006, 08:31


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
JWolf
post Dec 12 2006, 14:06
Post #25





Group: Members
Posts: 65
Joined: 3-May 05
Member No.: 21842



QUOTE (mario620 @ Dec 7 2006, 15:04) *
I just downloaded the latest build (Dec 1 2006 - 1.1.3b). This is the string I use in EAC.
CODE
-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
-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
-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.
Go to the top of the page
+Quote Post

2 Pages V   1 2 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th July 2014 - 12:52