You can replace that file with 1.1.3b1, but whether you should move completely to 1.1.3 while it is in beta is another matter.

It seems to me that 1.1.3 will already be well tested by Josh, so I doubt you will have problems.

Thats all i needed to do, thanks. FLAC is awesome

Just noticed that 1.1.3beta2 is up on sourceforge. I know nothing about changes.

yes, the difference is in the API, I have merged libOggFLAC into libFLAC (and libOggFLAC++ into libFLAC++) so that both native FLAC and Ogg FLAC are supported with the same API (metadata editing still only works for native FLAC though).

the command-line programs are still the same, though I guess there's a small chance I screwed up something in the Ogg handling that wasn't caught by the test suite.

Josh

One thing i noticed. If i encode with Flac-Frontend and add Tags and RG it takes much longer now. I mean the writing of the Tags after encoding. Does this relate to a problem? i didn´t found any but it makes me wonder. This was in beta1 already.

Beta2 doesn't want to work under x86_64 linux, bug report submitted on sourceforge tracker.

beta2 dosen't work ogg-FLAC


beta1 work fine.

what takes longer? and what is the time difference and how big is the WAV file?


ok, will take a look.


ugh, the problem is that the .dsp files for libFLAC don't have /D "FLAC__HAS_OGG" in them (and some other .dsp's then need to link with libogg). I fixed that in CVS and re-uploaded the windows binaries.

Josh

with 1.1.2 i see only running all trakcs thru the window ~1 second when after encoding the tags and replaygain are written. An average album with wavs ~50-80MB. For 1.1.3 it is ~1 whole second per song.
Nothing to worry indeed but a difference i thought should be reported. Maybe Tag.exe needs longer?

New beta2 work fine ogg-FLAC. thx Josh

hmm, don't know what that could be. at first it sounded like the whole file was being rewritten because of the tags but that would take a lot longer than 1sec.

Thanks for the new improvements.

I've been playing with the picture importing feature and everything seems ok. Although I have one question: how do we extract the pictures from the block to a file? it would be nice to have a --export-pictures switch that would extract all pictures to files with the names made from the pic type and extensions from mime types.

(I hope this is not too dumb.. )

Thanks!

yeah, that's on the TODO but I didn't want to hold back 1.1.3 for it.

Hold on a second... do you mean we can embed album art with 1.1.3 but there is no way to extract it and we should wait for a future release to have any use for it?

Totally unrealated: I can be blind (and already proved to be in the past) but I don't see anything in the changelog about the possibility to embed cuesheets on non-CDA-sector-aligned material that was supposed to be available in the "next release". Is that fixed?

Sergio

Edit: sorry, I posted an empty reply in the first time. Now there is one.

glad to know that

thanks once again

I also vote for more extended picture support out of box only with flac/metaflac tools. Or flac 1.1.4 is planned soon after 1.1.3?

Please please please do us (those of us who want the smallest sized FLAC files) remove the embedding of album art. It's only going to lead to FLAC files posted on the net with album art included and I really really hate embedded album art of any kind. I don't need it at all and I don't want to risk getting files that have embedded album art.

Jon

JWolf, what are you saying ? The size of the embedded album art is negligible compared to the size of FLAC file (maybe about 100 KB max. compared to about 25-30 MB of a single FLAC file, that's less than 0,3-0,4%). What exactly is your interest in having the smallest possible FLAC file sizes ? Why is it so important for you ? If you really want small file sizes and 100 KB per file are vital to you, do know that there are other lossless codecs that compress slightly more than FLAC. And if you still want smaller file sizes, why don't you go MP3 ?

Also, just remember that you'll be able to batch-remove all the embedded album art you don't want in just a few clicks with most of the tag&rename softwares out there. So I really don't see the point.

So come on, let's be honest : the new album art embedding is a great improvement to FLAC, and I hope there will be soon lyrics embedding also (that's 2-3 more KB per file... wow, big deal ! ). Josh, what do you think ? Is lyrics embedding (and additional tag support like genre/sub-genre, album artist/song artist, etc.) in the pipeline for future FLAC releases ?

As for myself, I just can't wait for FLAC 1.1.3 final in order to begin ripping my 1000 CD collection. Thanks Josh for all your hard work. You rock !

From metaflac --help:

You can probably just delete the block with metaflac.

well I thought it was only going to be used it players through the API. the calls in libFLAC are there to read pictures, it's just there is no metaflac command to export yet.


yep, it's fixed.


hmm, I haven't really been asked for that yet so I haven't looked into it. are there any players that use it? what is the usual mechanism?

Josh

I'm afraid I'm not qualified enough to answer that question. Here are some examples :
- iTunes has been supporting album art & lyrics embedding for some time now. Everything seems to be inside the music files, but I don't know how. Of course iTunes doesn't support FLAC yet (it should in a few months according to XiphQT developer : http://www.xiph.org/quicktime ).
- There's also Music Library ( http://www.wensoftware.com/MusicLibrary ) that would allow to add album art & lyrics to a FLAC file, in which case the album art is external (link to an external jpg) and as for the lyrics I haven't found any link or external file, so maybe the lyrics are added somewhat to the FLAC file ?
- And probably lots of others players / library organizers.
I don't know if I'm answering your question. I don't know about the mechanisms. Sorry but I just can't be more helpful on that matter.

Josh, I'm just curious. Why the size increase in the default padding?

The previous 4kb padding was clearly not enough: there was a number of complaints about slow tag update speed, especially for CD-audio images. Hence the new nice 8k padding and 64k for audio longer than 20 minutes.

Oh, I understand. Since I use individual files and I don't add too much information to them, it's normal I didn't have any problems retagging the files, even those 20 minutes ones. Although I never tried with "Octavarium"...

How is this beta going ? Can we expect a 1.1.3 Final soon ?

the beta seems fine. I'm still writing patches for various projects that are affected by API changes to make the transition easier. should be a couple more weeks.

Josh


p.s. could also use some help with this:
http://www.hydrogenaudio.org/forums/index....showtopic=49439

Discussion regarding conversion of 1.1.2 to 1.1.3 moved to this thread.

Josh: I'm adding my vote for a "--export-picture" option for Metaflac in 1.1.3.

I routinely add cover art to my whole-album flacs now and I'm in the habit of deleting the scanned jpgs when I'm done. When I edit metadata in my flacs, I use a script to dump the metadata to files, edit the offending file (usually a cue sheet), clear the tags in the flac and then re-embed.

Without a way to extract the pictures, I'm afraid that I'll end up loosing the images when I clear tags.

Could wildcard support be implemented for Windows OS.
If read somewhere that this is not needed for Linux/Unix because of the native OS wildcard support.

I found a workaround with glob.exe, but native support would be great.
http://www.hydrogenaudio.org/forums/index....howtopic=45862#

Thanks,

Willem

Josh,

Thanks for working on this new FLAC update.

I am glad it will be backward compatible with all FLAC players (version 1.1.x decoders). Nice to see album art option for art support included.

The only thing I see missing (and which I saw someone else mentioned also) is Lyrics support, as iTunes and other players support display of song lyrics if it is embedded in the audio file via 'a tag'. Since there is no standard for a lyrics tag I am aware of (iTunes uses their own in M4A and ALAC lossless files they create), you would have to define one. Lyrics are a text field that is multi-line text with carriage returns/linefeed characters that should fit well in a text tag field and most songs lyrics are not that big in size. It would be a "nice to have" optional tag feature so people could look at the words to the song in their audio player (if the player supported song lyrics display).

I write my own songs and would like to embed the lyrics so my customers/listeners can see the words/have them included in the audio file. Also I like to insert lyrics into the audio file when I purchase a song or rip one from a CD I own. I know many artists would likely use this lyrics feature to "add value" to their music when distributing it via FLAC files. It is always nice to have both lyrics and artwork in my opinion. I appreciate any consideratiuon you can give this text lyrics option. It would truly make FLAC an even better and more versatile audio encoding file format.

Thanks again for this FLAC update. I look forward to the future growth of FLAC in hardware devices and software apps.

ok, but if it's just a tag you can already embed lyrics with flac 1.1.3 with its new option --tag-from-file

Josh

I guess what I am asking for Josh is a new standardized lyric tag for FLAC in the 1.1.3 spec. Since lyrics are usually lines of text (with carrage returns/linefeeds embedded), i.e. a plain textfile, there has to be some standard tag name defined to denote lyrics embedded in FLAC files so all players can access/read the lyrics properly. I don't know the technical ways Apple iTunes embeds Lyrics in M4A and lossless ALAC files it creates, but it must be through atoms/tags or something similar. Just wanted to have a standard lyrics tag (or embed option) defined in the FLAC spec. Hope this helps.

Well, why don't you just stick with LYRICS tag? Is there a meaningful reason to elaborate on a new RFC/ISO/whatever standard for just LYRICS tag?

Is there already a lyrics tag for FLAC files that is in standard use. If so, I have never seen or heard of one. Is it part of Vorbis comments and in wide use? Please enlighten us so we can ask WinAmp and other FLAC supporting audio players to recognize this standardized lyrics tag to suport display of lyrics in FLAC files? Thanks in advance.

Also which FLAC audio encoding apps support this standard LYRICS tag for embedding a song lyrics inside a FLAC file? I have yet to find one. Perhaps I looked in the wrong places. I have never heard lyrics in FLAC files brought up as being possible before.

I would recommend LYRICS as the most logical choice.

also, just checked in a new --export-picture-to option for metaflac, that will be in 1.1.3

http://flac.cvs.sourceforge.net/*checkout*...port_picture_to

Josh

Thanks Josh. I Guess LYRICS is the name for embedding lyrics in FLACs then. Now we have to get FLAC supporting apps to recognize/support that. Also thanks for adding the picture and export_picture options to FLAC 1.1.3 - I know a lot of people have been wanting a standardized way to embed album cover art in their FLAC files.

Keep up the great work!

Is that a good choice, given that LYRICS is suggested as "the person who wrote the lyrics, eg Donizetti", in the Ogg Vorbis Comment Field Recommendations?

Edit: sorry, noticed that it was LYRICIST, and not LYRICS that is used for that. Forget it.

I agree. But, for everyone's sake, please set standards like these as soon as possible before some idiot app or OS developer makes up his own and we're stuck with multiple different standards in a years time. I'd say at least before Apple has to create one of his own for when FLAC becomes natively part of the next OS X (Leopard, to be introduced in the spring of 2007).

I'd just like to go +1 with goodnews. It's true that a LYRICS option would be a great improvement to FLAC 1.1.3. With that, we would have what most people want besides FLAC music : (1) album art and (2) song lyrics. Josh, please think about it. IMHO, album art and song lyrics are simply complementary and should come together. Thanks in advance for implementing this as a defined standard ASAP, so that 3rd party developers can quickly support it in their FLAC-compatible applications (e.g. foobar2000, Music Library...).

BTW, about native FLAC support in Leopard, I've been hearding of it in the last few days, but is there any consistent information about it ? Is it confirmed ? Any links ?
FLAC support in Leopard would probably mean FLAC support in QuickTime, which would mean FLAC support in iTunes for both Mac and Windows !!!

--export-picture-to: yeah!!! Thanks Josh!

--lyrics: --set-tag-from-file="LYRICS=Dis workz gud enuf for me.txt"

so you can import and now export....does export delete/move the picture from the FLAC file or just copy out it to a file/stdout?

Cheers,

Kristian

Any idea how much longer until 1.1.3 is an official release? Any bugs we should be aware of in beta 2?

Jon

Just copy.

Josh, I just tried compiling beta2 and it hangs during the ./configure stage:I realised I hadn't made the changes to the two files you recommended before but when I went to alter them, the alterations were already made. Am I missing something obvious ?

Intel iMac OS X 10.4.8

Regarding multichannel WAVE_FORMAT_EX files

I suggest adding a --channel-mask option to flac and the channel assignment table from WAVE_FORMAT_EXTENSIBLE definition to the documentation. Unfortunately, there are still popular applications not supporting _EXTENSIBLE .

Turns out FLAC 1.1.3 beta 2 also cannot handle this WAV file without an error.

flac 1.1.3beta2, Copyright © 2000,2001,2002,2003,2004,2005,2006 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.

options: -P 8192 -b 4608 -m -l 12 -e -q 0 -r 0,6
wacky2.wav: WARNING: skipping unknown sub-chunk 'fact'
wacky2.wav: WARNING: skipping unknown sub-chunk 'pad '
wacky2.wav: WARNING: skipping unknown sub-chunk 'pad '
wacky2.wav: wrote 8328 bytes, ratio=138.800

The resulting WAV from the FLAC file no longer matches. The original is 96 bytes and the decompressed one is 60 bytes. FLAKE 's decompressed WAV file is 72 bytes.

no, it's not an error, see my explanation here.
http://www.hydrogenaudio.org/forums/index....st&p=447495

let's keep the discussion in that one topic.

Josh



yeah, maybe export is a bad word, but it's just a copy, it won't delete the metadata.


I've finished writing patches for the projects I know about (BTW if anyone needs one for an open source project and hasn't gotten one let me know). now I'm just going through the few remaining bugs on SF.

no major bugs have turned up so far since beta2. so I'm hoping in 2 weeks it will be ready.


ugh, hmm.... ok I will take a look again. it is basically waiting on stdin so you could try hitting ^D, it might keep going.


ok, I don't have any intuition on whether this will be necessary yet, I would just say if you run into multichannel files that flac rejects, send them to me so I can build up some info on the oddball ones.

Josh

Thanks Josh, that did the trick to get it through ./configure but make fails with:

Foobar2000 generates multichannel WAV files, which are not compatible with flac.exe 1.1.3 and Windows Media Encoder. I've sent you a sample to the address at sf.net.

One small problem with version info. I use flac.exe –version and metaflac.exe –show-vendor-tag in a windows batch script to determine if a .flac file needs to be updated to a newer version. The problem is the output is no longer consistent.

flac.exe –version = flac 1.1.3beta2
metaflac.exe --show-vendor-tag = reference libFLAC 1.1.3-beta2 20061016

The “-“ seems to be the problem. Can you make the change in the final version so my script will work again?

Thanks!