[Flac] Is FLAC hardware independent?

[Fernando Alberto Marengo Rodriguez]

Dear list,
We are investigating about some state-of-the-art
lossless audio codecs and their performance in terms of? rate and
compression ratio. Therefore, it is very important to us to know whether a
codec is hardware independent, i.e. if it produces the same output file
regardless of the hardware. Could you please tell me whether FLAC is
hardware independent?
Thank you very much in advance.
Kind regards,

?
Fernando A. Marengo Rodriguez, PhD
Acoustics and Electroacoustics Laboratory
School of Electronic Engineering
Faculty of Sciences, Engineering and Surveying
National University of Rosario
Rosario, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac/attachments/20110516/22b0f1a0/attachment.htm

[Brian Willoughby]

Which "output file" are you referring to? Also, your question is
incompletely specified, because you do not qualify whether the input
is the same when you expect the output to be the same.

When uncompressing, the final results are lossless, therefore it is
hardware independent when you consider the total process.

When compressing, the results depend upon the implementation. In
this respect, the intermediate output file is both hardware dependent
and version dependent. In other words, you can get a different
output file size even on the same hardware.

Perhaps there is a misunderstanding here, by trying to fit FLAC into
the same criterion as lossy formats. Lossless formats do not have a
fixed rate, nor do they have a fixed compression ratio. Lossy
formats throw away information in order to achieve a desired rate or
ratio, but lossless formats cannot throw away information and
therefore cannot reach the same goal every time. Results vary
greatly depending upon the input material and the implementation,
which varies by version and hardware.

Brian Willoughby
Sound Consulting


On May 16, 2011, at 13:51, Fernando Alberto Marengo Rodriguez wrote:
> We are investigating about some state-of-the-art lossless audio
> codecs and their performance in terms of rate and compression
> ratio. Therefore, it is very important to us to know whether a
> codec is hardware independent, i.e. if it produces the same output
> file regardless of the hardware. Could you please tell me whether
> FLAC is hardware independent?
> Thank you very much in advance.
> Kind regards,

[Fernando Alberto Marengo Rodriguez]

Dear list,

> Which "output file" are you referring to?? Also, your question is
incompletely specified, because you do not qualify whether the input is
the same when you expect the output to be the same.

My question is the following: For any encoding option (e.g. -5, default), does the flac encoder produce the same byte-for-byte output regardless of the CPU?


Regards,
Fernando

PS: Here is the answer of David Bryant, the developer of WavPack: "The WavPack codec is hardware independent; the standard "C" encoder will produce the same byte-for-byte output regardless of the CPU it is
running on (assuming a properly working C compiler, of course)."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/flac/attachments/20110517/8af2ead9/attachment.htm

[Nicholas Wilson]

Dear Fernando,

The flac codec is not independent of anything?the format doesn't
specify what the output file must be, just what it could be. The
encoder is free to pick better or worse interpolations as long as it
stores the residuals and outputs it all in a properly formatted
container. If you run the same encoder ported to different
architectures, then the same software will output the same encoded
file, but the crucial thing is that on any architecture, with any
conforming implementation, the audio will decode to exactly match the
original. The intervening stages are uniquely determined, but the
whole process is certainly independent of everything (except software
or hardware bugs!).

Nicholas

-----
Nicholas Wilson: nicholas at nicholaswilson.me.uk (ncw33)
Site and blog: www.nicholaswilson.me.uk
Peterhouse, CB2?1RD ? 86 Heath Road, GU31?4EL



2011/5/17 Fernando Alberto Marengo Rodriguez <fmarengorodriguez at yahoo.com.ar>:
> Dear list,
>> Which "output file" are you referring to?? Also, your question is
>> incompletely specified, because you do not qualify whether the input is the
>> same when you expect the output to be the same.
> My question is the following: For any encoding option (e.g. -5, default),
> does the flac encoder produce the same byte-for-byte output regardless of
> the CPU?
>
> Regards,
> Fernando
> PS: Here is the answer of David Bryant, the developer of WavPack: "The
> WavPack codec is hardware independent; the standard "C" encoder will produce
> the same byte-for-byte output regardless of the CPU it is running on
> (assuming a properly working C compiler, of course)."
>
> _______________________________________________
> Flac mailing list
> Flac at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac
>
>

[Neal B.]

> PS: Here is the answer of David Bryant, the developer of WavPack: "The WavPack codec is hardware independent; the standard "C" encoder will produce the same byte-for-byte output regardless of the CPU it is running on (assuming a properly working C compiler, of course)."

The same is true of flac, as long as you're using the same version of
the encoder, right? The same source code, compiled with the same
options, on different hardware, will yield the same flac output,
right?

Neal

[Brian Willoughby]

On May 21, 2011, at 11:40, Neal B. wrote:
>> PS: Here is the answer of David Bryant, the developer of WavPack:
>> "The WavPack codec is hardware independent; the standard "C"
>> encoder will produce the same byte-for-byte output regardless of
>> the CPU it is running on (assuming a properly working C compiler,
>> of course)."
>
> The same is true of flac, as long as you're using the same version of
> the encoder, right? The same source code, compiled with the same
> options, on different hardware, will yield the same flac output,
> right?
Unless there is conditional compilation in the source. It's entirely
possible to surround a piece of code with an #ifdef that is specific
to one or more processors, or even large groups of processors (big-
endian versus little-endian). I have not looked at every line of the
source for FLAC, but it's possible that there are certain
optimizations that are specific to one processor or another, either
for speed or to avoid processor bugs.

Brian Willoughby
Sound Consulting

[Brian Willoughby]

FLAC is a format which guarantees lossless data preservation. FLAC
does not guarantee a specific or consistent compression ratio. If
you are looking for a guarantee that the compression ratio is
repeatable, then you are looking in the wrong place.

While it is probably true that the same executable will produce the
same FLAC file from the same source file on different PCs, I'm not
sure there isn't any run-time variation based on processor type.

A better approach for you would be to modify your expectation to be
that the compression ratios fall into a range of values, rather than
expect them to be precise. Keep in mind that FLAC is focused on
guaranteeing that the final uncompressed audio samples precisely
match the original audio samples, while secondary concerns such as
the intermediate compression ratio are not guaranteed at all. You
might be able to find repeatable experiments, but it does not change
the fact that FLAC does not have a pre-defined compression ratio.

Brian Willoughby
Sound Consulting


On May 23, 2011, at 09:46, Eri Eri wrote:
> I?m investigating together with Fernando Marengo, and I think our
> doubt might have been misunderstood.
> Let?s say that we have a certain version of Flac (1.2.1 for
> example) and a certain track (?The blue room.wav? for example). If
> we were to compress that same track on different PCs using exactly
> the same Flac executable and command line parameters, would we
> always get exactly the same (bit-by-bit) output file?
>
> Differences in the output files yield different compression ratios.
> We want to make sure our results are consistent and repeatable so
> answering that question is crucial.