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.


no. I wouldn't call it a bug either, in that case flac is being passed an invalid wave file.


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.


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.

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?



file tests OK



File fails to encode, but tested OK.



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.

Is this what you mean?

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!!!

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 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.


Ok, where'd the post I was responding run off to?

Hiya,

you may want to change the line to 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

Two quesitons. First regarding this post -


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.

Yes, but it can hardly be called a bug, just a minor annoyance if you dislike unnecessary seekpoints.

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

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

Unfortunately, the download link (at least for the Windows installer) is still 1.1.3b.

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?

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

I'll check with Mike on this...

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 :

fb2k v0.9.4.2 parses the four de-facto RG tags correctly and displays the gain and peak values under : Properties > "Properties".

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

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

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.