yeah, this is only for the windows binary, I couldn't get MSVC6 to accept dashes in /D arguments in the .dsp file, even with quoting. the 1.1.3 final will not have this problem since there will be no beta suffix or dashes.

Egor, thanks for the file, will check it out tomorrow.

Josh

I wanted to warn a smaller project, but i cannot seem to find any api documentation of 1.1.3 (the website has the old stuff and can't find anything in cvs).

So were can api documentation be found?

yes, unfortunately the API docs are built from sources at release time and not checked in. the easiest way would be to check out CVS head anonymously:

http://sourceforge.net/cvs/?group_id=13478

...and run Doxygen. or just read the raw porting guide in include/FLAC/all.h:

http://flac.cvs.sourceforge.net/*checkout*...lude/FLAC/all.h

Josh

Would you mind posting your batch file please? I would love to know which of my FLAC files need updating and let the batch file go through them all and update just the ones that need updating.

That function is part of a larger script I use for multi-format flac conversion. You can download my current 1.1.2 compatable package from: http://www.revnull.com/download.php?file=!convert.zip
Just unzip the !convert directory into the root of your flac file directory. Run the flac-util.cmd script and follow the prompts.

Hi everybody,

I was just wondering if the LYRICS tab request (see previous topic pages) has been taken into consideration (maybe it already has). IMHO it should be quite easy to implement (I guess it's just an empty space of a given size, isn't it ?).

Josh ? Any news on that matter ?

Thanks again / Jose

Hi, support for LYRICS tag has already been added. You can add lyrics text to your flac files like that:
flac.exe --tag-from-file=LYRICS=lyrics.txt (while encoding),
metaflac.exe --set-tag-from-file="LYRICS=lyrics.txt"

If you want to add an empty LYRICS tag, then use following options:
flac.exe --tag=LYRICS="" (while encoding)
metaflac.exe --set-tag="LYRICS="

Thank you!

ok, these look like the WAV files flac used to generate too, they are 6ch WAVEFORMATEX which are technically not allowed but common.

the way I am handling this in flac-1.1.3 is an undocumented option '--channel-map=none' to let flac assume the channels are in WAVEFORMATEXTENSIBLE's order. note that you still have to feed flac a multichannel file that uses one of the legal channel assignments (http://flac.cvs.sourceforge.net/*checkout*...ml#frame_header) if you want to make sure the decoded WAV later has the right channels in the right order with the right channel mask.

Josh

Thanks Egor for your valuable information. Now all we need is music software support for FLAC 1.1.3 including the new "picture" and "LYRICS" tags.

FLAC 1.1.3 is going to ROCK !

Oh BTW, what's the point in adding an empty LYRICS tag ? I don't understand.

An empty LYRICS tag is kinda LYRICS tab you've asked about :

Ooh, sorry, I meant "tag" not "tab" !

My question was just about the use of an EMPTY lyrics tag. As far as I know we are not compelled to tell FLAC to define empty tags for all the other tags (title, album, genre, etc, etc.). They are default-defined (and empty of course until they are filled), and I guess it will be the same for the picture and LYRICS tags.

So I don't see the use in defining an empty lyrics tag, except for deleting the lyrics you don't want anymore of course. Is that what you meant ?

that's right


for that you can use 'metaflac --remove-tag=LYRICS'

another update: 1.1.3 is in final testing now so it should be ready witihin a week or so. updated comparison here:
http://flac.sourceforge.net/comparison.html

Josh

Thanks Josh, that's great news !

No offense intended of course, but as far as I know the information on WavPack given at http://flac.sourceforge.net/comparison.html is a bit outdated isn't it ? Here ( http://wiki.hydrogenaudio.org/index.php?ti...less_comparison ) it seems that WavPack has both streaming capabilities and hardware support. Am I wrong ? (I am not used to WavPack).

yeah, that part does need some maintenance but I fixed some of the glaring stuff.

Sort of off-topic, but the developers page at http://flac.cvs.sourceforge.net/*checkout*.../api/index.html doesn't seem to exist.

You can find the documentation in the latest source tarball (e.g., flac-1.1.3-beta2.tar.gz). See also the quote below:

Have you been in contact with the developers behind taglib? It is a popular open source metadata lib and getting things like lyrics and image support in there means that probably very soon a lot of open source players will support it.

They are working on releasing 1.5 (stable) soon but getting it in now would still be on time judging from the dev-list.

Are there any news regarding the final testing? (...another update: 1.1.3 is in final testing now so it should be ready witihin a week or so...)

Hi all,

I just checked the download site again and flac 1.1.3 is now out and ready to download!

Thanks fairway.

However I don't see any mention of the LYRICS tag in the changelog : http://flac.sourceforge.net/changelog.html.

And the windows installer link ( http://cyberial.com/flacinstaller.asp ) still points to FLAC 1.1.2a : it seems that only the "tools only" link ( http://sourceforge.net/project/showfiles.p...ackage_id=12675 ) has been updated.

You will find the Windows binaries over here:

http://sourceforge.net/project/showfiles.p...lease_id=467249

Same links as the last one I gave up here (same binaries in fact)... Thanks anyway !

Yes, I agree with you, a reference in the FLAC 1.1.3 Docs and CHANGELOG would be nice to let people know that the "LYRICS" tag is the approved tag name for embedding LYRICS in a FLAC file. Josh has posted here that he thinks we should use the LYRICS name for the Tag, plus many others here in this thread have agreed to standadize the tag name on "LYRICS". We need authors to know this so they start supporting an optional LYRICS tag/info along with the new ALBUM ART that the new FLAC version is supporting.

Also a new validated news thread for the FLAC 1.1.3 press release should be started as this thread is for the FLAC 1.1.3 beta, plus it's getting quite long. Just my opinion...

I am waiting on the windows installer from Mike (since that is what most people use) before doing the official announcement, to avoid confusion. but you can get binaries and source for 1.1.3 on sourceforge.

the LYRICS tag is strictly a user issue. neither FLAC nor Vorbis specify tagging policy, and the only real recommendations are here. the LYRICS tag as described in this thread is intuitive so I don't see any problem with adoption.

Josh

Thanks Josh for clearing that up about the LYRICS tag. I hope lots of developers start to use/support it in their FLAC files. I just downloaded the FLAC 1.1.3 binary (for Windows). I look forward to your official announcement on your flac.sourceforge.net page as well as in a new thread in validated news here on Hydrogen Audio.

BTW Josh, have you (or your testers) tested the Windows build on the new Windows VISTA latest release build for compatability? Also the same for the Windows installer, as many will have their hands on Vista beginning in about a week (for business customers) and January (for individuals/consumers). Just curious what versions of Windows the FLAC binary and Windows installer have or will be tested on. Is their a Mac OS X build out yet?

Josh, here are some incorrect URLs and newer FLAC supporting extra software that should be corrected in your doc/html directory for your updated FLAC site and also included with the binaries and other distros. These will help more people find these great FLAC supporting programs/tools:

All are from FLAC 1.1.3's doc/html directory:

Filename: download.html - Under the: Extras heading

Under: CD Burning/Windows:
Add: [$] Easy Media Creator 9 Suite - link: http://www.roxio.com/enu/products/creator/...e/features.html
Add: [$] Easy CD-DA Extractor - link: http://www.poikosoft.com/

Under: Players and plugins/Windows:
Edit: Adobe Auditon (as a plugin) link to new link of: http://www.vuplayer.com/audition.php
Add: Song Bird - link: http://www.songbirdnest.com/
Edit: VUPlayer link to new link of: http://www.vuplayer.com/vuplayer.php

Under: Players and plugins/Mac OS X:
Add: Song Bird - link: http://www.songbirdnest.com/

These should help the extra programs list to be more accurate and fix moved/changed links, plus add some new popular apps. The more people that can find major FLAC supporting apps the better for the future long-term success of the FLAC format.

Hope this helps...

There's no Intel build at the moment but in the meantime, XLD has been updated to 1.1.3.

Yup, Easy Media Creator is a major Windows application, that should be mentioned, btw it does other things than just CD burning (audio editor etc.).

Foobar2000 has a native FLAC input/encoding preset support (so it doesn't need a plugin currently).

Yes, and speaking about filters/plugins no longer be required by foobar2000, I just remembered that the latest version of Winamp has their own version of a FLAC decoder and encoder.

I hope the new FLAC Windows Installer (Mike Wren is currently working on) WON'T install the Winamp plugin by default clobbering Nullsoft's built-in FLAC decoder (or encoder).

Also, maybe Josh should mention something in the Windows binaries docs (or README.WIN32 file) that the Winamp plugin should only be used in earlier (pre Windows 5.31) builds of Winamp, to avoid conflicts between it and the native Nullsoft FLAC encoder and decoder.

I compiled 1.1.3 final on Linux from sources downloaded from flac site, and transcoded a few flac files earlier made by 1.1.3beta1 and 1.1.3beta2. I was surprised to find that the file size made by 1.1.3 are larger than those made by 1.1.3 beta1 and beta2. I checked a few files created with 1.1.2, and 1.1.3 produced files of the same size, indeed, very slightly even bigger ones. Embedding pictures, however, worked allright.
Is it just me, or has anyone else had similar experiences?

I have the same experience. I use the precompiled 1.1.3 win32 binaries, and the compression rate is as high as in the 1.1.2 release. But the 1.1.3betas gave me much better compression rates. I also wondered about this! I searched in the docs, but I don't found any explanation for this. So I still use 1.1.3beta2.

Confirmed, 1.1.3-release produces larger files than 1.1.3-beta2:

U2 - How To Dismantle An Atomic Bomb.flac
345988700 1.1.3-beta2
349337313 1.1.3-release

wierd, there should not be any difference in compression between beta2 and final. if someone can host a track (FLAC or WAV), and also post the command line options used to compress, I'll take a look.

Josh

I tested it with several samples and with every sample I get different sizes between the betas and the final version.

So I uploaded a short sample that is shorter than 30s:
http://www.hydrogenaudio.org/forums/index....showtopic=50626

I use -V5 for encoding. I use foobar and there I use that command line option: "-s -5 - -o %d" (standard settings)

If I use flacdrop the sizes are also different. So its likely no foobar problem.

Thank you,

Matthias

there is something fishy about Waiting.flac... it has a big seektable with ~21K of unused seekpoints. this looks to me like a manifestation of an old problem between fb2k and flac (see also SF bug), where fb2k was forging the wave headers with a larger size than necessary (because it didn't know the actual size ahead of time) when encoding to stdout. with this and the extra 60K default padding this would account for ~81K.

but neither of these should come up when comparing 1.1.3-beta2 vs. 1.1.3 final since the code is so similar. And it wouldn't explain Egor's 1% difference.

so I decoded Waiting.flac to wav, then did 'flac -5V Waiting.wav -o cmp.flac' with both the win32 binary releases (beta2 and final) and got almost identical sizes. then I rebuilt from sources on linux and did the same thing and got the same sizes as with the windows build:



the six byte difference between beta2 and final is due to the shorter vendor string.

so I'm not able to reproduce this problem yet.

Josh

Well, I decoded the CD image to a wav file and then reencoded using -5 and -8 switches on an Intel Celeron D and AMD Duron processors. The problem doesn't depend on the processor type. U2's album is definitely worth buying and is available in every music store, I believe.

1.1.3-release (reference libFLAC 1.1.3 20061120)
U2 - How To Dismantle An Atomic Bomb
-5 350552343
-8 349334214

1.1.3-beta2 (reference libFLAC 1.1.3-beta2 20061016)
U2 - How To Dismantle An Atomic Bomb
-5 347846199
-8 345985601


metaflac.exe --list differences (besides the seekpoints):

maximum framesize: 15977 bytes
vendor string: reference libFLAC 1.1.3-beta2 20061016

maximum framesize: 15949 bytes
vendor string: reference libFLAC 1.1.3 20061120

For whatever it's worth, I just now downloaded both the 1.1.3 and 1.1.3beta2 releases and ran a test. The test was done at a command prompt in Win2K using a cd image (Alice In Chains - Dirt) and the -8 setting. I saw the same results as Josh; the beta2 encode was a mere 6 bytes larger than the final, due to the version string.

Edit: Removed an unnecessary return.

Aha, got it!

The problem occurs on systems with a comma as a decimal point symbol.

Are you kidding, or is this serious?

My system locale surely has comma as a decimal point symbol. But how can it affect the filesize?

wow, I don't know how you figured that out, but that could be the problem!

for such a system, can you try adding (note the comma) to the command line somewhere after the -5 and see if that improves the compression? I think it is parsing the internally hardcoded "tukey(0.5)" incorrectly in your locale, and fails back to a rectangular window like flac-1.1.2 used.

Josh

LOL, nice find, Egor. I get the same result when using a french locale. How the hell did you figure that one out?
Josh: adding -A "tukey(0,5)" corrects the issue indeed.

While I'm at it, the xmms plugin from flac 1.1.3 doesn't work anymore. I get this error when launching xmms:

The plugin gets disabled and doesn't show up in the list. Also, oggenc doesn't work anymore either, since it's linked against the old library (which isn't on my system anymore). Any patches coming up?

I've submitted patches to the vorbis-dev list and the package maintainters for flac-1.1.3, maybe I should put them here too.

as for the xmms plugin, did you build from source? (i'm guessing so)... you may need to explciitly link libogg, i.e. change line 67 of src/plugin_xmms/Makefile.am to
also line 33 to
sorry about that.

Josh

Josh,

What patches are you referring to? Is there going to be a build 1.1.3a of FLAC.EXE released to fix this comma and decimal point "tukey(0.5)" encoding problem? I see Mike Wren's installer on the download page listed as flac113a.exe yet the version of FLAC.EXE inside is dated 11-26-2006 and the one inside flac-1.1.3-win.zip is dated 11-28-2006 though they have the same filesize.

Just not sure if we are to expect new Windows builds and developer builds of 1.1.3 or not. I would like to begin distributing code based on 1.1.3 but wanted to make sure a new bug release wasn't coming out soon.

Also Mike Wren's Windows installer has the FLAC Winamp plugin checked by default to be installed even though his own docs say it should not be installed for Winamp 5.31 or later. While it is nice he removed it out of the default installed stuff, still being checked by default many novice users may install it unknowingly and find their Winamp install corrupted with both Nullsoft's (native) and your 3rd party FLAC decoders installed. I think this option should definately be turned off by default (with a click option to turn it on during install instead for those running older Winamp versions who want it). Or just get rid of it entirely, like Mike did with the Foobar 2000 FLAC filter from the FLAC Windows installer package.

Thanks!

Thanks Mike Wren for fixing this within a few minutes of me posting the above about the Windows installer 1.1.3a and the Winamp plugin problem. I see you have now posted version 1.1.3b of the Windows installer on your site for download and made reference to my post above here on Hydrogen Audio in the readme file for the installer.

Even though the Winamp boxes are still checked by default during install options, I tested, and you are correct, no Winamp plugin is being installed. This is to avoid novice users from getting 2 different FLAC decoders installed and a potential conflict in Winamp. Thanks for the fix Mike!

Here's the deal with the Winamp stuff...

The "lite" flavor of the latest version of Winamp doens't include the FLAC output plugin. It doesn't contain the adware/advertising crap for eMusic, either.

However, the "full" flavor of Winamp includes FLAC output, but also the adverts. This presents a problem.

I'd prefer to distribute our own in_flac.dll for any user that doesn't already have it in their Winamp plugins directory... or, maybe better yet... force our latest supercool .dll plugin, since it will probably have more recent updates than the Winamp guys will distribute.

Thoughts?


EDIT: Worst case scenario, is the installer just overwrites the existing in_flac.dll without prejudice... the Winamp-distributed output plugin has the same filename as what we were using, so the results SHOULD be A-OK.

I use Winamp Pro so I don't get the adverts. The Winamp developer (benski?) is very active here on HA and regularly updates his Ogg stuff when new versions are released, so I think he will come out soon with a 1.1.3 FLAC update of the Nullsoft native FLAC decoder. I think you should still make your decoder available (does it support Winamp's ML Media Library? as the previous version didn't I believe). Just not make it checked on by default in the FLAC Windows Installer... Sound good? That way if a person gets the lite Winamp they can install it by clicking on it, and those with the Full or Pro versions of Winamp won't get a plugin installed by mistake that they don't want installed. Let me know.

I believe this is WRONG to overwrite Nullsoft's FLAC decoder. I guess that's what just happened to mine without me knowing about it. I like Nullsoft's FLAC decoder as it works with their media library (ML) and playlists fine. I don't want a third party FLAC decoder replacing the official Winamp FLAC decoder thank you... Just turn the option off by default please on the install window and let a person check the box if they really want your FLAC decoder plugin. Otherwise don't overwrite the existing one... that is bad programming etiquette I believe. I spent many years doing usability testing for software, so I wanted to help out here with my comments about FLAC. As if you haven't guessed it already, I am a big fan of FLAC.

By the way Mike, do you mind if I distribute your flac113x.exe Windows installer bundle from my server/site, or do you want all downloads to go through your server? Thanks.

You're right, it is bad etiquette... and I wasn't aware that the FLAC-distributed output plugin didn't play nice with WinAmp's media library.

My goal is to make an idiot-proof installer that will get FLAC Frontend and the WinAmp FLAC plugin installed on a user's PC without having to check/uncheck any boxes. I'll work on making the installer more smart about detecting the version and author of in_flac.dll... but it make take a bit more work than what I get done tonight. In the meantime, I'll leave Windows Installer v1.1.3b online, as it won't overwrite an existing in_flac.dll.

Thanks for all your hard-work in helping to promote FLAC. We'll get this figured out to be the best possible for all FLAC users (newbies and pros alike). Your FLAC installer is a blessing to many, and I just wanted to give you some input to make it the best possible from a user's perspective...

Let me know please if it is OK for me to take some load of your servers by distributing unmodified copies of your Flac Windows installer to my FLAC site's visitors. I have a dedicated server sitting around not doing much

I'd prefer that all downloads be directed through the main link for the Windows Installer on the FLAC project page, as this allows me to compile and implement new installer versions with the greatest of ease.