Announced here: http://lists.xiph.org/pipermail/flac-dev/2...rch/003695.html (http://lists.xiph.org/pipermail/flac-dev/2013-March/003695.html)
Git change log: https://git.xiph.org/?p=flac.git;a=summary (https://git.xiph.org/?p=flac.git;a=summary)
Whoa. They've been on 1.2.1 for six years now, haven't they? I never saw this coming.
Whoa. They've been on 1.2.1 for six years now, haven't they? I never saw this coming.
There was a discussion about “The future of FLAC (http://www.hydrogenaudio.org/forums/index.php?showtopic=96784)” here half a year ago, so it isn’t completely out of the blue. :-)
Works fine on Arch Linux.
As usual, Fidel Castro Loco ignored Windows.
mudlord, don't overkill. You spent so much ink on him already. If you follow the topic you'll see that it's tested fine under mingw/msys and issues and patches are further provided for msvc.
If you want to be constructive, no one stops you
-=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-
Configuration summary :
FLAC version : ........................ 1.3.0pre1
Host CPU : ............................ i686
Host Vendor : ......................... pc
Host OS : ............................. mingw32
Compiler is GCC : ..................... yes
GCC version : ......................... 4.7.2
flac-1.3.0pre1.zip (http://aiz.free.fr/flac-1.3.0pre1.zip)
Configuration summary :
FLAC version : ........................ 1.3.0pre1
Host CPU : ............................ x86_64
Host Vendor : ......................... unknown
Host OS : ............................. linux-gnu
Compiler is GCC : ..................... yes
GCC version : ......................... 4.6
My own Linux build could not decode 1 file out of 4 that were tested. It ended with an error:
03.flac: ERROR while decoding data
state = FLAC__STREAM_DECODER_END_OF_STREAM
Compiling it with MSVC required some modifications and I'm unhappy to see that it still can't encode larger than 2 GB files.
I encoded 5 full random jazz/rock albums (-8) and I get a bit (less than 1%) more compression size than before. So, no improvement here.
My own Linux build could not decode 1 file out of 4 that were tested. It ended with an error:
Does the file decode with 1.2.1? Also, have you run make check? If yes to both questions, this might be worth investigating.
I encoded 5 full random jazz/rock albums (-8) and I get a bit (less than 1%) more compression size than before. So, no improvement here.
You know that 1% more compression is quite a lot for lossless audio?
As usual, Fidel Castro Loco ignored Windows.
I really wonder why you think that. If you take a look at what has been posted today on the FLAC-dev mailinglist, you'll see he's been busy discussing and applying patches for MSVC, which is obviously for the Windows-build of the flac libraries and command line utilities. Something like FLAC doesn't need much platform-specific stuff because it has been developed in a very portable way.
Agree, 1% is a good improvement.
Why still no 2GB+ support?
Yes, still being limited to 2 GB is a glaring problem. Considering that Case already showed (http://hydrogenaudio.org/forums/?showtopic=84014#entry725304) that it is easy to support files of any size, this should be fixed in the official code at the earliest opportunity.
Why still no 2GB+ support?
Because nobody submitted a patch to fix it apparently. No unicode support for Windows either.
edit:
Yes, still being limited to 2 GB is a glaring problem. Considering that Case already showed (http://hydrogenaudio.org/forums/?showtopic=84014#entry725304) that it is easy to support files of any size, this should be fixed in the official code at the earliest opportunity.
I just submitted this to the flac-dev mailinglist. @eahm: yes, but not everyone's reading HA that thorough
But there is a "patch", I am using Case's version and it has 2GB+ support.
Yes, still being limited to 2 GB is a glaring problem. Considering that Case already showed (http://hydrogenaudio.org/forums/?showtopic=84014#entry725304) that it is easy to support files of any size, this should be fixed in the official code at the earliest opportunity.
I just submitted this to the flac-dev mailinglist. @eahm: yes, but not everyone's reading HA that thorough
A few of us are reading it. But it would be better for everyone to continue the discussion on the flac-dev list instead.
Does the file decode with 1.2.1?
Yes.
Also, have you run make check?
I am doing it now. I hope It doesn't take forever.
You know that 1% more compression is quite a lot for lossless audio?
Actually, I said the opposite from what you understood. Files are bigger now.
Also, less is different than equal.
Maybe Case could provide the patch file instead of the compiled binary, to help out the FLAC devs.
Actually, I said the opposite from what you understood. Files are bigger now.
Also, less is different than equal.
I tried a few files and you are right: the files are larger then with 1.2.1. However, this will not be the case with the final 1.3.0, because the size increase I'm seeing is exactly 4 bytes, probably because the vendor string is now 1.3.0pre1 instead of 1.2.1, that's 4 characters more
But you're right: there have been no improvements considering compression, this release will be to keep FLAC up-to-date for developers mainly.
I tried a few files and you are right: the files are larger then with 1.2.1. However, this will not be the case with the final 1.3.0, because the size increase I'm seeing is exactly 4 bytes, probably because the vendor string is now 1.3.0pre1 instead of 1.2.1, that's 4 characters more
OK, so aside from the vendor string, will 1.3.0 produce exactly the same FLAC bit-streams as 1.2.1? I'm just wondering whether 7- and 8-channel support is the only new feature for end users like me...
Chris
You know that 1% more compression is quite a lot for lossless audio?
Actually, I said the opposite from what you understood. Files are bigger now.
Also, less is different than equal.
Pink Floyd - Echoes
wav: 238 MB (249,587,573 bytes)
flac.exe 1.2.1: 119 MB (125,539,573 bytes)
flac.exe 1.3.0pre1: 119 MB (125,537,329 bytes)
flac-1.3.0pre1.zip (http://aiz.free.fr/flac-1.3.0pre1.zip)
could you (or anyone else) tell me what option i need to use to build just the .exe? i've tried compiling myself and it works but i'm ending up with an extra file named libFLAC-8.dll which is required for it to run. i guess i'm just missing a configure option?
./configure --enable-static --disable-shared
Well, the first directory contains wav files that include no foreign metadata or tags. The second directory, files that were encoded with the Rarewares build. The third directory, files with my new linux 1.3.0 build.
zfox@paokfc01:~/temp/wav$ ls -la
total 2069368
drwxrwxr-x 2 zfox zfox 4096 ΞœΞ¬Ο 5 08:18 .
drwxrwxr-x 6 zfox zfox 4096 ΞœΞ¬Ο 5 08:18 ..
-rw------- 1 zfox zfox 644570348 ΞœΞ¬Ο 5 07:22 Caravan - Ether Way.wav
-rw------- 1 zfox zfox 466453388 ΞœΞ¬Ο 5 07:22 King Crimson - Islands.wav
-rw------- 1 zfox zfox 553853708 ΞœΞ¬Ο 5 07:22 Miles Davis - Miles Ahead [Rem 2000].wav
-rw------- 1 zfox zfox 454088924 ΞœΞ¬Ο 5 07:22 Pete Sinfield - Still [Rem 2004].wav
zfox@paokfc01:~/temp/wav$ cd ../1.2.1_rarewares
zfox@paokfc01:~/temp/1.2.1_rarewares$ ls -la
total 1180348
drwxrwxr-x 2 zfox zfox 4096 ΞœΞ¬Ο 5 08:03 .
drwxrwxr-x 6 zfox zfox 4096 ΞœΞ¬Ο 5 08:18 ..
-rw------- 1 zfox zfox 369762707 ΞœΞ¬Ο 5 07:40 Caravan - Ether Way.flac
-rw------- 1 zfox zfox 213436874 ΞœΞ¬Ο 5 07:40 King Crimson - Islands.flac
-rw------- 1 zfox zfox 345233967 ΞœΞ¬Ο 5 07:40 Miles Davis - Miles Ahead [Rem 2000].flac
-rw------- 1 zfox zfox 280174671 ΞœΞ¬Ο 5 07:40 Pete Sinfield - Still [Rem 2004].flac
zfox@paokfc01:~/temp/1.2.1_rarewares$ cd ../1.3.0
zfox@paokfc01:~/temp/1.3.0$ ls -la
total 1180584
drwxrwxr-x 2 zfox zfox 4096 ΞœΞ¬Ο 5 08:17 .
drwxrwxr-x 6 zfox zfox 4096 ΞœΞ¬Ο 5 08:18 ..
-rw------- 1 zfox zfox 369829421 ΞœΞ¬Ο 5 07:22 Caravan - Ether Way.flac
-rw------- 1 zfox zfox 213499535 ΞœΞ¬Ο 5 07:22 King Crimson - Islands.flac
-rw------- 1 zfox zfox 345297053 ΞœΞ¬Ο 5 07:22 Miles Davis - Miles Ahead [Rem 2000].flac
-rw------- 1 zfox zfox 280237221 ΞœΞ¬Ο 5 07:22 Pete Sinfield - Still [Rem 2004].flac
All files were encoded with '-8' compression level and were chosen randomly out of thousands.
The >4GB files patch can be found at kode54's FLAC github (https://github.com/kode54/flac).
Is it possible for John33's optimizations to affect file size along with speed? That is the case with lossy codecs.
The >4GB files patch can be found at kode54's FLAC github (https://github.com/kode54/flac).
Great job, team
edit: ah... it's not that easy to make the patch, I was in a rush... can someone provide it as a patch?
[flac-dev] Answering the Hydrogen Audio thread (http://lists.xiph.org/pipermail/flac-dev/2013-March/003742.html)
I will answer what I can here.
No unicode support for Windows either.
Somebody that knows about windows unicode needs to work on this and
supply a patch. I'm happy to help out with guidance and testing.
Depends on what you mean by "unicode support".
Unicode file names? UTF-8-encoded metadata in files?
The latter is a matter of I/O mostly, and should already work (if it
doesn't, it will have to be fixed).
The former depends on what libflac (or flac, if your only concern is the
commandline utility) does with filenames.
Also, do you want unicode support in API? Unicode support in commandline
utility? Unicode support in GUI frontend (is it free at all, by the
way?)?
Also, do you want libflac to remain ANSI-compatible? The API won't
change, that's for sure, so do you want libflac to assume "char *"
arguments to be UTF-8-encoded or encoded in locale-dependent codepage
(if you were thinking of libflac providing a subset of APIs that accept
"wchar_t *" - i don't see that happening).
Depends on what you mean by "unicode support".
What I mean is that on linux, I can encode files with filenames that include Cyrillic or Greek characters without any problem. On Windows, it it rejects the file, saying it does not exist at all, because it doesn't "understand" anything but ANSI apparently. I guess that's a compile-time issue?
edit: just to be clear, I can create a file with Cyrillic characters and feed it to most programs from the command line (like foobar2000, it plays the file just fine), but flac will say that the file doesn't exist.
./configure --enable-static --disable-shared
thanks.
flac-1.3.0pre1.zip (http://aiz.free.fr/flac-1.3.0pre1.zip)
It's working fine, thanks a lot for this build but is there any chance that you could make one with this patch ? :
The >4GB files patch can be found at kode54's FLAC github (https://github.com/kode54/flac).
I tried a few files and you are right: the files are larger then with 1.2.1. However, this will not be the case with the final 1.3.0, because the size increase I'm seeing is exactly 4 bytes, probably because the vendor string is now 1.3.0pre1 instead of 1.2.1, that's 4 characters more
I verified this 4-byte difference with a native 1.2.1 build.
Maybe Case could provide the patch file instead of the compiled binary, to help out the FLAC devs.
I didn't make source patch as my changes were using Windows specific variable definitions and functions. That has to be made by someone who wants to maintain linux compatibility.
As usual, Fidel Castro Loco ignored Windows.
As usual, NutCase ignored Linux.
If i may breathe a wish for 1.3 final in this thread: I'd really like to see EBU R128 support in FLAC.
If i may breathe a wish for 1.3 final in this thread: I'd really like to see EBU R128 support in FLAC.
There is support already? http://www.hydrogenaudio.org/forums/index....showtopic=85978 (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978)
Or do you mean support in the FLAC binaries? This release is mostly about libFLAC, only a few adjustments to the utilities are made.
If i may breathe a wish for 1.3 final in this thread: I'd really like to see EBU R128 support in FLAC.
There is support already? http://www.hydrogenaudio.org/forums/index....showtopic=85978 (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978)
Or do you mean support in the FLAC binaries? This release is mostly about libFLAC, only a few adjustments to the utilities are made.
If you want a binary solution, pbelkner's command line tool, flac1770, is a great little ebu r128 scannner, similar to vorbisgain. Works great for scripting.
On Tue, Mar 5, 2013 at 8:10 PM, Johnny Rosenberg <gurus.knugum@gmail.com> wrote (http://lists.xiph.org/pipermail/flac-dev/2013-March/003751.html):
> What is the reason that libFLAC is available for Windows in the first
> place? Aren't there lots of alternatives for Windows anyway?
(http://i.imgur.com/bShEqun.jpg)
Here's Johnny!
nothing interesting in the new version
[flac-dev] Answering the Hydrogen Audio thread (http://lists.xiph.org/pipermail/flac-dev/2013-March/003742.html)
Thanks romor (and Erik)!
Chris
If i may breathe a wish for 1.3 final in this thread: I'd really like to see EBU R128 support in FLAC.
There is support already? http://www.hydrogenaudio.org/forums/index....showtopic=85978 (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978)
Or do you mean support in the FLAC binaries? This release is mostly about libFLAC, only a few adjustments to the utilities are made.
I prefer software that is available through linux package management. The tool you mention isn't available in any distribution i know of. FLAC 1.3 bundle will likely be widely available once it's released. Plus native support is more smooth to use for various reasons.
Anyway: Great to see development again.
The question to update metaflac as part of the package for higher samplerate audio is there since several years now be it R128 or anything else.
03.flac: ERROR while decoding data
state = FLAC__STREAM_DECODER_END_OF_STREAM
Have you found the cause? This might be an interesting case.
I'm just wondering whether 7- and 8-channel support is the only new feature for end users like me...
Aside from lots of bug fixes, cleanups and harderning, a few features were added.
- adding ReplayGain support for 88.2kHz, 96kHz, 176.4kHz and 192kHz files to metaflac
- while it was already present in FLAC 1.2.1, --ignore-chunk-sizes can be used to encode malformed WAV-files (i.e. > 4GB) and this option is now present in the documentation
- support for Wave64 and RIFF64 has been added
I think that's it, but I might have missed something. Here's the changelog: https://git.xiph.org/?p=flac.git;a=shortlog (https://git.xiph.org/?p=flac.git;a=shortlog)
Have you found the cause? This might be an interesting case.
All tests from “check build” passed, so I guess this is not an issue.
Have you found the cause? This might be an interesting case.
All tests from “check build” passed, so I guess this is not an issue.
Yes, but flac 1.2.1 decodes and 1.3.0pre1 gives an error, that would be a serious regression right? Or some big bad bug in 1.2.1 which we didn't know about but fixed anyhow.
It's difficult to spot this file again in my library. I will try though, later.
flac-1.3.0pre2 release (link in first post)
It still doesn't compile here with MSVC out of the box. I get unresolved externals in libflac_static.lib
flac-1.3.0pre2 release (link in first post)
It still doesn't compile here with MSVC out of the box. I get unresolved externals in libflac_static.lib
Ahh, yes you are right. Let me fix that up. I didn't catch one of these before because I was compiling without Ogg.
patch works fine now, flac compiles out of the box
Can anyone please post the exe? ...or instructions of how to compile since I've never did it once?
Thanks.
Here it is, flac-1.3.0pre2 exe with metaflac, compiled with MSVC: http://db.tt/x87ItNjC (http://db.tt/x87ItNjC)
Thanks romor, the pre2 is working fine for me. The ref lib is 1.2.1xxx, not 1.3xxx?
just out of curiosity does anyone here go all willy nilly and re rip all their cds with each new flac version just to stay "bleeding edge"? I dont even remember which version I have...its whatever came with eac...
Why would you need to re-rip? Only recode (foobar converter), if at all.
From what I can tell, there are no compression improvements in this version. You don't have to either re-rip or transcode your FLAC 1.2.1 collection.
Binary is provided as user asked for it, and it's there for testing. There can't be any reason for re-encoding, or using beta version over next 1.3.0 version or previous release.
More patches are supplied, and final flac version will hopefully make flac build system breeze on supported platforms, and perhaps attract more developers and further extend in the future.
Some changes are mentioned in this thread and git change log is linked in first post.
More accessible change log should also be provided soon, AFAIK
just out of curiosity does anyone here go all willy nilly and re rip all their cds with each new flac version just to stay "bleeding edge"?
As others pointed out, re-ripping for the sake of a new lossless encoding is absolutely no point.
Myself I converted all my FLAC 1.1.x files to 1.2 simply because I otherwise would have too many FLAC versions in the Codec or Codec profile list in fb2k when selecting multiple items. It was too annoying to scroll past the FLACs in order to see if there was any other filetypes selected. I am still not confident that FLAC's overwrite is safe (anyone?), so I selected every 1.1.x file in fb2k, converted to a different drive with directory structure preserved, imported, bit-verified audio as identical, overwrote, and removed bit-identical files using XXCOPY. I am not sure if fb2k preserved album art, but I have that as folder.jpeg, front.jpeg and back.jpeg anyway.
Thanks romor, the pre2 is working fine for me. The ref lib is 1.2.1xxx, not 1.3xxx?
I just found out that for MSVC, there's a libFLAC version number (1.2.1 in this case) "hard coded" into the source, which explains why you're seeing files with such a vendor string appearing. I've notified the devs of this problem.
Also why the date is up to 2009 and not 2013?
Also why the date is up to 2009 and not 2013?
Because nobody updated it
Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?
Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?
No, for features like that you should use other encoders.
Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?
No, for features like that you should use other encoders.
I think that should be a feature for the frontend, not for the FLAC binary. Considering you can't use multiple cores to encode a single track it should be up to the frontend to just spawn multiple instances of the FLAC binary for each file and core.
Considering you can't use multiple cores to encode a single track
Why? Afaik FLAC encoding is easy to parallelize.
FLACCL (http://www.hydrogenaudio.org/forums/index.php?showtopic=64628), fpFLAC (http://www.hydrogenaudio.org/forums/index.php?showtopic=76193)
Considering you can't use multiple cores to encode a single track
Why? Afaik FLAC encoding is easy to parallelize.
FLACCL (http://www.hydrogenaudio.org/forums/index.php?showtopic=64628), fpFLAC (http://www.hydrogenaudio.org/forums/index.php?showtopic=76193)
You are of course both correct. How could I forget FLACCL...
I'm just wondering whether 7- and 8-channel support is the only new feature for end users like me...
Aside from lots of bug fixes, cleanups and harderning, a few features were added.
- adding ReplayGain support for 88.2kHz, 96kHz, 176.4kHz and 192kHz files to metaflac
- while it was already present in FLAC 1.2.1, --ignore-chunk-sizes can be used to encode malformed WAV-files (i.e. > 4GB) and this option is now present in the documentation
- support for Wave64 and RIFF64 has been added
I think that's it, but I might have missed something. Here's the changelog: https://git.xiph.org/?p=flac.git;a=shortlog (https://git.xiph.org/?p=flac.git;a=shortlog)
Even more 'features': I just ran some of my 'lossless audio codec comparison' scripts, and it seems decoding has sped up a bit. Encoding is as fast as 1.2.1 and compression it the same too, as was already concluded here. More graphs see http://www.icer.nl/misc_stuff/FLAC-1.3.0-results.pdf (http://www.icer.nl/misc_stuff/FLAC-1.3.0-results.pdf)
(http://www.icer.nl/misc_stuff/flac-1.3.1-decodespeed.png)
That's quite a shift. Do you have a suspect?
That's quite a shift. Do you have a suspect?
There were decoder optimizations done by Miroslav Lichvar. Specifically in the bitreader code in the Rice code decoder
Thanks @benski.
For reference this should be it: diff (https://git.xiph.org/?p=flac.git;a=commitdiff;h=8d9e5c6e8e532207b839231a3dc6592272685d5a;hp=7b37472a2f2a2ec6437a303d31fb828779f3dd92)
Anybody knows how FLAC calculates MD5?
I took a 16-bit file and encoded it with FLAC, WavPack, TAK and OptimFrog. All encoders calculated MD5 = 00b0bff6862b518452b46ad994cbde11.
Then I converted it to a 24-bit file (padded with 8 zero bits). Again, all encoders agree on its checksum: 453f0af141959d709cccdc4723ff77ec.
So far so good. But then I changed wValidBitsPerSample field, and now FLAC disagrees with all other encoders.
valid_bits WavPack, TAK, OptimFrog FLAC
16 453f0af141959d709cccdc4723ff77ec 00b0bff6862b518452b46ad994cbde11 (the same as for 16-bit file)
17 453f0af141959d709cccdc4723ff77ec 25234a864c084eb6c23c5f61ce5fdfc4
18 453f0af141959d709cccdc4723ff77ec c207d52c70f3fda72595864f3d133f35
19 453f0af141959d709cccdc4723ff77ec 4b26f915fe3775ea165e58ba4fc4b1cd
20 453f0af141959d709cccdc4723ff77ec daa325b376bfa803c849636fa1de0704
21 453f0af141959d709cccdc4723ff77ec 3d0670388b6919ab3ac79301b5c19996
22 453f0af141959d709cccdc4723ff77ec cac12a2a39c14e20df4716f34ea145b7
23 453f0af141959d709cccdc4723ff77ec 086a82a505fac96241b50fd67c925f45
24 453f0af141959d709cccdc4723ff77ec 453f0af141959d709cccdc4723ff77ec (the same as in other encoders)
It seems that FLAC first shifts input PCM data by (BitsPerSample - ValidBitsPerSample) bits, and calculates MD5 of these
altered data.
Anybody knows how FLAC calculates MD5?
Last time I checked, it was a MD5 sum of the raw data.
However, it seems FLAC is the only one displaying the right behaviour here, see http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/hardware/ff538802%28v=vs.85%29.aspx) The other encoders use all 24 bits to calculate the MD5 sum, presumably because they ignore wValidbitspersample and just encode all 24 bits. The specification however says wValidbitspersample is used to pack for example 20-bit audio in WAV (which can only be 24-bit or 16-bit, nothing in between AFAIK), so it seems FLAC just ignores the other bits while the other encoders keep them.
At least that would explain why your MD5sum for 16 bits is the same as the one of wValidbitspersample = 16 and why the MD5sums differ between FLAC and the other encoders
When ValidBitsPerSample=16: yes, FLAC just throws away these padding bytes. But when ValidBitsPerSample=17...24 then FLAC doesn't discard bits but simply shifts all input samples by (BitsPerSample - ValidBitsPerSample) bits and only then calculates MD5.
I don't think that such behavior is better than the simple (and straightforward) algorithm of WavPack, TAK and OFR.
When ValidBitsPerSample=16: yes, FLAC just throws away these padding bytes. But when ValidBitsPerSample=17...24 then FLAC doesn't discard bits but simply shifts all input samples by (BitsPerSample - ValidBitsPerSample) bits and only then calculates MD5.
Ah, sorry, I misunderstood/misread. Raw data of course can't be 22-bits or something like that, so indeed, MD5sum should be the same for 17 through 24 bits, as they are all packed as 24bit in raw audio. However, I don't understand why WavPack, TAK and OptimFrog can have the same MD5 for 16 bit and 24 bit. It would be stupid to pack 16-bit audio in a 24-bit container, true, but still, it looks like they just ignore wValidBitsPerSample?
Other news: The FLAC git has seen some changes on 2GB file limits on Windows. I didn't full understand the mailing list conversation, but apparently the limit was raised to 4GB and this can't be fixed until 1.3.1. Not really sure though. https://git.xiph.org/?p=flac.git;a=commit;h...ad983e3ec7fdb4f (https://git.xiph.org/?p=flac.git;a=commit;h=f25b2602dce3c09098e3092bfad983e3ec7fdb4f)
anyway, slower and less compression than flaccl (http://www.cuetools.net/wiki/FLACCL)
Other news: The FLAC git has seen some changes on 2GB file limits on Windows. I didn't full understand the mailing list conversation, but apparently the limit was raised to 4GB and this can't be fixed until 1.3.1.
The fix has no such limits. Only API wasn't allowed to be changed, but that affects nothing but FLAC__metadata_simple_iterator_get_block_offset function. That means this function won't work if there's more than 2 GB worth of metadata. I have tested the modified code with 20 GB FLAC files without trouble.
Edit: I added experimental Unicode support to flac.exe last night. If anyone wants to experiment you can download this (http://www.saunalahti.fi/~cse/temp/flac-1.3pre2-mod.zip).
Edit: I added experimental Unicode support to flac.exe last night. If anyone wants to experiment you can download this (http://www.saunalahti.fi/~cse/temp/flac-1.3pre2-mod.zip).
Great stuff, can't wait to see it make it into git! Thanks!
Edit: I added experimental Unicode support to flac.exe last night. If anyone wants to experiment you can download this (http://www.saunalahti.fi/~cse/temp/flac-1.3pre2-mod.zip).
Does -o option work? Because when I use "flac -6 in.wav -o out.flac" it creates in.flac and outputs:
in.wav: wrote 21869264 bytes, ratio=0,731
ERROR: output file in.flac already exists, use -f to override
ERROR: output file in.flac already exists, use -f to override
If -f is added, it encodes the file three times.
(http://www.icer.nl/misc_stuff/flac-1.3.1-decodespeed.png)
So now new FLAC decoder decodes -8 preset faster than old decoder -0 preset.
Not bad.
[coded support for files >2/4 GB and Unicode]
You’re on a roll here!
Also,
more speed-ups? Great, but as if it wasn’t far enough ahead of all the competition already.
Does -o option work? Because when I use "flac -6 in.wav -o out.flac" it creates in.flac and outputs:
in.wav: wrote 21869264 bytes, ratio=0,731
ERROR: output file in.flac already exists, use -f to override
ERROR: output file in.flac already exists, use -f to override
If -f is added, it encodes the file three times.
Thanks for testing. I had missed a couple of functions that took filenames. Appropriate fixes have been made and my own quick testing found no more problems.
I updated the archive (http://www.saunalahti.fi/~cse/temp/flac-1.3pre2-mod.zip) with latest changes and added metaflac in too. It contains the same unicode and wildcard treatment.
15 percent increase in decoding speed? It is hardly much compared to how CPU power has evolved over the years, but still cool in the 'just because one can' department. (After all, this is the yardstick I have been evaluating other codecs against; can it touch FLAC on both speed and compression simultaneously?)
I've compiled FLAC 1.3 pre3 with GCC 4.8 (vanilla) on i686 but it keeps crashing:
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x08078685 in FLAC__bitreader_read_rice_signed_block_asm_ia32_bswap.c0b0 ()
#1 0x00000000 in ?? ()
Compilation flags used are:
-O2/-O3 -pipe -march=native
(I've got an Intel Sandy Bridge CPU)
I configured it this way:
./configure --enable-sse --disable-shared --enable-static
It also crashes when compiled with GCC 4.5.4 without "--enable-sse".
It also crashes when I used "-O2 -pipe".
OK, I give up, I've just compiled it with "-O0 -g" and it just doesn't work at all:
file.flac ERROR got FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH while decoding FLAC input
file.flac ERROR: while decoding FLAC input, state = FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC
I run flac this way:
./flac -f -8 -Ax2 --replay-gain -V *.flac
(This is how my files were originally compressed).
I even removed most flags:
./flac -f -V *.flac
The errors persist (STREAM_DECODER_ERROR).
Guys, is some magic required to compile the new FLAC? It seems totally broken.
GIT version has the same problems.
Sigh.
Guys, is some magic required to compile the new FLAC? It seems totally broken.
Why are you trying to do a static build?
Static building never worked for me, but if you build shared, the flac utility will be static anyway (you'll have to run the script src/flac/flac and use src/flac/.libs/lt-flac after that), which does work here.
This release was mainly meant to fix built issues, so building should actually be easier.
but if you build shared, the flac utility will be static anyway (you'll have to run the script src/flac/flac and use src/flac/.libs/lt-flac after that), which does work here.
That’s not actually true, lt-flac is still dynamically linked. Libtool only makes sure that the uninstalled libFLAC is being used:
$ ldd src/flac/.libs/lt-flac | grep FLAC
libFLAC.so.8 => /home/chi/devel/flac/_bd/src/libFLAC/.libs/libFLAC.so.8 (0x00007f419de57000)
Unlike a statically linked binary, this will stop working if moved (it may either silently use the system-wide library, if there is any, or fail).
That’s not actually true
Oh right, I've been fooling myself apparently. Sorry for talking BS, thanks for the warning.
The problems birdie has look very much like broken hardware to me. Bad memory stick could easily trigger such behavior.
I uploaded fresh Win32 binaries of 1.3pre3 + git fixes here (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip).
I uploaded fresh Win32 binaries of 1.3pre3 + git fixes here (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip).
These are with the UTF-8 runtime patches you made? There are still problems with them (it actually got worse). I tested them on Windows XP SP3 and Windows 7 SP1, and I got this when used on three files, one with Cyrillic, one with Arabian and one with Japanese text.
See these screenshots:
http://www.icer.nl/misc_stuff/flac-130pre3-test.png (http://www.icer.nl/misc_stuff/flac-130pre3-test.png)
http://www.icer.nl/misc_stuff/flac-130pre3-test2.png (http://www.icer.nl/misc_stuff/flac-130pre3-test2.png)
It seems it doesn't remove enough characters (doesn't empty the line completely) before writing a new step.
Ouch, thanks. I used such tiny files in testing that the verification finished too fast to show this problem. I'll fix it.
Fixed the bug and repeating line bug with long filenames. Compiled version can be downloaded here (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip).
Fixed the bug and repeating line bug with long filenames.
We're getting there Case! Great job, finally the characters show up. However, I still have a bug to report. I can't catch it in screenshots this time.
Suppose I run flac.exe with 2 files, like flac.exe -t ?????.flac ????.flac The first file shows up correctly:
flac 1.3.0pre3 [...]
?????.flac: testing, 56% complete
However, the second filename is not displayed
flac 1.3.0pre3 [...]
?????.flac: ok
testing, 12% complete
When finished, it does show the filename correctly:
flac 1.3.0pre3 [...]
?????.flac: ok
????.flac: ok
Another bug is the following: when a file doesn't exist, flac returns the next message
flac 1.3.0pre3 [...]
?????-n.flac: ERROR initializing decoder [...]
However, metaflac.exe returns something else:
αβγδε-n.flac: ERROR: reading metadata, status = "FLAC__METADATA_CHAIN_STATUS_ERROR_OP
ENING_FILE"
However, when the file exists, it works perfectly.
Still, I can't stress this enough, this is a *HUGE* improvement over no UTF-8 support at all, many thanks for fixing this
I should hire you as my personal beta-tester. I reverted the long-line repeating fix as it obviously needs much more work. Here's a fresh set with above bugs fixed: flac-1.3pre3-mod.zip (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip)
New Winamp 5.70 Build 3364 Beta 4
* Updated: [libFLAC] FLAC 1.3.0
Isn't too early to integrate FLAC 1.3.x?
edit:
Tag 1.2.1 20070917, same as the "Pre" versions.
Isn't too early to integrate FLAC 1.3.x?
(http://i50.tinypic.com/351zq09.jpg)
New Winamp 5.70 Build 3364 Beta 4
* Updated: [libFLAC] FLAC 1.3.0
Isn't too early to integrate FLAC 1.3.x?
edit:
Tag 1.2.1 20070917, same as the "Pre" versions.
It's a beta release of Winamp. It's a good opportunity to test the FLAC release.
It's also worth mentioning that a vast majority of the changes for 1.3.0 were in the build scripts and the various tools. The core libFLAC library only received a minor amount of changes.
I uploaded a test binary with properly made long filename display fix. In my own testing it performs now correctly, but perhaps ktf could give it a try before I send patches to flac dev list. Download at the usual location (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip).
Download at the usual location (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip).
I just came here to thank you for the previous patches, they work on MinGW too I'll check the binaries.
I found no issues, it even works when I change the size of the console while flac is running. Great patch, I have seen this bug for years (because I've encoded quite some classical music, which usually has long filenames) but always ignored it. I hope it works as nice on Linux and other Unixes too
Screenshots:
http://www.icer.nl/misc_stuff/longlinepatch1.png (http://www.icer.nl/misc_stuff/longlinepatch1.png)
http://www.icer.nl/misc_stuff/longlinepatch2.png (http://www.icer.nl/misc_stuff/longlinepatch2.png)
thank you for the previous patches, they work on MinGW too
So would you be kind enough to share a GCC build please ?
Not sure why you would want it (I think building with MSVC is more native than building with MinGW) but here you go. This is the build I tested this morning, which is current git plus the two UTF-8 patches by case. This one is without the long line patch though.
http://www.icer.nl/misc_stuff/flac-mingw-g...utf8patches.zip (http://www.icer.nl/misc_stuff/flac-mingw-git2de567f-utf8patches.zip)
I'm confused. Is Case forking FLAC into a Windows-only project?
I'm confused. Is Case forking FLAC into a Windows-only project?
No? Case is supplying patches to get features into the Windows builds that have been in the Linux/*nix builds for ages, like UTF-8 support. Except the last two they are in git already, so no forking. Building on *nix still works perfectly. Cross platform projects sometimes just require some platform-specific workarounds.
The problems birdie has look very much like broken hardware to me. Bad memory stick could easily trigger such behavior.
I uploaded fresh Win32 binaries of 1.3pre3 + git fixes here (http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip).
I have zero problems with my system - RAM is 100% errors free as I've never had a single crash.
Like it's already been mentioned, static FLAC build is horribly broken.
I have zero problems with my system - RAM is 100% errors free as I've never had a single crash.
Case said memory stick, not RAM.
Like it's already been mentioned, static FLAC build is horribly broken.
No, it's not. I've now built statically linked on a bunch of different machines and architectures and it all worked flawlessly but for one (which failed during compiling already). I really don't know why it doesn't work on your machine though. Maybe you could explain a little more so we can do some troubleshooting? For example, are you trying to compile under Linux (what distro?), MinGW, *BSD, Solaris, etc. Have you tried using the compiler native to your OS, if it's an open-source one? It might be one of the libraries that is linked statically (libogg, libiconv etc.) is outdated or broken?
Can anyone compile pre4? Thanks.
Windows compiled flac-1.3pre4: http://lists.xiph.org/pipermail/flac-dev/2...ril/004057.html (http://lists.xiph.org/pipermail/flac-dev/2013-April/004057.html)
Decoding and Encoding test: http://lists.xiph.org/pipermail/flac-dev/2...ril/004078.html (http://lists.xiph.org/pipermail/flac-dev/2013-April/004078.html) (see attached PDFs)
Erik has announced he wants to release FLAC 1.3.0 next Saturday, so if you have any bug fixes, please be quick
Erik has announced he wants to release FLAC 1.3.0 next Saturday, so if you have any bug fixes, please be quick
Actually, he said “on Saturday”, so I guess he means this Saturday, not next. (See “Which day does ‘next Tuesday’ refer to? (http://english.stackexchange.com/questions/3841)”)
Put differently: There is some 50 hours left.
So, should we expect the final release today?
So, should we expect the final release today?
I
think that was the plan, though in that case it is already delayed (early Sunday in Australia now).
So, should we expect the final release today?
I think that was the plan, though in that case it is already delayed (early Sunday in Australia now).
Is Erik Australian?
edit:
Oh, he is from Sydney I see... http://au.linkedin.com/in/erikd (http://au.linkedin.com/in/erikd)
Which Saturday again?
not this saturday.
http://lists.xiph.org/pipermail/flac-dev/2...May/004139.html (http://lists.xiph.org/pipermail/flac-dev/2013-May/004139.html)
But the original plan was May 4, it just didn’t work out as planned. Perhaps next Saturday, then. :-)
I'm eagerly anticipating the release, considering I've been 1.2.1-FLACing my entire CD lineup in the past few weeks.
Quick question - does anyone have (or can anyone build) a script which will decode all 1.2.1-FLAC files in a given folder structure, and reencode at 1.3.0, preserving metadata/tags? I always use the strongest possible compression so would be interested in doing this, even if the disk space saved would be miniscule.
EDIT: Looks like compression increases are very minor, varying from a few kb improvement to a 4 byte decrease. Even so, I'm still willing to give it a try.
Quick question - does anyone have (or can anyone build) a script which will decode all 1.2.1-FLAC files in a given folder structure, and reencode at 1.3.0, preserving metadata/tags? I always use the strongest possible compression so would be interested in doing this, even if the disk space saved would be miniscule.
Everything about your post is a terrible idea. Please don't do it.
Spend the time you would have wasted on that doing something more useful, like coming up with a meticulous sorting and classification system for your own navel lint museum. Let the electricity you would have wasted on that go to a more noble purpose, like powering a Big Mouth Billy Bass singing fish year-round.
If you're really that short on bytes of storage I'm sure that I have a spare 3.5" floppy gathering dust somewhere which I can send you. It may be only a millionth as big as a cheapo consumer hard drive these days, but it's probably a good bit more than you'll save by recompressing your collection.
Everything about your post is a terrible idea. Please don't do it.
Spend the time you would have wasted on that doing something more useful, like coming up with a meticulous sorting and classification system for your own navel lint museum. Let the electricity you would have wasted on that go to a more noble purpose, like powering a Big Mouth Billy Bass singing fish year-round.
If you're really that short on bytes of storage I'm sure that I have a spare 3.5" floppy gathering dust somewhere which I can send you. It may be only a millionth as big as a cheapo consumer hard drive these days, but it's probably a good bit more than you'll save by recompressing your collection.
[sarcasm]You're right, I suppose the three seconds that it would take to get the batch process started would be a waste of my time. And the 50 cents in electricity it would take for my laptop to chug through all of the files in the Power Saving mode I normally leave it on could be better used somewhere else.[/sarcasm]
Frankly, your criticism was a very bad idea and a waste of time. If it wasn't baseless and self-defeating, I'd actually listen.
Yes, I am quite aware that there's not a lot of utility to such an effort - as made very obvious in my first post, where I indicated I expected miniscule changes. However I'm interested to see what difference 1.3.0 makes in maximal compression, and - given it's the first update in 6 years - I think this is justifiable.
There is no compression increase with version 1.3. The differences reported earlier were due to different metadata (the flac version string).
There is no compression increase with version 1.3. The differences reported earlier were due to different metadata (the flac version string).
Ah! Well in that case, I WOULD be wasting my time doing this. Thanks.
There is no compression increase with version 1.3. The differences reported earlier were due to different metadata (the flac version string).
Ah! Well in that case, I WOULD be wasting my time doing this. Thanks.
If you want tiny increases in compression, you could try FLACCL or Flake.
I did recompress my 1.1.x's, simply because I wanted a one-glance overview on the lossless part of a selection in fb2k (didn't have place to read any mp3 listings when there were four different FLAC versions to be listed first).
In addition I saved a quarter, I think. Of a dollar, certainly not of an hour.
(Actually, my drives soon got on the edge of full.)
Quick question - does anyone have (or can anyone build) a script which will decode all 1.2.1-FLAC files in a given folder structure, and reencode at 1.3.0, preserving metadata/tags? I always use the strongest possible compression so would be interested in doing this, even if the disk space saved would be miniscule.
To answer this question, the flac command line tool can do this. Just use 'flac -f file.flac' to re-encode the FLAC file while preserving all tags. To do this with a whole folder would be 'flac -f *.flac', with a whole folder of folders of flac files 'flac -f */*.flac' and so on.
Or, on Linux / OS Ⅹ / Unix:
$ find . -type f -iname '*.flac' -exec flac -f --best '{}' ';'
Is flac -f safe? Or can it mess up the transaction under e.g. write errors?
flac -f writes to a temporary file, before overwriting the original.
I guess you should use it with -V to check that the encoding went right. It transcodes to a temporary file (file.flac,fl-ac+en'c), and when finished, it removes the original and renames the new file.
Which makes sense, because a lossless codec should be as safe as possible. The command line tools have been designed with the same goal.
For restless, it arrived: http://downloads.xiph.org/releases/flac/ (http://downloads.xiph.org/releases/flac/)
For normal people, it should be formally announced in next day or two
For even more restless I made binaries (http://daman6009.home.comcast.net/flac.zip). Requires VC12 runtime.
This is the build I tested this morning, which is current git plus the two UTF-8 patches by case. This one is without the long line patch though.
http://www.icer.nl/misc_stuff/flac-mingw-g...utf8patches.zip (http://www.icer.nl/misc_stuff/flac-mingw-git2de567f-utf8patches.zip)
Please, is there any chance to get a GCC build of the release as well ?
Please, is there any chance to get a GCC build of the release as well ?
Yeah, sure, but you haven't told me yet why the Visual Studio build isn't good enough. It isn't faster (yes, I actually tested that), only a little bigger. http://www.icer.nl/misc_stuff/flac-1.3.0-final-minGW.zip (http://www.icer.nl/misc_stuff/flac-1.3.0-final-minGW.zip)
but you haven't told me yet why the Visual Studio build isn't good enough.
Because:
I want to do some tests and comparisons between different builds.
I find the GCC builds slightly faster than the MSVC2010-2012 builds on my main multimedia machine which is still running XP. It's about the same speed as MSVC2008 builds though (Déjà vu (http://www.hydrogenaudio.org/forums/index.php?showtopic=74345&view=findpost&p=802158)).
I'm often moving and changing location and the GCC builds can run out of the box on any machine I may work on, including older Windows versions, without the need to find and install the required runtimes which is sometimes impossible to do if the machine has been locked by some admin.
Anyway, thanks for this build, it's working like a charm as expected
Weren´t John33 ICL compiles from RareWarez always that slightly faster?
Yeah, sure, but you haven't told me yet why the Visual Studio build isn't good enough. It isn't faster (yes, I actually tested that), only a little bigger. http://www.icer.nl/misc_stuff/flac-1.3.0-final-minGW.zip (http://www.icer.nl/misc_stuff/flac-1.3.0-final-minGW.zip)
Confirmed to work with EAC.
I wonder why the download links on the Xiph website aren't updated yet? I only ever use FLAC in two programs - Foobar and EAC, and both work with FLAC 1.3.0 so that's fine for me.
I'm looking for a 64-bit Linux build for my Linux Mint system. Possibly just a standalone static linked build, that would be fine (of course a .deb would be the best).
However, I cannot find a Flac 1.3.0 version for a Debian-based system. Does anyone here know how I can get one?
http://packages.debian.org/search?keywords=flac (http://packages.debian.org/search?keywords=flac)
see: sid (unstable)
1.3.0-1: alpha amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe s390 s390x sparc sparc64
NOTE:
To check the same on Ubuntu:
http://packages.ubuntu.com/search?keywords=flac (http://packages.ubuntu.com/search?keywords=flac)
(but ubuntu doesn't seem to have 1.3.0 at the time of this post)
http://packages.debian.org/search?keywords=flac (http://packages.debian.org/search?keywords=flac)
see: sid (unstable)
1.3.0-1: alpha amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe s390 s390x sparc sparc64
NOTE:
To check the same on Ubuntu:
http://packages.ubuntu.com/search?keywords=flac (http://packages.ubuntu.com/search?keywords=flac)
(but ubuntu doesn't seem to have 1.3.0 at the time of this post)
Thanks!
I had to download the flac amd64, libflac8 amd64 and libflac8 i386 build. Now, I have flac 1.3.0 available on the command line.
Since (A) this thread was meant for discussion about the pre-release, not the final, and (B) it’s usually suboptimal for both readers and staff to have multiple discussions open about one specific subject, I think this thread should be closed in favour of the final-specific thread in Validated News. If no one presents any valid objection in the near future and everyone can get the loose ends of discussion tied up, I’ll do just that.
I would split this, but then, y’know, we’d still have two threads. Neither can I merge the relevant posts with the other thread as the first of them predates the opening post over there, and anyway, birdie made an effort to submit that thread to News, so it’s polite to let birdie retain authorship of it. I’ll consider merging in some of the later posts from here but can make no promises; that sort of thing can get very confusing.
Naw, this thing should have been closed once it was released.