pfarrell Wrote: 
> Every Unix I know, Linux, etc. has a copy of diff,
> and it has a --binary switch.
Pat, I guess maybe you have a different version of diff than I do, but
I've checked 3 different versions and none of them have a --binary
switch.  Specifically, I checked diff on OS X (GNU diffutils version
2.7), diff on Linux (GNU diffutils 2.8.1), and diff on Solaris (version
unknown).  I read the man pages for all for each one, and none of them
included --binary.

On OS X and Linux, when comparing two different binary files diff
simply said "Binary files <X> and <Y> differ."  It gave the same result
regardless of --binary, meaning it was ignoring the (presumably
unrecognized) switch.  On Solaris, diff complained --binary was an
illegal option.  The only way I could see any differences was to use
the --text switch, though that output was pretty much unreadable.

So, the good news and the weird news.  First the good news: it does
appear that ALAC is truly lossless and converts back to the same raw
data as the original music, at least when using iTunes to do the
conversion.  Using the mov123 utility (built-in to SlimServer) doesn't
generate the same files as using iTunes to do the conversion.  I'm not
quite sure what the reason is... using mov123 generates files that are
about 50KB smaller than iTunes-generated AIFF files.  It may be that
AIFF includes support for metadata, and the iTunes-generated files
include that metadata while the mov123-generated files do not.  (Note
that the 'file' utility recognizes AIFF, WAV, FLAC, and other audio
formats, but it says the mov123 output file is just "data" ...
apparently no recognized audio format.)

Specifically, I used iTunes to create an ALAC file from the raw CD
track, then used iTunes to convert that ALAC file to AIFF.  I then used
iTunes to convert the raw CD track directly to AIFF.  The resulting
filesizes were identical, but the files DID differ somewhat, however
the differences were minor - only a few bits out of the entire 48MB
files were different.  As a check, I used iTunes to convert the raw CD
track directly to AIFF a *second* time, and compared this to the first
raw-to-AIFF file.  They had the same filesize but ALSO differed in a
similar manner to how the ALAC-to-AIFF file differed.  Thus, I suspect
that iTunes is incorporating time-specific values in the AIFF metadata,
which would explain why two raw-to-AIFF files generated at different
times differ by a few bits, yet have the same filesizes.  The fact that
the ALAC-to-AIFF file differed in the same way makes me reasonably
confident that the original raw data is being properly recreated from
ALAC.

Unfortunately, there was no way for me to make sure that the output
from mov123 really was the same as the original raw data.  Through its
optical-drive drivers and various voodoo disk caching mechanisms, OS X
mounts the CD with the tracks already represented as AIFF files with
metadata, i.e. the track files are already properly named (not just
"track 1") and include other non-audio information.  So without some
independent utility to turn the CD track files (mounted and accessed as
AIFF files even directly from the CD) into the same raw output as mov123
provides, I can't verify that mov123 actually turns ALAC into the same
raw data as on the CD.  BUT... the results using iTunes do make me
reasonably confident that ALAC is converted properly back into the true
raw data.

Now the weird news... since OS X virtually pre-processes the CD tracks
and represents them as AIFF files, they are accessed as big-endian. 
When I use 'flac' to convert these to FLAC with --endian=big, the
resulting FLAC file has almost the same size as the raw data, i.e.
there is ZERO compression!  But if I use --endian=little, with no other
changes in the encoding options, the resulting filesize is 40% smaller. 
Wha?!

Anyway, though I'd update on that issue... it DOES seem ALAC is
properly lossless and the original raw audio can be reproduced, at
least when using iTunes... though what I *can't* verify is that mov123
properly reproduces the original raw audio, because of the apparent
difference between AIFF and whatever mov123 is outputting.


-- 
cepheid
------------------------------------------------------------------------
cepheid's Profile: http://forums.slimdevices.com/member.php?userid=3845
View this thread: http://forums.slimdevices.com/showthread.php?t=22635

_______________________________________________
audiophiles mailing list
audiophiles@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/audiophiles

Reply via email to