Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC 1.3.2 pre1 release (Read 14442 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC 1.3.2 pre1 release

Reply #1 –
Thanks for continuing development. FLAC is marvellous.

Re: FLAC 1.3.2 pre1 release

Reply #2 –
From the changelog:

General:
Fix undefined behaviour using GCC/Clang UBSAN (erikd).
General hardening via fuzz testing with AFL (erikd and others).
General code improvements (lvqcl, erikd and others).
Add FLAC in MP4 specification docs (Ralph Giles).
MSVS build cleanups (lvqcl).
Fix some cppcheck warnings (erikd).
Assume all currently used OSes support SSE2.
FLAC format:
(none)
Ogg FLAC format:
(none)
flac:
Fix potential infinite loop on flac-to-flac conversion (erikd).
Add WAVEFORMATEXTENSIBLE to WAV (as needed) when decoding (lvqcl).
Only write vorbis-comments if they are non-empty.
Error out if decoding RAW with bits != (8|16|24).
metaflac:
Add --scan-replay-gain option.
plugins:
(none)
build system:
Fixes for MSVC and Makefile.lite build systems.
documentation:
(none)
libraries:
CPU detection cleanup and fixes (Julian Calaby, erikd and lvqcl).
Fix two stream decoder bugs (Max Kellermann).
Fix a NULL dereference bug (on a malformed file).
Changed the LPC order guess for a slight compression improvement, particularly for classical music (Martijn van Beurden).
Improved encoding speed on older Intel CPUs.
Fixed a seeking bug when decoding certain files (Miroslav Lichvar).
Put an upper bound (32768) on the number of seek points.
Fix potential memory leaks.
Support 64bit brword/bwword allowing FLAC__BYTES_PER_WORD to be set to 8 (disabled by default).
Fix an out-of-bounds heap read.
Win32: Only use large buffers when writing to disk.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC 1.3.2 pre1 release

Reply #3 –
Thnx for the info/news ;)

Re: FLAC 1.3.2 pre1 release

Reply #4 –
Oh thank you I will be testing this.

Re: FLAC 1.3.2 pre1 release

Reply #5 –
is it possible with this flac 1.3.2 to re-encode, transcode (or whatever it is called) older flac files on the command line?

here's what I want:
- input file = flac1.2.1 encode , flac1.3.1 encode , or unknown flac file
- output file = flac1.3.2
- keep tags
- keep embedded picture

I don't mind doing this one by one. Is this possible?

Re: FLAC 1.3.2 pre1 release

Reply #6 –
Quote from: nastea on
is it possible with this flac 1.3.2 to re-encode, transcode (or whatever it is called) older flac files on the command line?

Yes; flac has supported this for quite some time.  I generally use the following:

Code: [Select]
flac --best -f -V foo.flac

In this case, the -f is what allows re-encoding an existing file.

Re: FLAC 1.3.2 pre1 release

Reply #7 –
I use this

dir /b /s *.flac > flac.txt
for /f "usebackq delims=|" %%f in (flac.txt) do flac.exe "%%f" --force --verify 2>> results.txt

But I would wait to final version to do it on real collections.

Re: FLAC 1.3.2 pre1 release

Reply #9 –
Quote from: Porcus on
A warning:
I had a few files eaten by the FLAC frontend. For all that I know, the problem could be in the CLI.

(Of course I had a backup, so I could bit-verify afterwards.)

I use the bit compare component for foobar2000 and see if any differences are reported as safety measure after encoding FLACs before deleting the original WAV files.  I've only had one or two instances out of thousands of encoded files where an encoded file was truncated.

Re: FLAC 1.3.2 pre1 release

Reply #10 –
Quote from: Chibisteven on
I've only had one or two instances out of thousands of encoded files where an encoded file was truncated.

Only a few here. Which is still way too much, of course. A lossless convert-with-verify utility shall not commit a delete unless "to" and "from" are verified to match.

Re: FLAC 1.3.2 pre1 release

Reply #11 –
I remember asking a couple of years ago whether it was worth changing/re-encoding my FLAC library from its current 1.2.1 to the most up to date at the time (which was 1.3.1).  And the answer was a pretty definite no. 

So just curious as to what the benefits are in doing this and why some people plan to? 

Cheers

Re: FLAC 1.3.2 pre1 release

Reply #12 –
It provides no direct benefits, maybe very slightly better compression (especially if you change the compression level to -6/-8 which has however negligible effect and increases compression time significantly, e.g. I use the default level (5) ) and generally updated FLAC.EXE engine (which does not matter much if your current files play OK, and FLACs do play OK - I experienced no problems with that format). But if you want to have your FLACs to be written by new/updated FLAC "engine", you can do it, of course with good backup and you then can compare MD5 sums to be sure the audio has not changed.

But I would wait to final version become mature and widespread before thinking about it anyway.

Re: FLAC 1.3.2 pre1 release

Reply #13 –
Quote from: MaxDread on
So just curious as to what the benefits are in doing this and why some people plan to? 

First, to get rid of a long list of tool metadata. This fb2k-screenshot is a bit "artificial" I admit, but:

The Tool line is already fairly wide even with only the FLAC files. With all the lossies (and WavPack which I use for CDs with pre-emphasis, in case I should accidentally delete/copy the wrong tag), it does sometimes still get annoying, but FLAC files taking up the vast majority of the hard drive, and I very often had a lot of versions displayed. Now I have a fairly good overview with just a glance: except a few corrupted files, I keep my classical music in 1.2.1 and the rest in 1.3.1.

Second, FLAC does not store the encoding settings, so only my CD rips I can know have used -8. It seems to me that Bandcamp uses -8 fairly consistently, but I didn't know until I recompressed the entire lot.

Re: FLAC 1.3.2 pre1 release

Reply #15 –
Tested on 100 various WAV-FLAC files conversions, no apparent problems.
Thanks for development!

Re: FLAC 1.3.2 pre1 release

Reply #16 –
10GB of mixed bitrates and genres came out 1MB smaller, no album compressed worse, speed must be similar against the latest x64.
Only a simple test from a happy customer.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC 1.3.2 pre1 release

Reply #17 –
Also I report one happy FLAC user here  ;)

Re: FLAC 1.3.2 pre1 release

Reply #18 –
When is the final release expected?

I'm planning on transcoding my entire Wavpack collection to flac so I can enjoy music on my android device.

Re: FLAC 1.3.2 pre1 release

Reply #19 –
Quote from: Wombat on
10GB of mixed bitrates and genres came out 1MB smaller, no album compressed worse, speed must be similar against the latest x64.
Only a simple test from a happy customer.
Don't forget that every single file produced by "FLAC 1.3.2pre2" will be 4 bytes bigger than those produced by the final "FLAC 1.3.2" because of the extra "pre2" in the version string.  ::)
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Re: FLAC 1.3.2 pre1 release

Reply #20 –
Quote from: Maurits on
Don't forget that every single file produced by "FLAC 1.3.2pre2" will be 4 bytes bigger than those produced by the final "FLAC 1.3.2" because of the extra "pre2" in the version string.  ::)
I mention it because of the changes in the changelog "Changed the LPC order guess for a slight compression improvement, particularly for classical music"
It is not some wacko compressionate fetish. For that CUEtools flake is undisputed ;)
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC 1.3.2 pre1 release

Reply #21 –
Are there any settings that makes FLAC get near the compression ratio of WavPack? I need compatibility, but WavPack is a little more efficient. Tried -8 -ep, tried different LPC settings etc, but nothing near WavPack.

Only way to go (way) beyond that is LossyWav, but I still don't dare to use that because the obvious reason it is not identical to the original anymore. Although I really like LossyWav.

Re: FLAC 1.3.2 pre1 release

Reply #23 –
Quote from: Fairy on
Are there any settings that makes FLAC get near the compression ratio of WavPack? I need compatibility, but WavPack is a little more efficient. Tried -8 -ep, tried different LPC settings etc, but nothing near WavPack.

Only way to go (way) beyond that is LossyWav, but I still don't dare to use that because the obvious reason it is not identical to the original anymore. Although I really like LossyWav.

Using -ep in FLAC is just not worth it, too slow for almost the same compression. As wombat said in the post above yours, with CUETools Flake you can get the best results with FLAC format. Even then, it will be a minor improvement.

Re: FLAC 1.3.2 pre1 release

Reply #24 –
Quote from: Fairy on
I'm planning on transcoding my entire Wavpack collection to flac so I can enjoy music on my android device.
That seems like a lot of trouble. Aren't there any Android players you like that support WavPack? I know Foobar2000 does.