| Newsgroups |
gmane.comp.audio.eac.user |
| Message-ID |
<[email protected]> |
> To quote from the official FLAC website, "FLAC stands out as the fastest and most widely supported lossless audio codec, and the only one that at once is non-proprietary, is unencumbered by patents, has an open-source reference implementation, has a well documented format and API, and has several other independent implementations.”
I was unaware that the official FLAC website states that FLAC is the best lossless format. That is convincing. ;)
The Apple Lossless Audio Codec project, which Apple released as open source in 2011, contains the sources for the ALAC encoder and decoder. Also included is an example command line utility, called alacconvert, to read and write audio data to/from Core Audio Format and WAVE files. I would call those “open-source reference implementations.” ALAC is not “encumbered by patents” because the Apache license explicitly grants “a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license.” There are also independent implementations of ALAC, at least one of which was created before ALAC was open-sourced.
> Not to disparage Fred's expertise in any way, but even the European Broadcasting Union uses FLAC, and not ALAC.
The European Broadcasting Union adopted FLAC in October of 2007, when ALAC was still a proprietary, closed source CODEC. That the EBU did not revisit that decision when ALAC was open-sourced by Apple four years later is hardly evidence of the superiority of FLAC.
> The format is standardized. It is supported by an organization (xiph.org) that guarantees that. Being also a "de facto" standard is actually an advantage: it means that many products, organizations, and people have chosen to use it in preference to something else, so it is more likely to be supported on any platform.
Here’s an example of the standardization documented on Xiph’s website:
> What kinds of tags does FLAC support?
>
> FLAC has it's own native tagging system which is identical to that of Vorbis. They are called alternately "FLAC tags" and "Vorbis comments". It is the only tagging system required and guaranteed to be supported by FLAC implementations.
>
> Out of convenience, the reference decoder knows how to skip ID3 tags so that they don't interfere with decoding. But you should not expect any tags beside FLAC tags to be supported in applications; some implementations may not even be able to decode a FLAC file with ID3 tags.
You can have a FLAC file with an ID3 tag that works on the reference decoder, but the tag information won’t be processed or recognized. Other applications may not even be able to decode that file. That’s not a standard. It’s a mess. Either ID3 tags are acceptable or they are not. If they are not, then the decoder should not be written so as to allow them. If they are, then they should be part of the spec. The web is filled with people complaining about ID3 tags in FLAC files, including those added as a default by EAC: https://www.mediamonkey.com/forum/viewtopic.php?t=30377
Another “standardization” issue is the use of "Vorbis comments” for tagging. Saying “here’a a place for you to make up field names and assign text to them” is a standard. But it is a problematic standard since, according to xiph, "No single or group of field names is mandatory; a comment header may contain one, all or none of the names in this list.” I won’t belabor that point as I’m sure you can see the ramifications yourself.
> Anyway, it's a non-issue, since one can convert back and forth between FLAC and ALAC without any loss (except your own time).
Provided that your freeform Vorbis comment field names align with the MP4 tag rigidly specified tag names.
The only significant advantage that I can see for FLAC is its ability to detect, but not correct, file corruption like flipped bits. Apple blew it when they didn’t include this, but it’s not a deal-breaker for me.
Apple has sold in excess of 2.2 billion iPhones, 360 million iPads, and 100 million iPods, so I don’t think that we are wanting for devices that natively, without third party add-ons, support ALAC but not FLAC. Of course, if your devices support FLAC and not ALAC, then you’re probably better off standardizing on FLAC.
P.S. — I fully expect that I screwed something up in all of that, so I’m putting on my Nomex suit.
> On Sep 29, 2020, at 2:22 PM, Mark Fishman [email protected] [EAC] <[email protected]> wrote:
>
>
> Not to disparage Fred's expertise in any way, but even the European Broadcasting Union uses FLAC, and not ALAC. To quote from the official FLAC website, "FLAC stands out as the fastest and most widely supported lossless audio codec, and the only one that at once is non-proprietary, is unencumbered by patents, has an open-source reference implementation, has a well documented format and API, and has several other independent implementations."
>
> The format is standardized. It is supported by an organization (xiph.org) that guarantees that. Being also a "de facto" standard is actually an advantage: it means that many products, organizations, and people have chosen to use it in preference to something else, so it is more likely to be supported on any platform.
>
> Anyway, it's a non-issue, since one can convert back and forth between FLAC and ALAC without any loss (except your own time).
>
> Cheers -- m.
>
> --
> It is hard to believe a man is telling you the truth when you know you would lie if you were in his place.
> -- H.L. Mencken
>
>