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.
Last post by Porcus -
I recommend against bringing your only copy to work!
Sure, SSD for going out DJ-ing - and for that use, you can go MP3. If you suspect artefacts - or some software is too slow seeking at VBR, is that a thing? - you can go back to the losslesses and re-encode.
A couple of typos first: "Hertz" on three occasions, should be "hertz"; when written out, SI units are not capitalized. Not even those named after people (ampere, henry, hertz, kelvin, ...) "bocksize" is something worth discussing when we are closing in on Oktoberfest, but you need an "l" in that link in C4.
Then an obsolete piece of information: * 9.2, bottom of page 13 says that the reference implementation only supports up to 24 bits per sample.
And then on to Subset considerations. * First capitalizing nitpickery: it must be hard to read all those "subset of" that don't refer to format Subset. If the document allows for emphasis, may I suggest emph'ed Subset? And even if not, the Section 8 header (and thus the TOC) should have capital S, and then in 9.6.2 it says "non-subset". Also, if some of the "subset of" could be rephrased as "special case of", or in the case of "decoders only implement a subset of FLAC features": what about "only implement part of the full FLAC specification" or ...?
* Also the definition is not clear, since 9.6.2 says that tag-defined channel mask violates streamability and is "i.e. non-subset" - and that restriction is nowhere found in Section 8. Indeed, consider whether Section 8 should be clearer about the fact that there are indeed signals that can be encoded to Flac but not to Subset (even standard left+right 2ch, those > 655350).
And finally I wonder if escaped Rice is to be understood as Rice.
For each subframe with a predictor, a entropy coding method (i.e. rice coding method) is chosen once. An escape code can be used for every partition, so that is one level deeper.
Yes, but (I might have mentioned this before, because at least I have thought I'd mention it): Does Subset disallow for a "Rice partition order" of 0b1111? It can be read as "no, that is a number > 8" but alternatively it can be read as "that is fine - as 0b1111 does not signify a Rice partition order, it can obviously not signify a too big Rice partition order". A simple "MUST NOT be escaped" or "or be escaped" in the last sentence of section 8 would clear up.
* Then: I find nowhere that it is RECOMMENDED to use Subset when interoperability is a concern (provided the signal allows for Subset, that is). You have probably thought of it, but it looks strange not to recommend.
And finally a few that you might argue don't need to be clarified at that level of nitpickery (which you might already have been thinking a few times already during this post). First, on a general note, I don't have the knowledge to tell whether all "invalid" are strongly enough declared invalid. Say, I have no idea whether all/any of the "MUST be a multiple of 8" could be 0. Or, say: could the last frame be 0 samples?
Some specific ones:
* 5.3: Should there be a first sentence that an encoder MAY use any of these for any subframe at its discretion subject to [rest of the requirements, including all the quirks on 32 bit]? (Although this section describes common uses, it might otherwise appear as prescriptive. Imagine if some ultra-low power CPU only wants to receive an audio stream and store it uncompressed, uses FLAC for other reasons than compression and stores everything Verbatim - oh fine!)
* 9.6.2 again. Should one write that the WAVEFORMATEXTENSIBLE_CHANNEL_MASK field MAY be used even when it agrees with the channel bits? And then that it isn't streamable when defined through a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag that differs from the channel bits ...? And also: what shall(/SHALL, or RECOMMENDED or ...) a decoder do if it gets a dropout in a multichannel stream where it knew (from the beginning) that it had a channel mask tag? Default to channel bits even at the slightest dropout? Or that MAY be up to the implementation?
* C5, RECOMMENDED to pad to "a whole number of bytes", would it be better to have "the next whole number of bytes" or are devs not dumb enough to think "oh, but let's use 32 as a catch-all!"?
Last post by music_1 -
I did a little test with different builds posted here in the forum and my AMD Ryzen 5 3600X under Windows 11. The file used, is a almost 2 hours long DJ set, of electronic music. The fastest build was flac-1.4.1-win64-znver3 (Case).
Don´t want to give the wrong impression, I am not impressed by a lack of license at Github. This could mean the author is happy about the free update. But in contrast, I wonder about the copyright notice in About Scheduler. There might be some calculated ambiguity in there...