FLAC 1.1.4 is released; see the download page (http://sourceforge.net/project/showfiles.php?group_id=13478) and latest comparison (http://flac.cvs.sourceforge.net/*checkout*/flac/flac/doc/html/comparison.html). The windows installer for 1.1.4 is not ready yet but should be along soon. If needed you can replace the binaries from the current (1.1.3) installer with the ones in the 1.1.4 .zip on sourceforge.
The main features of this release:
- Compression improvements in all modes (-0 .. -8) with no change to the format or decrease in speed
- Speed increases for all modes, both encoding and decoding. Encoding at -8 is twice as fast as in 1.1.3
- New --warnings-as-errors option for flac
- Simpler alternative form for --picture/--import-picture-from options
- Several bug fixes (apodization locale bug, FLAC-to-FLAC transcoding, etc)
- Reduced memory requirements
The complete changelog is at http://flac.cvs.sourceforge.net/*checkout*.../changelog.html (http://flac.cvs.sourceforge.net/*checkout*/flac/flac/doc/html/changelog.html)
Developers will be happy to know the API is unchanged!
Very nice work Josh. Some great improvements and fast bug-fixing.
BTW thanks to you and all the others for the alpha testing! The feedback was very helpful in tuning.
for downloaders, here are the checksums:
MD5
ffe547e92417fcd90877f66412726acf flac-1.1.4-devel-win.zip
77407be9247f8420d0e88a061917ee90 flac-1.1.4-linux-i386.tar.gz
9452a95cf9e5cc65b3e50c2bee2b6eaa flac-1.1.4-osx-ppc.tar.gz
496d4aa3b6f74a23b5b84f8da9e65c61 flac-1.1.4-win.zip
3958cbd5b6ed8c14966792538e44223b flac-1.1.4.tar.gz
SHA-1
bdf8dcc23000c76466b6b08a0b32faa1ea2e5b32 flac-1.1.4-devel-win.zip
6ed7490970a297ee08013d722a5580b254f008a9 flac-1.1.4-linux-i386.tar.gz
3cd3296c11f87777cf24990b78c108efd16a6320 flac-1.1.4-osx-ppc.tar.gz
92b7a20eae4aa4d12b71dd6c365015e77309209d flac-1.1.4-win.zip
b4ce77a96d7ec89a1555b016d90ad4899e613141 flac-1.1.4.tar.gz
Thank you for all your hard work.
Thank you very much for your hard work, Josh!
@Synthetic Soul, will your batch file for transcoding from FLAC v1.1.2 to v1.1.3 work with the new v1.1.4? I was just going to move all my FLAC files to v1.1.3 when Josh released this new version! Now, I can't wait until I transcode to v1.1.4 (Thank you for your excellent work too ).
The batch file (http://www.synthetic-soul.co.uk/files/flac-113.bat) from Synthetic Soul will work. You just have to change the version string "flacVersion=113" to "flacVersion=114".
Thanks to Josh!
WOW! So many great improvements in so little time. Thanks for the effort, Josh!
Thanks a lot for your hard work, Josh!
I'm using FLAC v1.1.3 and feel good, and I'm so excite v1.1.4 roll out so fast, hope that the Foobar2000 and Audition filter update will be out soon.
I am surprised with the release so fast after 1.1.3. Great the dot/comma issue has been resolved.
I want to thank you and those who collaborate(d) for this fantastic compressor and all the dedicated efforts. FLAC is my preferred encoder and it will be for a long time (I think). Hopefully FLAC will become that popular that car radio manufacturers will implement it (besides Vorbis Ogg).
It's fascinating to see how, over the years, development activity (and interest in general) has shifted to lossless audio codecs. I realise that this is almost only isolated to the Hydrogenaudio crowd but it might announce a more global trend now that harddisks are getting bigger and cheaper. Anyway, I'm glad I made the switch to Flac a couple of years ago! If only I could find the time to re-encode my files to 1.1.4 ... .
Josh keep up the great work!
Thanks for your work, Josh. It's nice too see what a big improvement you could achieve in the last couple of weeks.
Btw, just in case it went unnoticed, a possible bug report has been posted in the "General Audio" section, here (http://www.hydrogenaudio.org/forums/index.php?showtopic=52618).
tnx,
quick test 1.1.3 vs 1.1.4 (using defaults: flac.exe file.wav) on 92 small files;
1.1.4
92 File(s) 459.040.498 bytes
1.1.3
92 File(s) 472.138.921 bytes
tnx,
quick test 1.1.3 vs 1.1.4 (using defaults: flac.exe file.wav) on 92 small files;
1.1.3
92 File(s) 459.040.498 bytes
1.1.4
92 File(s) 472.138.921 bytes
So flac 1.1.4 compresses worse than 1.1.3?
Yes, indeed - Great job you have done on this release also, Josh
I have personally switched back to WavPack, but you forsure deserves some kudo's for your coding skills and motivation for keeping up with all this for so many years
Best regards
CU, Martin
Thanks for this new release Josh!
fairway: nope, typo, fixed.
fairway: nope, typo, fixed.
Wow I would say the compression quite increased a lot! I love Flac. But let's not forget TAK
Has anyone compiled an Intel (or Universal Binary) Macintosh version of this new FLAC 1.1.4 package?
Download link please. Thanks!
AFAIK, ntohl() is defined in <winsock.h> (actually <winsock2.h>) on all versions of VC++, so
#if defined(_MSC_VER) && _MSC_VER <= 1200
should be
#if defined(_MSC_VER)
in bitreader.c and bitwriter.c.
The batch file (http://www.synthetic-soul.co.uk/files/flac-113.bat) from Synthetic Soul will work. You just have to change the version string "flacVersion=113" to "flacVersion=114".
I tried but it won't.
Note that i have OGG-flacs.
Fantastic, what a great year this has been for Flac users, year as in 12 months, not calendar year
and flac -5 vs flac -8 on set of short 70 samples (flac 1.1.4):
70 short files
---------------------------
flac5\ 521.737.686 | render time ~3 minutes
flac8\ 516.297.252 | render time ~7 minutes
orig\ 1.502.251.352
edit, optimfrog v4.600ex defaults
frog\ 480.359.971 | render time ~9 minutes
(render times are really just aprox., decoding speed not tested)
Thanks for your great work Josh
Fantastic work Just after I reencoded to 1.1.3 too At least I can run a full reencode now to 1.1.4 as none of my files are encoded to this yet.
Thanks for the great work.
I'm getting double the speed for -8 encoding now.
One odd thing is that a few files on one of my albums have ended up slightly larger, though the album had an overall decrease so that's allright.
Great job Josh. I definitely appreciate the work you've put into FLAC.
I ran a quick test with Timer on a single image file (soundtrack to 'Finding Nemo') using no parameters (defaults). I have a P4 3GHz with 1GB RAM. If someone provides an optimized ICL SSE build, I'll be happy to test
Original File: 638,775,020 bytes test_image.wav
flac 1.1.3
test_image.wav: wrote 329,487,790 bytes, ratio=0.516
Kernel Time = 3.546 = 00:00:03.546 = 2%
User Time = 62.890 = 00:01:02.890 = 48%
Process Time = 66.437 = 00:01:06.437 = 50%
Global Time = 130.422 = 00:02:10.422 = 100%
flac 1.1.4
test_image.wav: wrote 328,246,889 bytes, ratio=0.514
Kernel Time = 3.625 = 00:00:03.625 = 2%
User Time = 49.406 = 00:00:49.406 = 40%
Process Time = 53.031 = 00:00:53.031 = 43%
Global Time = 123.281 = 00:02:03.281 = 100%
Thanks, Josh!
Excellent stuff Josh
FLAC is, and has been, my lossless encoder of choice since I started using lossless audio compression (~3yrs now).
As I always use the --best (aka -8) switch I'm gonna notice a significant improvement, so that's brilliant.
Keep up the good work
Thanks Josh!
Appreciate all of your hard work and constant efforts to answer problems/questions posted in the forum. FLAC is still my codec of choice for my lossless encoding needs.
JXL
FLAC is my lossless codec of choice too. Hardware support is excellent (SqueezeBox in my case) and I never had a single problem with my FLAC files. Thank you Josh and please keep up the excellent work! I'm trying the new version right now and speed improvements as well as compression improvements really make my day!
thanks for the kind words everyone. I will take a look at that possible replaygain bug.
Another thanks from a FLAC user!! I'm excited about the increase in encoding speed. I've just started last weekend back up my CD collections and this new build will help it go by even faster!! Awesome job!
Great work jcoalson, thx.
Excellent news... so it seems 114 improved everything, which is great.
Now where are updated benchmarks comparing the lossless formats ^^
Not that I care, due to free+HWsupport+established... my support is surely won and I don't really care about other formats anymore..
Was looking forward to this release
Thanks!
Thanks for this new release. I was waiting for it before doing a batch convertion
AFAIK, ntohl() is defined in <winsock.h> (actually <winsock2.h>) on all versions of VC++, so
#if defined(_MSC_VER) && _MSC_VER <= 1200
should be #if defined(_MSC_VER)
in bitreader.c and bitwriter.c.
Thanks Josh!
On a related note: to build with mingw32 (msys) I had to comment out these #ifdefs in bitreader/bitwriter.c so that #include <winsock.h> would be visible to the compiler, and manually add -lwsock32 to the linker options.
Thanks.
Now if only winamp's plugin could get a little love as well...
I've experienced problems when seeking near the end of the song. Also, apparently flac plugin for winamp doesn't support Media Library tags, preventing other plugins from reading the song info (such as albumlist, last.fm, etc...).
Thank you, Josh. Your excellent work is very much appreciated. I have my entire collection in FLAC (200GB) and look forward to 1.1.4. Keep up the good work!
Thank you, Josh. Your excellent work is very much appreciated. I have my entire collection in FLAC (200GB) and look forward to 1.1.4. Keep up the good work!
Just wondering... If your collection is already archived in an earlier version of FLAC, is there any reason to transcode to a newer version, other than to save some additional space?
does this new version fixes this bug here:
http://www.hydrogenaudio.org/forums/index....1287&hl=bug (http://www.hydrogenaudio.org/forums/index.php?showtopic=41287&hl=bug)
i was pretty disturbed with this, and the foobar guy said it's not at their end.
thanks for inputs!
Thank you, Josh. Your excellent work is very much appreciated. I have my entire collection in FLAC (200GB) and look forward to 1.1.4. Keep up the good work!
Just wondering... If your collection is already archived in an earlier version of FLAC, is there any reason to transcode to a newer version, other than to save some additional space?
Good question. I think the new version has some tagging upgrades (album art, lyrics, etc.) and some other improvements (check changelogs to be sure) beyond some space saving that I may take advantage of. I'll probably transcode to 1.1.4 eventually just to save a bit of space, but 1.1.2 has worked great for me. I like to keep on the most recent version if its not too much trouble and to encourage further improvements. If I can gain a few GB of space with an overnight transcode I'll probably do it.
great!
I try soon flac 1.1.4 for encoding my next album CD.
For now, I thank in advance ! for fixing the comma-bug, and especially speed improvements on flac -8 , which i use on my P3-800MHz, I am curious how it works out !
For my amusement (and piece of mind), I did:
Ripped a track to WAV
Encoded to 1.1.3 via FLAC front end using -8
File size was 27.7 mb
Converted via the lil batch program to 1.1.4
File size is 27.5 mb
Used the FLAC 1.1.3 to decode to WAV
Used FC /B to compare source WAV to decoded WAV....
No differences. I am pleased and impressed.
THANKS!!!
I'll probably transcode to 1.1.4 eventually just to save a bit of space, but 1.1.2 has worked great for me. I like to keep on the most recent version if its not too much trouble and to encourage further improvements. If I can gain a few GB of space with an overnight transcode I'll probably do it.
I was in the same boat, well figuratively speaking. My FLAC collection was still in 1.1.2 also. I started my conversion last night and I've been seeing some pretty decent improvements. On quite a few files from 1.1.2 to 1.1.4 I've been seeing as much as a 6% improvement. Although I must say that this is not the norm, on average I'd say the compression advantage I've observed is closer to 2% or thereabouts. 2% of 200GB is 4GB so that's a pretty decent reduction to me. YMMV.
EDIT: Instead of adding a new post, I'll just put my final results here. I ended up saving just over 5GB on my 200GB collection. Which ends up equating to 2.5%.
does this new version fixes this bug here:
http://www.hydrogenaudio.org/forums/index....1287&hl=bug (http://www.hydrogenaudio.org/forums/index.php?showtopic=41287&hl=bug)
i was pretty disturbed with this, and the foobar guy said it's not at their end.
thanks for inputs!
No, this version does not correct that behaviour. As noted in the other thread, if this is an annoyance you can simply use "%s" in place of "-" to create a temporary file, thus avoiding the use of a pipe, and obtain normal seek tables.
- M.
Thanks so much, hugely appreciated.
Offtopic:
How does flake compares to FLAC? Is flake format compatible to FLAC (I mean will FLAC play flake encoded files)?
Some benchmarking...
Versions tested: flac 1.1.2, 1.1.3 and 1.1.4
Compiled for x86_64 GNU/Linux (2.6.18.3 smp)
Settings used: -8 -V
Benchmarked on an AMD 4200+ x2 (dual core 2.2ghz), 2GB pc3200 ram, 74GB Raptor SATA hard drive
Test1, Long track, "Tanya" from Dexter Gordons "One Flight Up" CD (RVG Edition)
-- wave file: 193776620 Bytes or 184.8MB
VER ENC TIME SIZE(Bytes, MBytes) SIZE DECREASE FROM PREVIOUS VERSION
112 2m28s 124323247, 118.283 --
113 1m50s 124118163, 118.368 205084 Bytes, or 0.2MB
114 1m7s 124028937, 118.283 89226 Bytes, or 0.09MB
Test2, Short Track, "Cue" from Yellow Magic Orchestras "Ultimate Collection CD2"
-- wave file: 47886764 Bytes, 45.7MB
VER ENC TIME SIZE(Bytes, MBytes) SIZE DECREASE FROM PREVIOUS VERSION
112 0m37s 29250006, 27.895 --
113 0m27s 28948188, 27.607 301818 Bytes, 0.287MB
114 0m16s 28884496, 27.546 63692 Bytes, 0.061MB
small decrease in file size (always welcome) but more importantly, a very noticeable decrease in encoding time. I would like to know how such a large decrease in encoding time was achieved (different data structure used, etc). Regardless, very well done & thanks!
I'm trying to convert to Flac 1.1.4 using Foobar's custom encoder in the convertor with the flac.exe from the Flac homepage and the following parameters:
-8 %d=%tracknumber%
But Foobar gives the following error:
Error writing to file (Unsupported format or corrupted file) : file://D:\filepath\filename.flac
Do I have some parameter wrong or is it just impossible to do what I want to do?
Just wondering... If your collection is already archived in an earlier version of FLAC, is there any reason to transcode to a newer version, other than to save some additional space?
from 1.1.3->1.1.4 it's just compression improvements. from 1.1.2->1.1.3 support for album art was added.
does this new version fixes this bug here:
http://www.hydrogenaudio.org/forums/index....1287&hl=bug (http://www.hydrogenaudio.org/forums/index.php?showtopic=41287&hl=bug)
no. I wouldn't call it a bug either, in that case flac is being passed an invalid wave file.
How does flake compares to FLAC? Is flake format compatible to FLAC (I mean will FLAC play flake encoded files)?
flake is supposed to generate valid FLAC but it's still alpha and we have found format-related bugs. it's getting better but I would not use it for archiving yet.
I would like to know how such a large decrease in encoding time was achieved (different data structure used, etc)
actually for -8, it was just a better algorithm for estimating encoded residual sizes.
Josh
Congratulations! The speed-up in -8 is impressive!
And thanks for the apodization fix. :-)
Thanks for the update. Also I was wondering if this update would allow Rockbox FLAC decoding to burn less power? (I use Rockbox to play FLAC 1.1.2 -5 files on an iPod Video)
Also is it true that there is no difference in the overhead required to decode from a -5 or a -8 compressed file?
Thanks!
Only if they integrate the 1.1.4 decoding code into Rockbox.
And there's no real difference in decoding speed between the compression levels.
Has 1.1.4 been tested well enough via a test suite and by users (i.e no known bugs) to use in production/archiving of master audio data?
The best thing you can do is make it verify it and compare the MD5 of the audio data with the original audio data.
I was transcoding from flac 1.1.2 to flac 1.1.4 using foobar converter, and noticed that while in most cases the size of the files got smaller, in other cases it grew.
As an example:
Various Artists - SUPER EUROBEAT presents Initial D Fourth Stage D Non-Stop Selection
compressed with flac 1.1.2
607.684.260 byte
compressed with flac 1.1.4
608.449.746 byte
It's rare that the flac 1.1.4 transcode ends up bigger than the flac 1.1.2 encode and for now it only happened for albums encoded as single tracks and not for albums encoded as an image (many tracks get bigger, while others get smaller) and all were encoded with the -8 setting.
Thanks for your time and effort and the great work!
Re-encoding now.
Re-encoding now.
Just curious, what are you using to re-encode? I can't decide between Foobar and Synthetic Soul's .bat file mentioned earlier.
Re-encoding now.
Just curious, what are you using to re-encode? I can't decide between Foobar and Synthetic Soul's .bat file mentioned earlier.
I use Synthetic Soul's .bat file with the additions he mentioned. Works well I'm also reencoding now...
I am using Omni Encoder and Flac 1.1.4 to recode. It works well. I just copied the new 1.1.4 flac.exe over the 1.1.3 one in Omni.
John
is this a bug?
J:\Temp>flac -t test1.flac
flac 1.1.4, Copyright © 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
test1.flac: ok
J:\Temp>
file tests OK
J:\Temp>flac -V test1.flac -o test2.flac
flac 1.1.4, Copyright © 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
ERROR: input file test1.flac has an ID3v2 tag
J:\Temp>
File fails to encode, but tested OK.
J:\Temp>flac -V -F -f test1.flac -o test2.flac
flac 1.1.4, Copyright © 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
ERROR: input file test1.flac has an ID3v2 tag
J:\Temp>
even forcing it fails.
I was able to remove the offending tag with mp3 tag studio 3.05, and it encoded fine then.
I thought for sure that 1.1.4 alpha was able to force encode through this problem but maybe I'm wrong.
FLAC filter updated for Adobe Audition/Cool Edit/Cool Edit Pro to include support for reading and writing of FLAC 1.1.4 format files. Thread with changelog and download link is located here. (http://www.hydrogenaudio.org/forums/index.php?showtopic=52787)
Has anyone compiled an Intel (or Universal Binary) Macintosh version of this new FLAC 1.1.4 package?
Download link please. Thanks!
Is this what you mean?
http://www.rarewares.org/lossless.html (http://www.rarewares.org/lossless.html)
Thank John33!
Has anyone compiled an Intel (or Universal Binary) Macintosh version of this new FLAC 1.1.4 package?
Download link please. Thanks!
Is this what you mean?
http://www.rarewares.org/lossless.html (http://www.rarewares.org/lossless.html)
Thank John33!
I see a WavPack version on Rarewares for Macintosh, but not an Intel Macintosh version listed there for FLAC 1.1.4. I checked there first but saw nothing, that is why I asked here.
Thanks for the great new release :-)
Converted my FLAC filess to 1.1.4 from 1.1.3 over the weekend (-8 to -8), and the ones I reviewed showed a decrease in size of a few percentage points. Thanks for the update, and great work!!!
is this a bug?
...
I thought for sure that 1.1.4 alpha was able to force encode through this problem but maybe I'm wrong.
no, this came up before somewhere else and I gave the long explanation. anyway id3 on flac files is going to get less and less support as time goes on.
oh, I just visited flac sourceforge page, and found out, that the download links for the flac windows installer link to flac1.1.3b , still.
edit: still after edit written in italics bold, so that it should be clearer, that I ask after 1 week of 1.1.4 being public, that the installer is updated for the broad public also. Obviously the techie HA guys know howto use and replace 1.1.3 against 1.1.4, but the JoeAverage out there might download the installer with high probability and get an outdated 1.1.3 with a locale-dot/comma bug. Especially because of this, the 1.1.3 versions should be replaced by 1.1.4 everywhere it is possible. It simply doesn't look nice or proper, if on 1 page is 1.1.4 and on other (even main download location), you get 1.1.3., and the news tell that 1.1.3 would be newest..
Nowhere in this topic is said why the installer isn#t updated yet, jcoalson said only in 1st post, that it isn#t updated yet.
Also the News could be updated, maybe even before the installer package
Currently latest:
news
27-Nov-2006 :
FLAC 1.1.3 released
edited/added also
my quick test:
Encoding Helge Schneider's Katzeklo song 3.05 min.s (yeah, the HA cat lovers ) to Case's flac 1.1.3 (used because of the locale dot comma bug) and to flac 1.1.4 , on windows (xp).
from wav 44.1/16 to flac 1.1.4 -8 -V and to flac 1.1.3case -8 -V
size advantage ca. 0.3% , very nice, (this song compresses to ca. 0.6 of 1400kbit/s raw wave size)
speed advantage even more nice on P3-800 MHz 1.1.3Case took 80s , 1.1.4 took 40s, so that the speedup is really great !!!
(Speed was measured 2-3 times each encoder and averaged.)
big edit 2007-02-23:
I found in flac sub-forum a topic http://www.hydrogenaudio.org/forums/index....showtopic=52863 (http://www.hydrogenaudio.org/forums/index.php?showtopic=52863) referring to the sourceforge flac homepage problem. Obviously, it is due to sourceforge, that it is down, that no updates can be made to that page
If you read the thread it's been explained why it's not been updated.
Using Foobar 0.9.4.2 and a custom converter set for FLAC 1.1.4, this works for me.
-s -8 - -o %d
Ok, where'd the post I was responding run off to?
Using Foobar 0.9.4.2 and a custom converter set for FLAC 1.1.4, this works for me.
-s -8 - -o %d
Ok, where'd the post I was responding run off to?
Hiya,
you may want to change the
-s -8 - -o %d
line to
-s -8 %s -o %d
as I have heard there are some issue with Foobar inserting too many seek points into piped FLAC conversions. See the topic here: http://www.hydrogenaudio.org/forums/index....showtopic=41287 (http://www.hydrogenaudio.org/forums/index.php?showtopic=41287)
Two quesitons. First regarding this post -
Using Foobar 0.9.4.2 and a custom converter set for FLAC 1.1.4, this works for me.
-s -8 - -o %d
Ok, where'd the post I was responding run off to?
Hiya,
you may want to change the -s -8 - -o %d
line to -s -8 %s -o %d
as I have heard there are some issue with Foobar inserting too many seek points into piped FLAC conversions. See the topic here: http://www.hydrogenaudio.org/forums/index....showtopic=41287 (http://www.hydrogenaudio.org/forums/index.php?showtopic=41287)
Does the coverter have this bug if the custom setting is NOT used? IE if you just choose FLAC from the built in settings?
Second, has anyone had any problems with flac 1.1.4 replaygain tags not being read in foobar? I used REACT2 today to create an album image and had flac scan for replaygain. I know it did cause it warned me that it would create some padding even if --no-padding was used. After I loaded the file into foobar, the RG tags were nowhere to be found. However there was a tag citing the REPLAY_GAIN_REFERENCE was 89 db. So either the tags weren't written (although it seems like they were), or fb2k can't read them. Ideas?
The four de-facto RG tags isn't shown in fb2k's "Properties" dialog, but fb2k still parses them and lists the gain and peak values in the "Properties" section of the "Properties" dialog. FLAC's ReplayGain implementation also sets a "REPLAYGAIN_REFERENCE_LOUDNESS" tag in addition to the four de-factor RG tags and since fb2k dosen't recognice that tag as being a RG tag, then that tag is also listed among the other non-RG tags in the "Metadata" section of the "Properties" dialog.
Does the coverter have this bug if the custom setting is NOT used? IE if you just choose FLAC from the built in settings?
Yes, but it can hardly be called a bug, just a minor annoyance if you dislike unnecessary seekpoints.
The four de-facto RG tags isn't shown in fb2k's "Properties" dialog, but fb2k still parses them and lists the gain and peak values in the "Properties" section of the "Properties" dialog. FLAC's ReplayGain implementation also sets a "REPLAYGAIN_REFERENCE_LOUDNESS" tag in addition to the four de-factor RG tags and since fb2k dosen't recognice that tag as being a RG tag, then that tag is also listed among the other non-RG tags in the "Metadata" section of the "Properties" dialog.
Actually this is a problem that I've been wrestling with for the past year, not just with the new release of flac. I don't understand why fb2k doesn't just read the flac replaygain tags. Is there a way to change the way fb2k parses and uses tags in flac files? Thanks.
Seeing as though Linux can handle the wildcard expansion and FLAC can takes its own format as input, I'm looking at running a simple command line to run through my entire directory structure, but can't find out how to make the command recursive.
Any clues how to do this easily people, I have about 350GB of FLAC's I'd like to convert to 1.1.4 -8
Cheers,
Kristian
EDIT: Whoops, misread your post, your using Linux not Windows
Seeing as though Linux can handle the wildcard expansion and FLAC can takes its own format as input, I'm looking at running a simple command line to run through my entire directory structure, but can't find out how to make the command recursive.
Any clues how to do this easily people, I have about 350GB of FLAC's I'd like to convert to 1.1.4 -8
find /path/to/flacs -name '*.flac' -print0 | xargs -0 flac --verify --best --force
Have fun!
Cheers, I shall give it a go in the next few days
I know a lot of people have asked in this thead and elsewhere why the FLAC home page had not yet been updated to reflect the FLAC 1.1.4 release (the reason being explained already by Josh).
Well I am happy to report that today the FLAC home page got its 1.1.4 update:
http://flac.sourceforge.net (http://flac.sourceforge.net)
I know a lot of people have asked in this thead and elsewhere why the FLAC home page had not yet been updated to reflect the FLAC 1.1.4 release (the reason being explained already by Josh).
Well I am happy to report that today the FLAC home page got its 1.1.4 update:
http://flac.sourceforge.net (http://flac.sourceforge.net)
Unfortunately, the download link (at least for the Windows installer) is still 1.1.3b.
The four de-facto RG tags isn't shown in fb2k's "Properties" dialog, but fb2k still parses them and lists the gain and peak values in the "Properties" section of the "Properties" dialog. FLAC's ReplayGain implementation also sets a "REPLAYGAIN_REFERENCE_LOUDNESS" tag in addition to the four de-factor RG tags and since fb2k dosen't recognice that tag as being a RG tag, then that tag is also listed among the other non-RG tags in the "Metadata" section of the "Properties" dialog.
Well that's the thing. The four RG tags that fb2k usually shows in the 'Properties' tab of the 'Properties' dialog are missing. That's what doesn't make sense. The REFERENCE tag is in the metadata section, but no actual RG tags are present anywhere that I can see. Remember this is flac 1.1.4. I think everything was OK with 1.1.3 when I tested it out.
NOTE: Mp3tag sees the 4 actual RG tags in the 'Extended Tag' info. Why not fb2k then?
The improvement in encoding speed over version 1.1.3 is impressive, but wavpack -hh is still over two times faster than flac --best, and compresses better (478 MiB vs. 491 MiB for Daft Punk's Homework, which is almost 74 minutes long)… Why is FLAC still getting so much more attention by software & hardware developers than WavPack?
Why is FLAC still getting so much more attention by software & hardware developers than WavPack?
Cross platform and seamlessly handles aiff's come first to mind
(almost twice as fast at encoding, not decoding. flac -8 decodes twice as fast as wavpack -hh on x86.)
I don't know about software, but for hardware, it's because of the other things that are more important in that segment, like decode speed, library, momentum. besides, those speeds are on x86 which is irrelevant to consumer electronics.
Josh
Unfortunately, the download link (at least for the Windows installer) is still 1.1.3b.
I'll check with Mike on this...
Well that's the thing. The four RG tags that fb2k usually shows in the 'Properties' tab of the 'Properties' dialog are missing. That's what doesn't make sense. The REFERENCE tag is in the metadata section, but no actual RG tags are present anywhere that I can see. Remember this is flac 1.1.4. I think everything was OK with 1.1.3 when I tested it out.
NOTE: Mp3tag sees the 4 actual RG tags in the 'Extended Tag' info. Why not fb2k then?
There's something wrong on your end, then. I have just tested it out by running the following command-lines with flac.exe v1.14 and metaflac.exe v1.14 :
flac --replay-gain test.wav
fb2k v0.9.4.2 parses the four de-facto RG tags correctly and displays the gain and peak values under : Properties > "Properties".
metaflac --remove-replay-gain test.flac
metaflac --add-replay-gain test.flac
fb2k v0.9.4.2 parses the four de-facto RG tags correctly and displays the gain and peak values under : Properties > "Properties".
If you are running "metaflac --add-replay-gain filename.flac" on files allready loaded into a fb2k playlist, then fb2k will only parse the newly created RG tags when selecting : Tagging > "Reload info from files".
I'm not using metaflac at the moment. I'll do some more testing, but I've already tried two runs with REACT2 in image mode and the RG tags are not being read by fb2k. As I said, they appear in mp3tag so this is strange.
Maybe it's something to do with REACT2 and embedding a cuesheet in the flac file? Martin, can you try an image run with REACT2 if you have it with the options to add RG (not apply it) and embed the cuesheet?
EDIT: I confirmed your procedure above works. So it seems it must be something with the embedded cuesheet. Let me know if you get a chance to test it.
@wraithdu
Please forgive me for saying that you where wrong in my previous post. I had just gone to bed and i was thinking about your issue, and then it hit me that you wheren't talking about track files but about images with embedded cuesheet and that in that case, then you where absolutely right in what you've said, so i immidiately jumped out of my bed and turned on my PC, to retract my previous statement I can now also see by your "Edit" section, that you also thinks that it's about the embedded cuesheet, and in which you are perfectly correct in.
The problem is that fb2k dosen't parse those RG tags when they are defined on an image file with embedded cuesheet. Of course, then track gain couldn't work in this way either, but as atleast album gain would work perfectly, then i wrote a post on the fb2k forum about this issue about 2 month ago, but unfortunetly i didn't get a responce from one of the fb2k developers. The only solution you then have to get your images album gained with REACT and which fb2k also will pick up, is then to setup your react.ini file to run WaveGain.exe on the image and then to let REACT add REM comments to the embedded cuesheet with the RG info, and this will fb2k parse correctly.
Again, sorry for saying that you where wrong before, my friend and i hope that you will please accept my apology for this
CU, Martin.
No offense taken at all Martin
I realise that problems like these are so system/config dependent that people are likely to have different test results. In this case I RG scan my resulting flac image with fb2k so as to have track and album gain tags. In the end I'm just glad to know what the issues was. Thanks for taking the time.
Thank's wraithdu and you are very welcome
CU, Martin.
Just want to say a big thanks to Josh for all FLAC development, past and present.
Just wanted people to know that a new version of the free VUPlayer was out as of today that now supports this new FLAC 1.1.4 version. More info at the thread here:
http://www.hydrogenaudio.org/forums/index....showtopic=53093 (http://www.hydrogenaudio.org/forums/index.php?showtopic=53093)
I've noticed that playback with the in_flac.dll that comes with Winamp 5.33, which uses 1.1.2e libraries I believe, sounds different than with 1.1.4 in_flac plugin. The best way for me to describe the difference is that when I playback .flac files with the 1.1.4 plugin, it sounds as though the equalizer in Winamp is turned off, whereas with the 1.1.2e in_flac, the equalizer settings apply (which makes it sound better on my speakers). Am I missing something here?
I've noticed that playback with the in_flac.dll that comes with Winamp 5.33, which uses 1.1.2e libraries I believe, sounds different than with 1.1.4 in_flac plugin. The best way for me to describe the difference is that when I playback .flac files with the 1.1.4 plugin, it sounds as though the equalizer in Winamp is turned off, whereas with the 1.1.2e in_flac, the equalizer settings apply (which makes it sound better on my speakers). Am I missing something here?
There is an official Winamp FLAC 1.1.4-based decoder plugin forthcoming.
A plugin does not need to be 'official' for the EQ to function. Jerethi, why can't you tell for sure if equalizing is performed? Just raise some bands and check the difference.
I'm using the old 1.0beta6a built on 2003-05-06 and the EQ works.
if a decoding plugin has to do something special (I'm not sure why) to make the equalizer work, the reference plugin is not doing it.
Josh
is this a bug?
...
I thought for sure that 1.1.4 alpha was able to force encode through this problem but maybe I'm wrong.
no, this came up before somewhere else and I gave the long explanation. anyway id3 on flac files is going to get less and less support as time goes on.
Sorry for the late reply, but...
If this is not bug, why does flac -t not return an error, but trying to re-encode it fails?
IMO, if flac won't re-encode it, then flac test should fail.
I will have to dig up and re-read the long explaination, but I don't quite understand why even if flac does not support id3 metadata writing/updating/etc, it still should not fail to decode/re-encode because of it.
In any case, if id3 tags will continue to fail re-encodes in the future, then at least please make test fail as well so they are consistent results.
Howdy,
When will the Windows Installer be updated?
It has been ages since released and still 1.1.3 is up!
Thanks
I know, sorry about that. the last word I had from Mike is that he's still having problems getting DLLs registered on vista.
I dLoaded the 1.1.4 zip file, unzipped it, opened the bin directory. I copied the 4 .exe files to the same place in the installed flac 1.1.3 version (renamed the existing extensions to .113 first) and did the same with the .dll to the Winamp/Plugins directory.
It seemed to work (although I am having some weirdlies with Winamp now, but I upped it to 5.33 after).
Is this how to get v1.1.4 without the installer? Anything else need to be done?
I dLoaded the 1.1.4 zip file, unzipped it, opened the bin directory. I copied the 4 .exe files to the same place in the installed flac 1.1.3 version (renamed the existing extensions to .113 first) and did the same with the .dll to the Winamp/Plugins directory.
It seemed to work (although I am having some weirdlies with Winamp now, but I upped it to 5.33 after).
Is this how to get v1.1.4 without the installer? Anything else need to be done?
Put in your Program Files\Winamp folder: (or provide your own libFLAC.dll)
http://stashbox.org/14137/libFLAC.dll (http://stashbox.org/14137/libFLAC.dll)
Put in your Program Files\Winamp\Plugins folder:
http://stashbox.org/14138/in_flac.dll (http://stashbox.org/14138/in_flac.dll)
This will be included in 5.34
Put them in and checked real quick......seems to have fixed 'er up!
For anybody else, my Winamp problem was that is wouldn't seem to add the .flac files (only the mp3) per album folder. Manually adding got them in, but with limited info; it seemed to read from file names rather than tag info...wasn't good anyway.
All seems well now.......thanks much benski!
Put in your Program Files\Winamp folder: (or provide your own libFLAC.dll)
http://stashbox.org/14137/libFLAC.dll (http://stashbox.org/14137/libFLAC.dll)
Put in your Program Files\Winamp\Plugins folder:
http://stashbox.org/14138/in_flac.dll (http://stashbox.org/14138/in_flac.dll)
This will be included in 5.34
I've just installed this one. Got a problem tho. Winamp crash every time I try to pause a flac file.
Put in your Program Files\Winamp folder: (or provide your own libFLAC.dll)
http://stashbox.org/14137/libFLAC.dll (http://stashbox.org/14137/libFLAC.dll)
Put in your Program Files\Winamp\Plugins folder:
http://stashbox.org/14138/in_flac.dll (http://stashbox.org/14138/in_flac.dll)
This will be included in 5.34
I've just installed this one. Got a problem tho. Winamp crash every time I try to pause a flac file.
Yup, is an old bug which has since been fixed in the latest version of the in_flac 2.0 plugin.
I'm not sure whether Benski will post the updated plugin here or not,
or whether you're just going to have to wait for 5.34.
There's also been a few other changes made to the plugin since then, eg.
FLAC Info Editor: Genre drop-down uses genres.txt, tabbing order fixed, columns rearranged, etc.
I've just installed this one. Got a problem tho. Winamp crash every time I try to pause a flac file.
I also found this bug.
Besides that, it also seems that flac files are not loudness adjusted according to their replay gain values when I use this 1.1.4 plugin. My mp3's are all adjusted fine but flac files aren't.
To test this I manually adjusted the replay gain value for a file (in fb2k) to -15 dB, but it still sounds awfully loud compared to my mp3 files. Strangely though, the file info box correctly shows the replaygain value to be -15 dB. Using the 1.1.2e plugin it all works normally.
Piet
Still no installer?
Update for the Winamp plugin:
I apologize for the previous bugs - we're still in a QA/Beta cycle.
Copy this to your Program Files\Winamp folder (note: no change in this file from previous version a few posts up)
http://stashbox.org/14137/libFLAC.dll (http://stashbox.org/14137/libFLAC.dll)
Copy this to your Program Files\Winamp\Plugins
http://stashbox.org/14467/in_flac.dll (http://stashbox.org/14467/in_flac.dll)
thanks guys
Thanks benski for the quick fix. This new version fixes both the pause-bug and the replaygain issue.
Thanks for the update benksi! Pausing works like a charm now :-)
Found another problem now. When I start a song and goes to the middle or the end of it by clicking the slider sometimes strange things happen. The slider can sometimes jump back to the middle of the song and sometimes it jumps to the very end of the song so it looks like the song is ended (but it's still playing.. and showing positive time counting up instead of negative counting down)
Maybe a bit dizzy writing but it's late and I hope you get it
Found another problem now. When I start a song and goes to the middle or the end of it by clicking the slider sometimes strange things happen. The slider can sometimes jump back to the middle of the song and sometimes it jumps to the very end of the song so it looks like the song is ended (but it's still playing.. and showing positive time counting up instead of negative counting down)
Strange. No-one can reproduce this. Are you maybe using some 3rd-party output plugin (eg. out_ks or out_asio)?
The official winamp flac plugin also doesn't properly works with Last.fm or Albumlist (http://albumlist.sf.net). I think it has something to do with only partial tag support.
The official winamp flac plugin also doesn't properly works with Last.fm or Albumlist (http://albumlist.sf.net). I think it has something to do with only partial tag support.
By "official winamp flac plugin" do you mean that one that comes with the FLAC distribution, or the one that comes with the Winamp installer (5.33 and up)?
The plugin that comes with FLAC should only be used for older (2.x) versions of Winamp.
Josh: can we get in_flac dropped from the FLAC installer? Starting with Winamp 5.34, users can 'upgrade' FLAC simply by copying a new libFLAC.dll into Program Files\Winamp (unless the FLAC API changes again)
By "official winamp flac plugin" do you mean that one that comes with the FLAC distribution, or the one that comes with the Winamp installer (5.33 and up)?
I mean Nullsoft FLAC Decoder v1.1.2e, included in Winamp 5.33.
Found another problem now. When I start a song and goes to the middle or the end of it by clicking the slider sometimes strange things happen. The slider can sometimes jump back to the middle of the song and sometimes it jumps to the very end of the song so it looks like the song is ended (but it's still playing.. and showing positive time counting up instead of negative counting down)
Strange. No-one can reproduce this. Are you maybe using some 3rd-party output plugin (eg. out_ks or out_asio)?
Could be. I know I've used another output plugin before but not sure what I'm using now. Will try to disable some plugins when I get home in 6 hours or so.
By "official winamp flac plugin" do you mean that one that comes with the FLAC distribution, or the one that comes with the Winamp installer (5.33 and up)?
I mean Nullsoft FLAC Decoder v1.1.2e, included in Winamp 5.33.
The official Nullsoft plugin is now in_flac 2.0 (based on FLAC 1.1.4),
as included with Winamp 5.34 Beta (http://www.hydrogenaudio.org/forums/index.php?showtopic=53402)
Now supports Extended Fields (Album Artist, Composer, Disc#, Publisher, Encoded)
By "official winamp flac plugin" do you mean that one that comes with the FLAC distribution, or the one that comes with the Winamp installer (5.33 and up)?
I mean Nullsoft FLAC Decoder v1.1.2e, included in Winamp 5.33.
The official Nullsoft plugin is now in_flac 2.0 (based on FLAC 1.1.4),
as included with Winamp 5.34 Beta (http://www.hydrogenaudio.org/forums/index.php?showtopic=53402)
Now supports Extended Fields (Album Artist, Composer, Disc#, Publisher, Encoded)
Hi, I've just tried the new version. I'm afraid both problems still persist: Albumlist is unable to retrieve metadata from files (such as the album name, album lenght, etc), and last.fm client doesn't detect winamp is playing.
However, I noticed that while last.fm only has problems with flac files, detecting every mp3 file, albumlist is still unable to retrieve metadata from mp3 files. It was working fine previously, so my guess is that something changed in the 5.33 release.
I can try with other formats to see if the problems still occur, if you require.
Hi, I've just tried the new version. I'm afraid both problems still persist: Albumlist is unable to retrieve metadata from files (such as the album name, album lenght, etc), and last.fm client doesn't detect winamp is playing.
However, I noticed that while last.fm only has problems with flac files, detecting every mp3 file, albumlist is still unable to retrieve metadata from mp3 files. It was working fine previously, so my guess is that something changed in the 5.33 release.
I can try with other formats to see if the problems still occur, if you require.
My guess is that they're not getting metadata the "proper" way. I'll look at the albumlist code (pretty sure it's open source) and see what's going on.
I'm using the new Winamp beta with FLAC 2.0 plugin. When I put FLAC files in the playlist, and Winamp reads the tags (FLAC file info), it shows the entire directory and filename instead of what is in the artist / title field and time.
I'm using the new Winamp beta with FLAC 2.0 plugin. When I put FLAC files in the playlist, and Winamp reads the tags (FLAC file info), it shows the entire directory and filename instead of what is in the artist / title field and time.
Yup, it's listed under the Known Issues section of the 5.34 Beta (http://forums.winamp.com/showthread.php?s=&threadid=267694) thread on the Winamp forums.
Basically, it means that you've disabled Advanced Title Formatting in Winamp > Prefs > Titles
(the beta bug being that this causes the full path & filename to be displayed, instead of just the filename).
To fix it, enable ATF and set a suitable ATF string, eg.
[%artist% - ]$if2(%title%,$filepart(%filename%))
[%artist% - ][%album% - ][$num(%track%,2) - ]$if2(%title%,$filepart(%filename%))
$filepart(%filename%)
or whatever (http://www.myplugins.info/winamp-wiki/doku.php/advanced_title_formatting)
Yup, it's listed under the Known Issues section of the 5.34 Beta (http://forums.winamp.com/showthread.php?s=&threadid=267694) thread on the Winamp forums.
Basically, it means that you've disabled Advanced Title Formatting in Winamp > Prefs > Titles
(the beta bug being that this causes the full path & filename to be displayed, instead of just the filename).
To fix it, enable ATF and set a suitable ATF string, eg.
[%artist% - ]$if2(%title%,$filepart(%filename%))
[%artist% - ][%album% - ][$num(%track%,2) - ]$if2(%title%,$filepart(%filename%))
$filepart(%filename%)
or whatever (http://www.myplugins.info/winamp-wiki/doku.php/advanced_title_formatting)
Didn't think to look in that area, I checked tech support and bug reports though (a few hours ago). Thanks, looks like its already going to be fixed by next version.
Josh: can we get in_flac dropped from the FLAC installer? Starting with Winamp 5.34, users can 'upgrade' FLAC simply by copying a new libFLAC.dll into Program Files\Winamp (unless the FLAC API changes again)
yeah, I asked that Mike keep it out for flac-1.1.4. I would prefer it not be in there anymore.
Found another problem now. When I start a song and goes to the middle or the end of it by clicking the slider sometimes strange things happen. The slider can sometimes jump back to the middle of the song and sometimes it jumps to the very end of the song so it looks like the song is ended (but it's still playing.. and showing positive time counting up instead of negative counting down)
Strange. No-one can reproduce this. Are you maybe using some 3rd-party output plugin (eg. out_ks or out_asio)?
Could be. I know I've used another output plugin before but not sure what I'm using now. Will try to disable some plugins when I get home in 6 hours or so.
A bit more then 6 hours, I know, but now I finally got some time over
Anyway, I used the Directsound output plugin. I've now also tried with the waveout plugin but the same problem there. I also disabled many other plugins that's not standard, but no luck there either. Have tested with many different flac files too.
I recorded a video so it should be a bit easier to see the problem:
http://www.youtube.com/watch?v=yp0CK6wO1t8 (http://www.youtube.com/watch?v=yp0CK6wO1t8)
As you can see it's slow and a bit strange acting overall. One thing you should take a look at is that when I play a file twice in a row it runs perfect the second time. My guess is that there's some king of buffering problem, what do you think?
I also went back to 1.1.2 again to remember what that was like and I saw no signs of delays with the seek bar there.
Hope this info is to some help. I'm glad to help you more if you got any other idea of what could cause the problem
@ ZnOOZer
Can you please confirm that you're using Nullsoft FLAC Decoder v2.0 (as included with Winamp 5.34 Beta Full (http://www.hydrogenaudio.org/forums/index.php?showtopic=53402)), and not the in_flac included with the FLAC 1.1.4 package.
If you are definitely using the latest Nullsoft in_flac, then could you possibly upload a sample flac file somewhere (zip it up first) to eg. sendspace.com and post the link here.
Yep, I'm using the Nullsoft FLAC decoder.
Just found out that the problem doesn't show up when using classic skins, just for the modern ones.
Yep, I'm using the Nullsoft FLAC decoder.
Just found out that the problem doesn't show up when using classic skins, just for the modern ones.
The only modern skin-related problem I've ever experienced resulted out of Desktop Alpha Blending being enabled. It can heavily drain CPU performance, possibly causing Winamp to suffer stability issues while using the FLAC input plug-in. Make sure Alpha Blending is disabled.
I recorded a video so it should be a bit easier to see the problem:
http://www.youtube.com/watch?v=yp0CK6wO1t8 (http://www.youtube.com/watch?v=yp0CK6wO1t8)
As you can see it's slow and a bit strange acting overall. One thing you should take a look at is that when I play a file twice in a row it runs perfect the second time. My guess is that there's some king of buffering problem, what do you think?
I also went back to 1.1.2 again to remember what that was like and I saw no signs of delays with the seek bar there.
Yep, I'm using the Nullsoft FLAC decoder.
Just found out that the problem doesn't show up when using classic skins, just for the modern ones.
Hm, all this reminds me of the behaviour of my TAK plugin if used with Winamp 5.x: Delays of the seekbar (but not of the playback itself), which vanish, if you switch to the classic skin....
The plot thickens....
Alas, we still can't reproduce it
@ TBeck
TAK plugin?
@ TBeck
TAK plugin?
I was talking about the playback plugin i wrote for my lossless audio compressor TAK: TAK Winamp plugin (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=52772&view=findpost&p=472368)
I wrote it for Winamp 2.x, possibly there are some compatibility issues if used for 5.3x?
There is now a newer Nullsoft in_flac v2.0 available via:
Winamp 5.34 Beta, Build 1178 (http://www.hydrogenaudio.org/forums/index.php?showtopic=53402).
in_flac-specific changes
* Fixed: FLAC files showing full path in playlist when ATF is disabled
* Fixed: in_flac trying to play non-existent .flac entries instead of skipping over them
* Fixed: Crash with .flac and .wav files when using CuePlayer plugin
Full changelog (http://forums.winamp.com/showthread.php?postid=2155659#post2155659)
Can someone give tell me the proper way to upgrade from 1.1.3 to 1.1.4, as 1.1.4 doesn't have the installer yet? I've downloaded flac-1.1.4-win.zip, but I'm not sure what to do with the files, and don't want to totally screw up things.
Thanks!!
Simply replace (overwrite) the old executables with the new.
You may want to do a find in Explorer for FLAC.EXE and METAFLAC.EXE if you don't know where the current executables are. If you previously used the installer I would assume "Program Files\FLAC" though.
Still no updated installer. Is there an ETA?
Thanks
Simply replace (overwrite) the old executables with the new.
Thanks for the help. Do I need to do anything with the COPYING.GPL files? (and I'm assuming the files in the Doc folder are just for documentation)
The Nullsoft in_flac v2.0 is updated again and is included in the new build:
Winamp 5.34 Beta, Build 1195 (http://www.hydrogenaudio.org/forums/index.php?showtopic=53402).
in_flac-specific changes
* Fixed: Winamp freezes when seeking paused flac files
Full changelog (http://forums.winamp.com/showthread.php?postid=2157508#post2157508)
Thanks to benski, DJ-Egg and the rest in the Winamp team!
Still no updated installer. Is there an ETA?
sorry, I've had no word from mike lately.
I'm thinking I need to commission a windows installer from some volunteer. I would like to have it be open source and in CVS so I can build it also. if anyone has the NSI (or other suitable) skills and wants to contribute, let me know.
Josh
Still no updated installer. Is there an ETA?
Thanks
I think I will stay with 1.1.3 until that installer is updated
If you already have FLAC then there is no point. Just download the updated executables and replace the old ones. It's not difficult.
Could we or Josh or somebody who assembles a package for Josh, offer a 1.1.4 package for download instead of the windows1.1.3.installer ?
So, instead of the outdated 1.1.3installer, we offer 1.1.4 with a help text file all included in a zip, where which specified files should be copied into, like into windows-system32 directory or what/whereever.
At least, until we have a real 1.1.4installer, this package is a better solution than offering 1.1.3installer.
that's already there, if you follow the (tools only) link on the download page to http://sourceforge.net/project/showfiles.p...ackage_id=12675 (http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12675)
edit: ah, maybe you meant that includes all the extra stuff that is in the installer...
of course, if I write "replace the 1.1.3 installer" with 1.1.4 , then I mean it that way,
as of today, 3rd April, there is still the 1.1.3b installer.
Please, remove this 1.1.3 thing, and replace either with link to normal 1.1.4 download, or zip a small package with txt file, which explains howto "install" flac114.
Links are broken here http://flac.sourceforge.net/download.html (http://flac.sourceforge.net/download.html)
windows installer ready for testing: http://www.hydrogenaudio.org/forums/index....showtopic=54439 (http://www.hydrogenaudio.org/forums/index.php?showtopic=54439)
Thanks for all the great work and also the new installer!
Especially the new feature (since 1.1.3) of embedding pictures is great.
But unfortunately if you want to embed many or very large pictures you'll have a problem:
Since every time you embed a larger image the whole file has to be re-written (unfortunately the metadata are at the beginning of the file) it can take quite a while to embed all images in a large FLAC file. To avoid this you have two choices: either embed all images at one using a very long command line or add sufficient padding.
But either way you may run into problems: When a command line gets longer than 2047 or 8191 characters (depending on your version of windows) it won't work. And as far as I know neither flac.exe nor metaflac.exe accept parameters from a text file (which would solve this problem). For embedding many images (especially with long file names and maybe descriptions) this could get problematic. So I figured that providing for enough padding seems the way to go. But metaflac.exe only allows padding up to < 2^24 bytes (16MB). That may seem a lot - but when you're adding hi-res scans to a complete CD image it often is not enough.
flac.exe doesn't seem to have this limitation, but even with lots of padding metaflac.exe still re-writes the file for (almost) every embedded image...
Any suggestions?
are you saying that if you metaflac --import-picture-from several large pictures, that it will rewrite the file for each picture addition? it's written to only rewrite the file once after all ops have been processed.
I can see the problem with commandline-length limitations. I don't know why the windows limit is so small. on practically every other modern OS this is not a problem.
are you saying that if you metaflac --import-picture-from several large pictures, that it will rewrite the file for each picture addition? it's written to only rewrite the file once after all ops have been processed.
No, I meant that to avoid such long command lines I would like to add every image separately (in a batch file) - after adding sufficient padding first. But even with several times the amount of padding needed (e.g. after adding it while encoding with flac.exe - which seems to allow bigger paddings) metaflac still rewrites the file even when there is more than enough padding left.
It seems to me that not only metaflac can't add such large paddings but either that flac.exe also has a problem with them (without saying so) or that metaflac can't even utilize pre-existing large paddings.
I can see the problem with commandline-length limitations. I don't know why the windows limit is so small. on practically every other modern OS this is not a problem.
Microsoft commented on this problem here (http://support.microsoft.com/kb/830473). Don't know about Vista but I doubt that this has changed. What else would you expect from the "
640 Kilobyte ought to be enough for anybody"-company. I think it would be great if an option could be added to (meta)flac which allows to read other parameters from a text file:
flac.exe --parameter-from-file=<FILE> <INPUTFILE>
This would certainly solve my problem by eliminating the need for huge paddings (although if those would work it would be cool, too ).
Hi Josh,
The new installer seemed to work fine on my XP install. I had the older 1.1.2a installed and it prompted to uninstall it and seemed to work fine. (Nitpick: On the uninstall text from your installer it mentions "Winamp now comes with Flac support, maybe mention a specific version number like "Winamp 5.34 and higher")
Anyway, it looks like the FLAC Frontend tagger component does not have the updated code that was mentioned in this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=53005) to not overwrite the FLAC version string. (With your current installer tagger.exe program overwrites the FLAC version string with 1.1.2 if you tag the file with FLAC Frontend.)
On a different note, the author of the Windows FLAC Tester program, would he allow that program to be included with the Windows installer? I have found that to be a great tool to test my flacs after I back them up to a different drive, etc.
Can anybody confirm that metaflac can't handle such large paddings (even if they were created without error by flac)?
ston3y[=' date='Apr 30 2007, 15:57' post='489198']are you saying that if you metaflac --import-picture-from several large pictures, that it will rewrite the file for each picture addition? it's written to only rewrite the file once after all ops have been processed.
No, I meant that to avoid such long command lines I would like to add every image separately (in a batch file) - after adding sufficient padding first. But even with several times the amount of padding needed (e.g. after adding it while encoding with flac.exe - which seems to allow bigger paddings) metaflac still rewrites the file even when there is more than enough padding left.
there are corner cases where this can happen, e.g. where the padding block would have to be shrunk below the minimum block size (4 bytes). to really tell what's going on I would have to see the 'metaflac --list' output before and after.
Josh
there are corner cases where this can happen, e.g. where the padding block would have to be shrunk below the minimum block size (4 bytes). to really tell what's going on I would have to see the 'metaflac --list' output before and after.
Josh
No problem - but the text files with the output are quite big, so I compressed them with 7-zip.
I will send you a PM with the link as soon as the upload is complete.
It's interesting that after adding over 33 MB of padding (with flac.exe) "metaflac --list" shows no padding block at all, although the padding obviously wasn't used entirely (judging by the increase in size when embedding the images with metaflac). Also when examining the flac file with an hex editor there are still about 32 megabytes of zeros in the flac file...
When filtering seektable and picture blocks (
metaflac --list --except-block-type=SEEKTABLE,PICTURE) the list output gets quite short:
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 0 bytes
maximum framesize: 0 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 126655200
MD5 signature: 00000000000000000000000000000000
METADATA block #2
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.1.4 20070213
comments: 0
Since the streaminfo block looked the same before embedding the pictures, it seems to me that flac.exe already screwed up this file when creating it with this large padding. Here the output after encoding
without extra padding:
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 1326 bytes
maximum framesize: 13798 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 126655200
MD5 signature: 8ed6a82d92937bab05a3e693ccedfc1f
METADATA block #2
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.1.4 20070213
comments: 0
METADATA block #3
type: 1 (PADDING)
is last: true
length: 65536
On a different note, the author of the Windows FLAC Tester program, would he allow that program to be included with the Windows installer? I have found that to be a great tool to test my flacs after I back them up to a different drive, etc.
yes, I added it to the latest installer (flac-1.1.4b.exe)
I just tried the new installer flac-1.1.4b.exe out of curiosity (actually I already had 1.1.4 anyway) and it worked just fine. Except: When you had flac installed previously it uninstalles the old version and deletes the complete folder along with all files in it. Even if those files where not created during the last installation of flac.
There were several rather extensive batch scripts I'm just working on in this folder...
...but fortunately I made a backup right before starting the new (un)installer.
that is a property of mike's old uninstalller I think. the new one I wrote only deletes files that it installed and only removes the c:\program files\FLAC (or whatever) dir if it is empty.
so from now on it will be safer that way.
Josh
the new one I wrote only deletes files that it installed and only removes the c:\program files\FLAC (or whatever) dir if it is empty.
Great, that's much better! Will try it as soon as 1.1.5 is ready.
Good work.
But very slow encoding speed.
Can you define "very slow" ???
Especifically in the context of one of the fast lossless encoders. ( http://wiki.hydrogenaudio.org/index.php?ti...less_comparison (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison) , and note that the speed of FLAC has improved since that table)
FLAC Setting: Preset 8
(http://pixloads.com/public/35190/FLAC.JPG)
WavPack Setting: V high with Max comp mode:
(http://pixloads.com/public/35191/WavPack.JPG)
The True Audio:
(http://pixloads.com/public/35192/TTA.JPG)
@Sina
You should check out this sites:
Synthetic Soul lossless comparison (http://www.synthetic-soul.co.uk/comparison/lossless/)
FLAC comparison (http://flac.sourceforge.net/comparison.html)
FLAC -0 is one of the (if not the) fastest loosless encoders!