Prev: Xcode + linux
Next: Where to find Apple�s list of security patches?
From: MartinC on 3 Aug 2010 03:07
Wes Groleau wrote:

> No I don't. He mentioned Apple lossless.
> You said it was a bit-copy, and I questioned that.

Yes, and so I tried to explained it with ZIP - I think that perfectly
explains it.

The archive - not a bit-copy
The expanded content - a bit copy

> I am fully aware of the difference between loss of quality
> and loss of size. But not being an audiophile, I am less
> aware of more subtle differences in algorithms.

For Apple Lossless, FLAC, APE, WV the subtle differences will result in
different file sizes. For each specific WAV or AIFF file, they will have
different compression ratios. But the audio-samples will all extract 1:1
bit-by-bit. Therefore: lossless and bit-copy. For picture files this is
something like TIFF.

For MP3, AAC, WMA the differences in algorithms will result in loss of data,
therefore the expanded files will have different sample-values, therefore
this is called "lossy". For picture files this is something like JPEG.

So to answer the original question one more time: No, Apple Lossless will
not create "subtle differences" in sound, the expanded file will not be just
"virtually indistinguishable", it will be *identical*, lossless, bit-copy,
period, dot.

And if you really don't want to believe it, and if you don't want to
test/verify it with Audacity, then just use FLAC... but don't look at the
filesize, it will be smaller than the original ;-)

From: MartinC on 3 Aug 2010 03:48
MartinC wrote:

one more thing (warning: it's getting technical now).

Regarding audio files, the term "bit-copy" must always refer to the
audio-samples and never to the "host file" - and this includes the
uncompressed formats.

Both AIFF and WAV files (by definition "bit-copy" formats) have various
sorts of headers, tags and so called "meta-information" attached to it. Some
is public (like artist names, titles, even CD sleeves), others are internal
and "private" to the audio software that created it, it can be things like
time-stamps or window positions.

None of this has anything to do with sound, it is just some extra data
sticked to it.

For that reason, WAV/AIFF files itself are hardly ever "bit copies". If I
open/create an audio file with my audio editor, save it as "sample1.wav" and
then save it *immediately* again as "sample2.wav", then - surprise surprise
- the two files "sample1.wav" and "sample2.wav" are not identical, i.e. the
whole files will have different .md5 checksums. This is because my editor
adds a time-stamp and if you save it again a few seconds later, the
time-stamp will be different.

For that reason it is pointless to use the term "bit-copy" for the
(container) file itself, because even WAV and AIFF will hardly *ever* be
bitwise identical.

The thing that matters are the audio-sample values "inside", this is the
audio information that gets processed by audio players and opened by audio
editors. If these samples are identical, then the music is *identical*.

For that reason, the following test will fail:
- create a file "sample1.wav"
- convert it with ALE to "sample2.m4a"
- convert the ALE to "sample2.wav"
- compare the *files* "sample1.wav" and "sample2.wav"

The files will most likely be different, because the tools added some
different "stickers" to them...

If you really want to check if (any) two audio files are "audio bit-copies"
then you need to do this:

- get a proper audio editor, Audacity will do (it's free)
- open file "sample1"
- open file "sample2" as a second *track* in the same document
- select track "sample1"
- invert the amplitudes (Menu Effect > Invert)
- select both tracks
- combine both tracks (Menu Tracks > Mix and Render)

Now if the files were *identical* you will get a complete flatline, like the
heartbeat of someone who died 100 years ago.

In order to really see, do the following
- Menu Effect > Normalize to 0 dB

If there would have been the *slightest* difference in a single sample, then
this spot would sky-rocket to 100%. If it still is a flat line, then the
audio was totally and utterly identical in the first place.

From: Wes Groleau on 3 Aug 2010 08:39
On 08-03-2010 03:07, MartinC wrote:
> So to answer the original question one more time: No, Apple Lossless will
> not create "subtle differences" in sound, the expanded file will not be just
> "virtually indistinguishable", it will be*identical*, lossless, bit-copy,
> period, dot.

The original wasn't a question, and it didn't even mention the file.
He said he had heard it was indistinguishible and you said it was a
bit-copy, meaning the stream. But since you didn't say so, I'm not
the only one who thought you were making an incorrect statement
about the format.

> And if you really don't want to believe it, and if you don't want to

I have never said I didn't want to disbelieve what you meant.
I was attempting to make a non-hostile correction to what you
appeared to be saying.

--
Wes Groleau

"Beware the barrenness of a busy life."
-- George Verwer
From: Wes Groleau on 3 Aug 2010 08:44
On 08-02-2010 19:24, Ian Gregory wrote:
> Of course the*compressed* file is not a bit-copy (if it was it wouldn't
> be compressed), but you can't listen to a compressed file without first
> decompressing it, and the decompressed file (for any lossless codec such

I suspect that there is no decompressed file in most cases, just a large
buffer in RAM or VM. But that's based on general software engineering
experience, not on any audio work.

Since I have little interest in audio, I'll give you and Martin the BOTD
and assume you are experts. All the other people who interpreted
"bit-copy" the way I did will have to make up their own minds.

--
Wes Groleau

Conservatives are funny …
http://Ideas.Lang-Learn.us/barrett?itemid=1543
From: MartinC on 3 Aug 2010 14:55
Wes Groleau wrote:

> The original wasn't a question, and it didn't even mention the file.
> He said he had heard it was indistinguishible and you said it was a
> bit-copy, meaning the stream. But since you didn't say so, I'm not
> the only one who thought you were making an incorrect statement
> about the format.

Yes, that was the core of the misunderstanding (here in this thread), and
that was why I tried to explain it again in much detail...

As I pointed out, even WAV files (that are, like AIFF, the plain integer
values stored on audio CD plus some headers in a wrapper) will usually be
binary different due to added private metadata used by most programs.

For that reason, using the term "bit copy" for the whole file doesn't make
sense at all, and once you know this, you start to forget about it and only
use terms like "bit copy" regarding the plain audio data. Whenever I wrote
"bit-copy", I meant the audio and not the wrapper file. Just as you would
say for ZIP and RAR (a file "demo.txt" in an archive "demo.zip" is not a
bit-copy of "demo.zip", but a bit-copy is stored inside "demo.zip" - to me
that is and was *so* obvious that I didn't point it out - sorry :-)

The myth that Apple Lossless actually changes the audio data in some way (so
that the audio isn't preserved 1:1) is well spread, and I wanted to point
out that this is wrong - ALE is not a matter of "you can't hear a
difference", it really is "there is no difference".

Having said all this, I just remembered one weird detail. FLAC is known as
lossless, but if I remember it correctly then it once got a lossy flavour. I
think the original creator wanted to have an option where you can either
chose lossless compression or some lossy variant. But the latter was never
very popular, and I've never seen a tool (on Mac) that even has it. The only
option for FLAC is the length of time the CPU takes to compress - you can
compress faster and get slightly bigger files, or slower with slightly
smaller files. However, this only concerns the optimization of the
algorithm, it doesn't change audio bits.

So if you ever read something about FLAC being lossy, then there is a small
chance that the text relates to a very early version that died a long time
ago. "Today's FLAC" is always only the lossless variant.


First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Xcode + linux
Next: Where to find Apple�s list of security patches?