flac 1.3.0 pre-release Options

[eahm]

Can anyone please post the exe? ...or instructions of how to compile since I've never did it once?

Thanks.

This post has been edited by eahm: Mar 9 2013, 20:18

[romor]

Here it is, flac-1.3.0pre2 exe with metaflac, compiled with MSVC: http://db.tt/x87ItNjC

[Musique-Rabbit]

Thanks romor, the pre2 is working fine for me. The ref lib is 1.2.1xxx, not 1.3xxx?

[Mach-X]

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

[johnb]

Why would you need to re-rip? Only recode (foobar converter), if at all.

[skamp]

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.

[romor]

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

[Porcus]

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.

[ktf]

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.

[eahm]

Also why the date is up to 2009 and not 2013?

[ktf]

Also why the date is up to 2009 and not 2013?

Because nobody updated it

[SpaceAgeHero]

Will this new release support compressing multiple audio tracks / files simultaneously with multicore CPUs natively?

[ktf]

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.

This post has been edited by ktf: Mar 11 2013, 10:10

[Maurits]

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.

[lvqcl]

Considering you can't use multiple cores to encode a single track

Why? Afaik FLAC encoding is easy to parallelize.

[skamp]

FLACCL, fpFLAC

[Maurits]

Considering you can't use multiple cores to encode a single track

Why? Afaik FLAC encoding is easy to parallelize.

FLACCL, fpFLAC

You are of course both correct. How could I forget FLACCL...

[ktf]

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

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



This post has been edited by ktf: Mar 13 2013, 15:00

[romor]

That's quite a shift. Do you have a suspect?

[benski]

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

[romor]

Thanks @benski.
For reference this should be it: diff

[lvqcl]

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.

CODE

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.

[ktf]

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

[lvqcl]

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.

This post has been edited by lvqcl: Mar 14 2013, 18:29

[ktf]

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

This post has been edited by ktf: Mar 14 2013, 20:59