FLAC 1.1.3 beta1 available Options

[Synthetic Soul]

nope , but i searched and there is on flac.exe in win32 folder but no other files, that i believe belong to it. So i can delete it? and paste the newset beta version in there?
I never deleted anything out of win32folder...

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.

[Paws]

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

[Wombat]

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

[jcoalson]

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

[Wombat]

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.

[iGold]

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

[madoka@ex-sounds]

beta2 dosen't work ogg-FLAC

CODE

options: --ogg -P 8192 -b 4608 -m -l 12 -e -q 0 -r 0,6 -V

ERROR initializing encoder
init_status = FLAC__STREAM_ENCODER_INIT_STATUS_UNSUPPORTED_CONTAINER

beta1 work fine.

[jcoalson]

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.

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

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

ok, will take a look.

beta2 dosen't work ogg-FLAC

CODE

options: --ogg -P 8192 -b 4608 -m -l 12 -e -q 0 -r 0,6 -V

ERROR initializing encoder
init_status = FLAC__STREAM_ENCODER_INIT_STATUS_UNSUPPORTED_CONTAINER

beta1 work fine.

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

[Wombat]

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.

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

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?

This post has been edited by Wombat: Oct 18 2006, 18:13

[madoka@ex-sounds]

beta2 dosen't work ogg-FLAC

CODE

options: --ogg -P 8192 -b 4608 -m -l 12 -e -q 0 -r 0,6 -V

ERROR initializing encoder
init_status = FLAC__STREAM_ENCODER_INIT_STATUS_UNSUPPORTED_CONTAINER

beta1 work fine.

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.

New beta2 work fine ogg-FLAC. thx Josh

[jcoalson]

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.

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

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?

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.

[DrGreen]

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!

[jcoalson]

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

[smz]

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.

This post has been edited by smz: Oct 18 2006, 22:33

[DrGreen]

glad to know that

thanks once again

[iGold]

it would be nice to have a --export-pictures switch

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?

[JWolf]

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

[Jose Hidalgo]

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 !

This post has been edited by Jose Hidalgo: Oct 22 2006, 12:45

[kjoonlee]

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

From metaflac --help:

--import-picture=SPECIFICATION Import a picture and store it in a PICTURE block.

You can probably just delete the block with metaflac.

[jcoalson]

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?

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.

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?

yep, it's fixed.

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 ?

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

[Jose Hidalgo]

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?

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.

This post has been edited by Jose Hidalgo: Oct 22 2006, 22:26

[Lashiec]

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

[Egor]

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.

[Lashiec]

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

[Jose Hidalgo]

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