Can you put some of this in English?
What is "demux" and "mux"? It sounds nasty but I assume it's an abbreviation for something?
Also, what I think you're saying is that FLAC is just another audio CODEC, as is WAV. Both are
lossless in that they do not throw off any samples or bits, and neither impart any perceptual
encoding. Is that correct?
Here's what I don't get about this discussion. Why would someone want to use FLAC as their primary
lossless format rather than WAV, given that FLAC includes (and features) a data-compression scheme
that inherently puts more data at risk per potentially bad sector in a storage device? Given the low
cost of storage, why not opt for less data at risk per sector?
-- Tom Fine
----- Original Message -----
From: "Dave Rice" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, May 18, 2015 12:11 PM
Subject: Re: [ARSCLIST] Is it time to rethink FLAC ?
> Hi Lou,
>> On May 18, 2015, at 11:49 AM, Lou Judson <[log in to unmask]> wrote:
>> I will admit to not reading the entire post, but have a question:
>> According to my understanding, FLAC is a non-lossy compression scene applied to WAV and PCM
> A FLAC encoding isn't limited to PCM/WAV source, the input to the FLAC encoder is simply the raw
> audio with contextual metadata (bit depth, channel count, sample rate, etc) from another source.
> For instance you could have
> WAV ---demux---> PCM ---decode---> rawaudio ---encode---> FLAC codec ---mux---> FLAC file format
> but you could have
> MP3 ---demux---> MP3 ---decode---> rawaudio ---encode---> FLAC codec ---mux---> FLAC file format
> S/PDIF ---demux---> PCM ---decode---> rawaudio ---encode---> FLAC codec ---mux---> FLAC file
> Most of my archival experience with FLAC involved no WAV file at all but the FLAC resulted
> directly from a digitization (analog source) or data migration (CD-R, DAT, etc).
> It is just as technically feasible to digitize directly to FLAC as it is to scan documents to
> lossless LZW in TIFF or digitize video to JPEG2000 or FFV1. It doesn't matter what type of decoder
> is producing raw audio data but only the the raw audio data is the input to the FLAC encoder. NB
> I'm taking behind the scenes in the transcoding or recording process, it's rare that an operator
> would be connecting these pieces together without some form or programming.
>> not a digital encoding format in itself.
> I would consider FLAC as a digital encoding in itself.
>> If that is so, then one must start with WAV (or other PCM format) files in order to get to FLAC.
>> Therefore FLAC is an accessory, not a proper format.
> I disagree. The raw audio data delivered to a FLAC encoder may come from any source that can
> provide raw audio data and the necessary metadata. This could be a WAV demuxer and PCM decoder but
> there is no such limitation that it must be. It could be from various digital audio transmission
> standards, other decoded lossless or lossy encodings, or other uncompressed audio encodings.
>> If this is so, then it can only be seen as a storage format, not a recording format, and the
>> argument is academic.
> * head desk *
>> Intelligent refutation is welcome.
> I can refute, but the information above seems to be based on presumptions (correct me if I'm
> wrong). If you have a citation that claims that "FLAC is not a recording format", that "FLAC is
> not a digital encoding format", or that "one must start with WAV (or other PCM format) files in
> order to get to FLAC" than I am happy to refute.
> Dave Rice
>> Lou Judson
>> Intuitive Audio
>> On May 18, 2015, at 6:39 AM, Dave Rice <[log in to unmask]> wrote:
>>> Hi all,
>>> I was very pleased to hear that the merits of FLAC as a preservation format were again being
>>> considered by ARSC List; however most of the discussion only considered a few of its advantages
>>> over PCM/WAV such as that the openness of the format and resulting storage requirements, but the
>>> thread hasn't yet covered FLAC's preservation and fixity features over PCM/WAV.