FLAC 1.5.0 released

[LedHarvest]

https://github.com/xiph/flac/releases/tag/1.5.0

As there have been additions to the libFLAC interfaces, the libFLAC version number is incremented to 14. The libFLAC++ version number is incremented to 11.

    General
        Multithreaded encoding is now possible in libFLAC and through the flac command line tool
        The GFDL license file is updated to version 1.3
        The markdown tool documentation is now also converted to HTML, for bundling with systems that do not read manpages (e.g. Windows)
        Decoding of chained Ogg FLAC files is now possible (philippe44, Martijn van Beurden)
        Various fixes (Sam James, Miroslav Lichvar, Cristian Rodríguez, manxorist, kgroeneveld, Lee Carré, Jevin Sweval, braheezy, Wolfgang Stöggl)
        Is is now possible in libFLAC, libFLAC++ and metaflac to write to a new file when changing metadata, instead of needing to overwrite an existing file
    flac
        Testing mode (flac -t) now parses all metadata blocks and warns the user when ID3v1 metadata is detected
        A warning is displayed when frame numbers do not increase correctly throughout a file
        The explain option (-H or --explain) is now removed, use the manpage or html tool documentation instead
        Built-in help and tool documentation are improved (H2Swine)
        When re-encoding a FLAC file from an existing FLAC file, a check is added that the MD5 sums of both files are the same
    libFLAC and libFLAC++
        The library interfaces have been extended. See the porting guide (part of the API documentation)
        An error is sent when a frame is missing
        The algorithm of the 'loose mid side' option has changed. Instead of checking every few frames which option is best and keeping that for the next few frames, a fast heuristic is now used. This was necessary to enable multithreading
        Most level 0 metadata interface functions now also work with Ogg FLAC files
        When encoding Ogg FLAC files, the callback now returns a number of samples instead of always 0 (Jesper Larsson, ziplantil)
        When changing metadata, libFLAC now detects when an input file is a symlink, and will refuse to write data to it when an in-place rewrite of the metadata cannot happen
        When encoding using seektable templates, unused seekpoints (with a sample number higher than the total number of samples) are converted to placeholders
    Build system
        Fix building on Android with API version < 24 (Steve Lhomme)
        The microbench utility has been removed
        Enable building with emscripten (werner mendizabal)
        Minimum CMake version required (when building with CMake) is now formally 3.12
    Testing/validation
        Improve fuzzing of allocation failures
        Various other fuzzing improvements
    Documentation
        The FLAC format is now specified in RFC 9639
        The foreign metadata storage format used by the flac command line tool is now properly documented

Hopefully that can get baked in sooner rather than later?

[sveakul]

Thank you for the heads-up on this!  The command line encoder flac.exe with metaflac.exe, and libFLAC.dll are downloadable in 32 and 64-bit versions at GitHub here:
https://github.com/xiph/flac/releases/tag/1.5.0 .

To begin using them in MusicBee for encoding/format conversion replace the existing flac.exe (in the Portable version it resides in MusicBee/Codec) and libFLAC.dll (in the main MusicBee directory).  The flac.exe requires the updated libFLAC.dll to work,  I would advise using the 32-bit versions of both as MusicBee.exe (which is 32-bit) may use the library file independently of flac.exe (unlike with qaac64, etc).

BASS has not released an updated bassflac.dll  decoder yet (I expect that very soon) so the few decoding updates ("Decoding of chained Ogg FLAC files") would have to wait for users using a default setup.

[hiccup]

Hopefully that can get baked in sooner rather than later?

What's the urgency?

Also, MB v3.6 is now in RC stages.
So I could imagine it not being the best moment for introducing new DLL's and such.

[LedHarvest]

Thank you for the heads-up on this!

You're welcome. Thanks for posting up the instructions for use for everyone.

Have you run any tests yet? All OK?

[LedHarvest]

Also, MB v3.6 is now in RC stages.

I never said 3.6.

Why would people want bug fixes, performance improvements, and new features? Sometimes some questions really are stupid.

[hiccup]

Also, MB v3.6 is now in RC stages.

I never said 3.6.
Why would people want bug fixes, performance improvements, and new features? Sometimes some questions really are stupid.

That's quite a puzzling and hostile reply.
You ignored/misunderstood my question regarding the urgency that you implied, and you don't seem to have a clue about what I wrote concerning the RC status that MusicBee currently is in.

Perhaps have a strong cup of coffee and try again?

[Zak]

FLAC encoding in MusicBee is already multi-threaded, in that it concurrently runs multiple copies of the encoder process when encoding multiple files.
We will need to see some before/after timed comparisons to determine if the introduction of multi-threading to the encoder itself will provide any noticeable benefit.

It may seem counter-intuitive but there's a possibility that multiple concurrent processes each running concurrent threads may take longer to complete if they compete for finite resources.

[Haste]

That would be awesome!

Been waiting for this to optimize my library. I want to do it from MusicBee itself to avoid any issue.

According to Musichoarders,

1. Encode with libFLAC
All lossless audio should be encoded with the latest version of libFLAC at the highest compression level, level 8. Since version 1.4.0, libFLAC, the reference FLAC implementation, has much improved compression ratio compared to earlier versions.

I've moved away from embedded cover art and I've trimmed my flac files. The last piece of the puzzle is the re-encoding.

Looking forward to the MusicBee update!

[hiccup]

That would be awesome!
Been waiting for this to optimize my library. I want to do it from MusicBee itself to avoid any issue.
Looking forward to the MusicBee update!

If you read the version history for 1.5 you will see that nothing has been changed regarding compression ratio.

[hiccup]

FLAC encoding in MusicBee is already multi-threaded...

In addition to that, I can't imagine encoding to FLAC will be used much to begin with?
Perhaps for CD ripping? But there the physical optical drive will be the bottleneck and the encoding speed will hardly matter at all.

[Haste]

That would be awesome!
Been waiting for this to optimize my library. I want to do it from MusicBee itself to avoid any issue.
Looking forward to the MusicBee update!

If you read the version history for 1.5 you will see that nothing has been changed regarding compression ratio.

Were there improvements made to compression ratios between the version of FlAC bundled with MusicBee and the current version of FLAC?

It is my understanding that there are.

MB is using FLAC 1.3.2


Improvement to compression ratios are mentioned in FLAC 1.4.0

https://github.com/xiph/flac/releases/tag/1.4.0

Therefore, I'm looking forward to an update.

[hiccup]

MB is using FLAC 1.3.2

I wasn't aware of that. I assumed it was using 1.4
But apart from that, improvements on compression ratio after 1.3 are pretty much negligible from what I have read.
Not much more than a couple of kb's for a complete album.

[LedHarvest]

MB is using FLAC 1.3.2

I wasn't aware of that. I assumed ...

That's where you keep going wrong. Making false assumptions and not understanding some basics - such as how out of date some libraries are / were in MB.

If you have nothing constructive to add, please stop.

[LedHarvest]

...there's a possibility that multiple concurrent processes each running concurrent threads may take longer to complete if they compete for finite resources.

I would have thought it makes sense to hand off the multi-threading to the new FLAC library now that it's included? Also note that the new multi-threading brings other changes to facilitate it which improves overall performance - "a fast heuristic is now used". Of course, Steven is more than capable of working that out.

Then there is the vague "Various fixes (long list of names)" within ~2 years of regular commits.

I've installed the new FLAC version and it seems to be working fine with MB3.6 latest patch.

[hiccup]

...some off-topic ranting...

I'll ignore your childish and misconstrued attacks.

In conclusion, you are not able to come up with a single valid argument why MusicBee should be updated using FLAC 1.5 "sooner rather than later".

Also, even if you don't, other users will understand it's probably not a good idea to update such files while MusicBee is in Release Candidate status.

And those are the only two points I have been making.
Not sure why you are reading other things into it and are trying to make a big fuzz about it.
Perhaps the coffee was too strong this time.