similar to: [Flac-users] Settings to get the best compression

--- Chris <cl@enposte.net> wrote: > What are the settings that will give the absolute best compression? > It doesn't have to stream, and encodeing speed is not a factor. > I also don't care how long it will take to encode. flac --super-secret-totally-impractical-compression-level No joke, but you will soon find out that it is not worth it and will go back to -8. The -#

--- Chris <cl@enposte.net> wrote: > What are the settings that will give the absolute best compression? > It doesn't have to stream, and encodeing speed is not a factor. > I also don't care how long it will take to encode. flac --super-secret-totally-impractical-compression-level No joke, but you will soon find out that it is not worth it and will go back to -8. The -#

On Thu, Jun 12, 2003 at 09:04:40AM -0500, David W. Tamkin wrote: > Josh suggested to Chris: > > > flac --super-secret-totally-impractical-compression-level > > Now it's not a secret any more! (OK, to those who can read the code, it > never was.) > > >No joke, > > The existence of the option isn't, but its performance pretty much is, > as Josh

Early this past week, Miroslav Lichvar suggested for me: > Ok, you need 0.04% improvement, that should not be a problem. Try > flac --lax -e -p -l 32 -r 10 --no-padding Thank you again, Miroslav. I tried that, and it took almost two full days (surprisingly, Windows ME stayed up that long without crashing) to re-encode the entire set on my 266-MHz machine. After all, in the help file

Miroslav Lichvar wrote: > Ok, you need 0.04% improvement, that should not be a problem. Perhaps a little more than that, since the sizes I listed were after stripping out the padding and all metadata blocks except SEEKTABLE and STREAMINFO. > Try flac --lax -e -p -l 32 -r 10 --no-padding > and if it is not enough, increase -r up to 16. Thank you. I'll do that. What, though,

If processing time is not a big factor -- say, I could put up with four to six times the duration of compressing at -8 -- what command-line settings could one use to get even more compression? I have a case where the FLACs encoded at -8 are about 653.3 MB, but the set comes with artwork whose jpegs are 50.5 MB (I tried zipping the jpegs, realizing it would do very little, and the zip file

I have had this happen to me once: Encoding of a .wav file was interrupted somehow, so an incomplete .flac flie was generated. I accidentally ran a decode on that .flac file, which wiped out the original .wav file. I suggest that flac adopt one of the following to handle the situation that an output file is specified with -o or implied, and the output file already exists: 1. rename the

On Tue, 27 May 2003, benny k. wrote: > I'm a little embarrased because its just a hack on metaflac, but if you > want it, i'll post it one my webpage. it should be easy to modify it for > use with a CD image. Why don't you submit to the sourceforge feature request queue as a patch? That way it will be there for anyone who wants to hack on it. Although maybe this kind of

On Sun, Apr 06, 2003 at 04:40:42PM -0500, David W. Tamkin wrote: > If processing time is not a big factor -- say, I could put up with four > to six times the duration of compressing at -8 -- what command-line > settings could one use to get even more compression? > > I have a case where the FLACs encoded at -8 are about 653.3 MB, but the > set comes with artwork whose jpegs

On Sat, Apr 12, 2003 at 05:49:06PM -0500, David W. Tamkin wrote: > Early this past week, Miroslav Lichvar suggested for me: > > >Ok, you need 0.04% improvement, that should not be a problem. Try > >flac --lax -e -p -l 32 -r 10 --no-padding > > Thank you again, Miroslav. I tried that, and it took almost two full > days (surprisingly, Windows ME stayed up that long

2007/10/15, David W. Tamkin <dattier@panix.com>: > > Harry, > > > so i was wondering what advantages it could give me to make a ffp > > file, because there is already a internally stored md5 checksum on the > > decoded audio data inside the flac file? > > Testing the .flac file against its internally stored fingerprint lets > you know that you have a

On Wed, 28 May 2003, Josh Coalson wrote: > interesting idea, CD-TEXT is in the subcode and if cdrdao can > split it out that's better I think than hacking the CUESHEET > block to store CD-TEXT. I suppose the ideal would be to have a metadata block to store the subcode from a CD, and something that could interpret it as CD-TEXT, if that's what it is. Then it would be possible to

I've just started to archive my CD collection (about 800 CDs), and my criteria are pretty much the same as the original message under this subject, except that I'm doing one file per CD. One file per song is just too much of a pain, and there's really no need, given FLAC's ability to have metadata in the file. The first thing I do is run cd-discid against the cd, and store that

This may be more a question about the pseudo-DOS command line than about flac itself, but at this point I don't really know. How can one direct the output of flac -t to a file instead of the screen? Often I'd like to verify a large number of flac files, and Speek's front-end is very good for writing up the batch file for that (flac -t itself doesn't seem to expand wildcards on

If one is running flac under Windows and invoking it at a command.com prompt, does flac -t return an exit status that command.com can use to determine its next move (such as logging whether the flac file being tested passed or failed)? Meanwhile, I discovered the pause command; by editing that into the batch file between invocations of flac -t, at least I won't miss any results before they

make sure to use --ogg when encoding: flac -V --ogg -o file.ogg file.wav --- Keith <keith105@yahoo.com> wrote: > I am running flac 1.1.0 under Fedora Core 1 Linux and have encoded a > .wav file using the following command: > flac -V -o file.ogg file.wav > I then try to decode it with the following command: > flac -d -o file2.wav file.ogg > and

First, many thanks to Kerry Hoath (and some to a friend who is not on this list, but mostly to Kerry) for help with my batch file question. It's working, pretty much, but I'm still tweaking it, and I'll share the results when it's polished to my satisfaction. Related question: according to the longer help file, if you use the "verify" option during encoding, flac checks

I''ve been looking for the definitive answer for months now, and the RSpec book doesn''t touch on it at all: How do we now handle stubbing out rendering of partials in view specs in RSpec2? I have a large (35K+ lines of views and related specs) that I''m trying to upgrade to Rails3/RSpec2. My views use partials pretty extensively and this issue is a huge blocker for me.

Two wavs I tried to encode tonight got errors near their ends, saying something like "skipped unknown sub-chunk 'LIST'." These occurred at 97% into one file and 98% into the other. If I hadn't brought the DOS command window to the foreground and hadn't been at the monitor watching before these warnings were scrolled away by the displays from work on other files in the

When I asked, | > If you're going to run flac -t later to test | > the .flac file, isn't it redundant to have verification on during | > encoding? Fearless Leader Ace Coalson responded, | yep. OK. | > If you know ... that -V was used | > during encoding and that flac reported "Verify OK," is there any | > reason to test the file? | nope, unless you suspect