libFlake, libFLAC, flake & FLACCLCan anyone explain what the difference(s) are please?
I'm worried about compression
0% compression thank you!
Wait...so my FLAC audio player extracts the song from the FLAC file before it's played?
I see I see, is this why when I open FLAC files in VLC the first few seconds of the song are cut off sometimes? If you REplay it the first few seconds will be there, and foobar seems to "fade" the first few seconds.
ALSO, the bar above "Go' that says 0-8 is that compression/quality/priority? Best quality 0 or 8? lol
"and foobar seems to "fade" the first few seconds."
and the tracks/FLAC files re-written in level 8 compression mode with no quality loss of "re-compressing" ??
the greater the compression of the FLAC file, the more CPU/memory it is likely to use when you are PLAYING that file.
-V or VERIFY switch/parameter... which encodes a bit of audio, then immediately turns back around and decodes it... then compares it to the source file (either in memory still or on disk)
Quote from: Chinch on 27 March, 2012, 06:08:57 AMthe greater the compression of the FLAC file, the more CPU/memory it is likely to use when you are PLAYING that file.Nope, FLAC decodes at practically the same speed regardless of compression level (and it is very fast). If you look at http://flac.sourceforge.net/comparison_all_procdectime.html , the differences are miniscule, and it isn't even so that better compression takes longer time.
As for checking lossiness, it is easier to use foobar2000's bit comparator than md5ing files (which could fail due to headers and tags and whatnot ... actually, fb2k's bit comparator might at worst give miniscule differences due to roundoff errors on mp3 files, but you will usually not use it for those cases anyway).
I used foobar2000's Binary Comparator (I can't recall if it is stock or an add-on, sorry)... but this compares the exact same thing... it disregards any NON-AUDIO data, and compares ONLY the audio within both files. I compared the original FLAC file, with the re-encoded (larger) FLAC output file, with the same results... identical files, no differences found:All tracks decoded fine, no differences found.Comparing:FILE1.FLACFILE2.FLACNo differences in decoded data found.
I'll have to look at your charts a bit later, but to say such a thing would make one ask "if it isn't even so that better compression takes a longer time", then why would the option even exist
I was encoding back to FLAC, and noticed 0 and 8 were taking about the same amount of time. Now, I have a good enough machine to know that it's not being utilized to its potential, by far.I watched the flac.exe encoder task run... and the CPU load never went above 15%. Now, I have an i7 quad-core with HT, so it shows up as 8 cores in task manager/apps. Then I realized that this reference build of FLAC encoder is dated 09/17/2007! That's a 5 year old compile! Then I realized more... of course it's not going to be multi-threaded, let alone optimized to utilize multiple CPU cores!
All in all, the actual DECODE of the 800MB (nearly) CD was so fast that it finshed before I hit START on my stopwatch, LOL.