Do Apple Lossless files really sound the same as AIFF?

[Paul R]

Here is one for you to chew on- why does a CD sound different when it is ripped and played back from a computer, compared to when it is played back from a CD player? Even when connected to the same DAC?

 

Almost everyone I know can hear a difference with that one. Same digital data, same DAC.

(Grin)

 

Paul

 

 

One could take this as the operational definition of expectation bias.

[jhwalker]

Here is one for you to chew on- why does a CD sound different when it is ripped and played back from a computer, compared to when it is played back from a CD player? Even when connected to the same DAC?

 

Almost everyone I know can hear a difference with that one. Same digital data, same DAC.

(Grin)

 

Paul

 

But not the same playback "chain". CDPs are well-known for having a certain sound signature, probably as a result of different error correction schemes, different internals, etc. All the more reason to get *accurate* data off the discs and onto a computer where the data can be streamed bit-perfect.

[sandyk]

All the more reason to get *accurate* data off the discs and onto a computer where the data can be streamed bit-perfect.

 

So you are saying that a cheap and nasty DVD Rom, extracting data at perhaps 10 x normal playback speed using E.A.C. is capable of more accurately getting data off a CD than a high quality CD/DVD player with fully functional error correction, playing at normal speed ? BTW, the actual rip speed using E.A.C. after it is correctly calibrated, is very much dependent on the type and quality of the reflective layer and the precision of the burn.

I burned a back up copy of my DS-LOG CD using these ripped tracks to a normal Kodak CD-R , and then ripped it back to HDD to confirm the checksums. Rip speed started out at 2 x.

I later made another couple of comparison CD s(both were the same 2 x 9 different tracks) using a MAM Gold CD-R , and when ripped it read at 7.3 x at the start, and 14.6 x for the last and 14.6 x for the last track track (79 minutes)

I have found the same thing many times before with other comparison CDs when the same tracks were burned to both normal CDs and Gold CDs.

Care to explain these things too, jhwalker ?

 

 

 

 

 

 

Signature

--------------------------------------------------------------------------------

"If you can't hear the difference between an original CD and a copy of your CD, you might as well give up your career as a tester. The difference between a reconstituted FLAC and full size WAV is much less than that, but it does exist."-Cookie Marenco. cookiemarenco.com/

[jhwalker]

So you are saying that a cheap and nasty DVD Rom, extracting data at perhaps 10 x normal playback speed using E.A.C. is capable of more accurately getting data off a CD than a high quality CD/DVD player with fully functional error correction, playing at normal speed ? BTW, the actual rip speed using E.A.C. after it is correctly calibrated, is very much dependent on the type and quality of the reflective layer and the precision of the burn.

I burned a back up copy of my DS-LOG CD using these ripped tracks to a normal Kodak CD-R , and then ripped it back to HDD to confirm the checksums. Rip speed started out at 2 x.

I later made another couple of comparison CD s(both were the same 2 x 9 different tracks) using a MAM Gold CD-R , and when ripped it read at 7.3 x at the start, and 14.6 x for the last and 14.6 x for the last track track (79 minutes)

I have found the same thing many times before with other comparison CDs when the same tracks were burned to both normal CDs and Gold CDs.

Care to explain these things too, jhwalker ?

 

 

 

 

 

 

Signature

--------------------------------------------------------------------------------

"If you can't hear the difference between an original CD and a copy of your CD, you might as well give up your career as a tester. The difference between a reconstituted FLAC and full size WAV is much less than that, but it does exist."-Cookie Marenco. cookiemarenco.com/

 

Not sure what you're asking - didn't see a question in there, other than "care to explain that?", so . . .

 

But, sure, if the rip is proven to be bit-perfect (for example, by comparison to the AccurateRip database), then it is, by definition, perfect (or at least, identical with a number of other samples, so unless *all* of them are wrong . . . ). So it doesn't matter if you use a DVD-ROM, a Plextor CD with "audiophile-grade" SCSI connections, EAC or iTunes, whatever: if the resulting files are identical, they are *identical* - by definition, they are the *same file*. If you don't understand the concept of identical vs. non-identical files, I can't explain it any better that that.

 

That's just how computers work. You can't have a file with identical content that *doesn't* have identical content - it's like saying "the sun is the moon"

 

Now, if the files are *not* identical, then you have a hardware (or software) problem, and that's a whole different story - but if a file has even a single bit wrong, most programs will refuse to read it *at all*.

[sandyk]

That's just how computers work. You can't have a file with identical content that *doesn't* have identical content - it's like saying "the sun is the moon"

That's not what Martin Colloms, and now many others, in C.A. as well, are now reporting about files with identical check sums, NOT necessarily identical content though. Obviously the files don't have identical content if they sound different, no matter what the checksums may be telling you. The same applies with lossless versus the original format, where many are reporting hearing differences that according to people like yourself, are simply not possible.

A couple of years ago Chris openly ridiculed me, yet I am still here, and have now gained quite a bit more credibility from quite a few members, including Chris, due to my painstaking investigations, especially in the USB area, where many suppliers now have products that do basically what I recommended several years ago.

Surely, I must have imagined all those improvements that I reported back then too ?

SandyK

[sone]

why does a CD sound different when it is ripped and played back from a computer, compared to when it is played back from a CD player? Even when connected to the same DAC?

 

 

Almost everyone I know can hear a difference with that one. Same digital data, same DAC.

 

 

Different clocks, different interconnects, different jitter spectrum and characteristics, all of which may have impact on the audio. E.g.

 

 

https://www.jstage.jst.go.jp/article/ast/26/1/26_1_50/_pdf

AES E-Library » The Diagnosis and Solution of Jitter-Related Problems in Digital Audio Systems

AES E-Library » Considerations for Interfacing Digital Audio Equipment to the Standards AES-3, AES-5, AES-11

AES E-Library » Theoretical and Audible Effects of Jitter on Digital Audio Quality

http://202.114.89.42/resource/pdf/4024.pdf

…

 

Interesting, but completely irrelevant to lossless formats.

[Jud]

Different clocks, different interconnects, different jitter spectrum and characteristics, all of which may have impact on the audio. E.g.

 

 

https://www.jstage.jst.go.jp/article/ast/26/1/26_1_50/_pdf

AES E-Library » The Diagnosis and Solution of Jitter-Related Problems in Digital Audio Systems

AES E-Library » Considerations for Interfacing Digital Audio Equipment to the Standards AES-3, AES-5, AES-11

AES E-Library » Theoretical and Audible Effects of Jitter on Digital Audio Quality

http://202.114.89.42/resource/pdf/4024.pdf

…

 

Interesting, but completely irrelevant to lossless formats.

 

Agreed.

[Jud]

This is a discussion about there are differences between lossless formats played through the same channel, not different channels. AAC sounds a lot better out of my Burr Brown than AIFF does out of my iPhone, but so what? The relevant question asked by the OP is whether there's a difference playing ALAC and WAV on the same computer to the same DAC over the same interconnect.

 

The fact that all software being discussed concerts whatever lossless file you're playing in memory then sends the exact same bytes to the DAC means that there is no audio difference between lossless formats.

 

The processor cost of the codec could be an issue if it were CPU or memory intensive, but it's neither—just the opposite. It takes a second to decode about 5 minutes of ALAC audio. Try it yourself:

 

time afconvert --file WAVE --data LEI16@44100 --verbose track_alac.m4a track_alac.wav

 

That's a factor of 300x. So even if the lossless codec were doing something stupid like running constantly with no buffering (it doesn't—the source code link is above), that means at worst a 0.3% CPU load for the codec. But the load for kernel_task is a constant 5–10%, so if it were really the case that the audio of ALAC is degraded by codec processing, computer audio would be a dead letter anyway just from having to run the kernel. But of course it's not and the codec CPU load is irrelevant to audio.

 

I have listened to various lossless formats on my own system to make sure that the codec software itself isn't borked, and I've found all lossless formats to be intisinguishable, as expected with no bugs.

[Emphasis added.]

 

Yep, precisely that quite logical-appearing argument has been made in these forums before. I for one am well aware of it, and I'm guessing others remember it well also.

 

But then we've got these folks who know a fair amount about computers, and specifically about computer audio, who are software player developers. A couple of them (who are actually developers of the two software players I use most) have developed "memory players." Now if the burden of the codec processing specifically, and of the computer's audio processing generally, is indeed audibly insignificant in comparison to the many other tasks the computer's CPU resources are taking on at the same time, a good part of the idea behind memory players is just plain wrong. And in fact the developer of one of the players I use, Damien Plisson, has written a white paper often cited in this forum that spends a good deal of its time talking about his philosophy with regard to coding his player to minimize computer resource use synchronous with audio playback: http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf

 

Now if you're correct and the burden of things like codec processing is audibly insignificant, either folks like Damien and other memory player developers like PeterSt of XXHE know less about computer audio than you do; have managed to fool themselves in the face of available proof to the contrary; or are actively misrepresenting what their software is doing. Or you could be wrong.

 

In the interest of exploring the last possibility, a couple of comments back I proposed a little home experiment with XXHE. Certainly a simple adjustment to the size of a memory player's memory buffer (something that would cause far less of a drain on CPU resources, if any at all, than codec processing) couldn't possibly make an audible difference, could it? Unless the mechanism of that difference is something beyond your current state of knowledge - but within the knowledge of at least one player software developer, so he provides a facility to adjust it. Now your comments have all been reasonably Mac-centric, so perhaps you don't have a Win 7 desktop machine with modern processing and a fair amount of memory ready to hand. If not, fair enough; I would probably not go through the hassle of my proposed experiment in that situation either, so I could hardly expect you to do so. But if you do have the capability ready to hand (or for that matter, for anyone else reading this who has a desktop machine fitting the hardware requirements, with Win 7 installed or readily able to be installed), I'd gently urge you to perform the suggested experiment, for your own curiosity (and possible education, if something happens that your present state of knowledge can't account for) if nothing else.

[4est]

+1

 

[Emphasis added.]

 

Yep, precisely that quite logical-appearing argument has been made in these forums before. I for one am well aware of it, and I'm guessing others remember it well also....... I'd gently urge you to perform the suggested experiment, for your own curiosity (and possible education, if something happens that your present state of knowledge can't account for) if nothing else.

[sone]

if you do have the capability ready to hand (or for that matter, for anyone else reading this who has a desktop machine fitting the hardware requirements, with Win 7 installed or readily able to be installed), I'd gently urge you to perform the suggested experiment, for your own curiosity (and possible education, if something happens that your present state of knowledge can't account for) if nothing else.

 

First lets get something out of the way: Windows 7 has nothing to do with the capability of the box. I happen to use a dual-core Mac Mini with 8 GB, and more recent models have i7 quad cores with 16 GB. But for our purpose, a much less capable box than either of these options is adequate. And as I've already stated, I have checked and am unable to distinguish between ALAC and WAV, as I would expect in the absence of any bugs.

 

Now to your experiment. Rather than searching for "something beyond your current state of knowledge," why don't we try an actual controlled experiment: play a track you enjoy, then burden your CPU a lot and see if you can hear the difference. Here's what I did, compute 10,000 digits of pi over and over using this python script I just cobbled together. You can run it on Windows or any BSD box:

 

pipy.py

#!/usr/bin/env python

 

# Compute pi to lots of digits

 

ndigs = 10000

resttime = 0.05 # about a 50% duty cycle

maxits = 1000

 

import sys

from time import sleep

from sympy.mpmath import mp

mp.dps = ndigs # number of digits

 

its = 0

while True:

# print(mp.pi) # print pi

pipy = str(mp.pi)

print "%d digits of pi on the wall..." % pipy.__len__()

sys.stdout.flush()

its += 1

if its >= maxits: break

sleep(resttime)

 

 

If you want to run continuously and completely load your CPU, then set resttime to 0 seconds. A value of 50 ms gives about a 50% duty cycle.

 

I did this and am unable to distinguish any difference, even running continuously. Why? Like I said, my box is dual core -- there are two CPUs. So even I use up all the cycles on CPU, there's another. And even if I used multi-threaded code and used all the resources on both CPUs, the OS's task manager will still give more than sufficient cycles to decode ALAC and send it to DOUT. And that's just on a dual-core. Most modern boxes are quad cores, and octo-cores are on the near horizon. I expect I could begin to have an impact if I reniced my pipy process to hog all the cycles, at the cost of bring the entire box to it's knees all at once.

 

So please tell us: at what duty cycle does a CPU hogging process like computing a bunch of digits of pi begin to impact your audio?

 

As for software based on limiting codec cycles, I'll let you all draw your own conclusions. That said, I have had my own experiences with Apple audio bugs, and like the fact that people and companies are pushing to make sure computer audio isn't borked.

[Paul R]

Interesting, but completely irrelevant to lossless formats.

 

The format of music data on a CD is a WAV/AIFF file, which is lossless and uncompressed. Of course, all your comments apply to that. Now why are you having difficulty taking the next logical step and saying that when the files are stored on a computer, their format may make a difference? Every one of your points, different clocks, interconnects, and jitter spectrums may apply.

 

Some of them certainly apply, albeit with a lesser magnitude, to different file formats as well.

 

Again, none of this controversial, so what are you trying to prove?

 

I grant you that Alex (SandyK) has some controversial data and opinions on this, but even Alex doesn't dispute that identical files are identical. His point is more that seemingly identical files must not be identical, because they can be made to sound different. The operator for this is debatable, but it isn't all that controversial. Seemingly identical WAV files sound different based upon the playback chain.

 

I guarantee that identical video data will look different depending upon the power supplies used, and I honestly do find that audio sounds different based upon the power supplies used. Again, not controversial.

 

So the question is again, what is your purpose in this argument? You are not presenting any unfamiliar arguments at this point- do you have some new ideas?

 

-Paul

[Jud]

First lets get something out of the way: Windows 7 has nothing to do with the capability of the box. I happen to use a dual-core Mac Mini with 8 GB, and more recent models have i7 quad cores with 16 GB. But for our purpose, a much less capable box than either of these options is adequate. And as I've already stated, I have checked and am unable to distinguish between ALAC and WAV, as I would expect in the absence of any bugs.

 

 

Tunnel vision much?

 

I mentioned Windows 7 and the hardware requirements for the XXHE-specific experiment I requested because those are, by consensus of XXHE users and developer, the conditions under which XXHE runs best, i.e., would be best able to show any audible difference between SFS settings. My OS and hardware suggestions thus have only as much to do with "the capability of the box" as the developer feels (and has written) are best for running his software.

 

Part of the reason I proposed the experiment I did is to open up the idea that, irrespective of the fact that the only mechanism you appear able to think of is CPU (or other resource) utilization, there may well be causes of audible differences you haven't yet thought of. That's why I mentioned the SFS setting specifically, because any effect on CPU utilization ought to be negligible. So yes, I could run the experiment you suggest, and well may. I will not be surprised if I come to the same conclusion you have, but any conclusion from your experiment does not necessarily relate to the outcome of the one I suggested.

[Superdad]

The format of music data on a CD is a WAV/AIFF file, which is lossless and uncompressed.

 

Sorry Paul, but that statement is not true at all. In fact the single largest reason why computer audio--even with super cheap optical drives--can store and restream a bitstream superior to the most mega-buck CD player transports has to do with the difference in how the bits are read off the disc.

It is all about the mode in which the data is read, and in the case of CD players, they have to do all sorts of crazy realtime processing, including constantly varying the speed of the drive and moving/refocusing the laser to be able to play the CD.

I'll search for further info (my engineer friend gave me and John Atkinson a long verbal lesson on this at CES about 7 years ago) about what machinations a CD player takes to play a disc versus the CDROM DATA MODE 1 that we use with a CDROM drive and ripping s/w. But to get us started, here are some relevant Wikipedia excerpts from the "Compact Digital Disc Audio" page:

 

FILES

Unlike on a DVD or CD-ROM, there are no "files" on a Red Book audio CD; there are only the physical pits and lands, which in turn represent a single encoded data stream, which ultimately represents one continuous stream of LPCM audio data, and a parallel, smaller set of 8 subcode data streams. Computer operating systems, however, may provide access to an audio CD as if it contains files. For example, Windows represents the CD's TOC as a set of Compact Disc Audio track (CDA) files, each file containing indexing information, not audio data.

In a process called ripping, Digital Audio Extraction software can be used to read Red Book audio data and store it in files. Common audio file formats for this purpose include WAV and AIFF, which simply preface the LPCM data with a short header...

 

 

DATA ENCODING

Before being written to the disc, the LPCM audio data is divided into 12-sample frames (six left and right samples, alternating) and subjected to CIRC encoding, which segments and rearranges the data and expands it with "parity" bits in a way that allows occasional read errors to be detected and corrected. 8 bits of subcode data are added to each frame. The resulting 291-bit frame data is EFM-modulated, where each 8-bit word is replaced with a corresponding 14-bit word designed to reduce the number of transitions between 0 and 1, thus reducing the density of physical pits on the disc and providing an additional degree of error tolerance. 3 "merging" bits are added before each 14-bit word for disambiguation and synchronization. A 24-bit word is added to the beginning of each frame to assist with synchronization, so the reading device can locate frames easily. The EFM, merging bits, and sync words thus expand each frame from 291 to 588 bits of "channel data". The frames of channel data are written to disc physically in the form of pits and lands, with each pit or land representing a series of zeroes, and with the transition points—the edge of each pit—representing 1.

The disc's audio data stream is continuous, but has three parts: the main portion, which is further divided into playable audio tracks, is the program area. This section is preceded by a lead-in track and followed by a lead-out track. The lead-in and lead-out tracks encode only silent audio, but all three sections contain subcode data streams. The lead-in's subcode contains repeated copies of the disc's Table Of Contents (TOC), which provides an index of the start positions of the tracks in the program area and lead-out. The track positions are referenced by absolute timecode, relative to the start of the program area, in MSF format: minutes, seconds, and fractional seconds called frames. Each timecode frame is one seventy-fifth of a second, and corresponds to a block of 98 channel-data frames—ultimately, a block of 588 pairs of left and right audio samples. Timecode contained in the subchannel data allows the reading device to locate the region of the disc that corresponds to the timecode in the TOC.

In the 1990s, CD-ROM and related Digital Audio Extraction (DAE) technology introduced the term sector to refer to each timecode frame, with each sector being identified by a sequential integer number starting at zero, and with tracks aligned on sector boundaries. An audio CD sector corresponds to 2,352 bytes of decoded data. The Red Book does not refer to sectors, nor does it distinguish the corresponding sections of the disc's data stream except as "frames" in the MSF addressing scheme.

 

DATA STRUCTURE

The smallest entity in a CD is a channel-data frame, which consists of 33 bytes and contains six complete 16-bit stereo samples: 24 bytes for the audio (two 8-bit bytes × two channels × six samples = 24 bytes), eight CIRC error-correction bytes, and one subcode byte, used for control and display. Each byte is translated into a 14-bit word using eight-to-fourteen modulation, which alternates with three-bit merging words. In total there are 33 × (14 + 3) = 561 bits. A 27-bit unique synchronization word is added, so that the number of bits in a frame totals 588 (which are decoded to only 192 bits music (the 24 bytes mentioned above)).

These 588-bit channel-data frames are in turn grouped into a larger structure, confusingly dubbed frame in the timecode-based addressing system of Red Book audio CDs. In CD-ROM and related technology, including Digital Audio Extraction (DAE, or ripping of audio CDs), the same structure is called a sector and is addressed with simple, sequential, non-negative integer numbers. Regardless of which name is used, each of these structures contains 98 channel-data frames, totaling 98 × 24 = 2352 bytes of music. The CD is played at a speed of 75 frames (or sectors) per second, thus 44,100 samples or 176,400 bytes per second.

 

FRAMES

On a Red Book audio CD, data is addressed using timecode expressed in minutes, seconds and frames (mm:ss:ff), where one frame corresponds to 1/75th of a second of audio: 588 pairs of left and right samples. This frame is distinct from the 33-byte channel-data frame described above, and is used for time display and positioning the reading laser. When editing and extracting CD audio, this frame is the smallest addressable time interval for an audio CD; thus, track boundaries only occur on these frame boundaries.

On a CD-ROM data disc, the timecode frames are called sectors. Since error concealment cannot be applied to non-audio data in case the CIRC error correction fails to recover the user data, a third layer of error correction is defined, reducing the payload to 2048 bytes per sector for the Mode-1 CD-ROM format. To increase the data-rate for Video CD, Mode-2 CD-ROM, the third layer has been omitted, increasing the payload to 2336 user-available bytes per sector, only 16 bytes (for synchronization and header data) less than available in Red-Book audio.

 

LOGICAL STRUCTURE

The largest entity on a CD is called a track. A CD can contain up to 99 tracks (including a data track for mixed mode discs). Each track can in turn have up to 100 indexes, though players which handle this feature are rarely found outside of pro audio, particularly radio broadcasting[citation needed]. The vast majority of songs are recorded under index 1, with the pre-gap being index 0. Sometimes hidden tracks are placed at the end of the last track of the disc, often using index 2 or 3. This is also the case with some discs offering "101 sound effects", with 100 and 101 being indexed as two and three on track 99. The index, if used, is occasionally put on the track listing as a decimal part of the track number, such as 99.2 or 99.3. (Information Society's Hack was one of very few CD releases to do this, following a release with an equally obscure CD+G feature.) The track and index structure of the CD carried forward to the DVD as title and chapter, respectively.

[Superdad]

REGARDING SONY BLUSPEC CDs:

 

In a PM sent to me by Sandyk, he pointed me towards Sony's "Feel the Difference of the Blu-spec CD , Rock Selection" 2-CD set and indicated that several of you may have listened to these discs and heard the benefit of the more accurate blue laser production of the glass master used to create the Blu-Spec disc of this set.

He even asserted that the Blu-Spec advantage survives DAE (digital audio extraction to hard drive), and that this too has been heard by several people around here.

 

Well, I would like to hear that for myself, but I am not inclined to pony up $30 for the privilege of owning these discs. Is anyone willing to share (by some method) one track from both discs (same tune, in AIFF) so that I can come to my own conclusion? Given that Sony produced the discs specifically so people could compare the glass mastering techniques, I can't imagine they would be too upset if one track got uploaded somewhere.

 

I am a very open-minded guy, but I am still having trouble wrapping my head around the idea that two identical checksumed audio files on a hard drive in the same container format will sound different.

No problem accepting that realtime playback of the CDs--with all the interpolating error correction and variable speed that a CD player has to use--can be improved upon by a "sharper" pressing made possible by a better glass master. Recording studios and musicians have know that for decades, and CDRs I sometimes make regularly sound better (in a CDP) than the original discs. Nothing new there.

[Paul R]

Well, sortof. As you noted, the data on a CD is Linear PCM data (LPCM) and the data in a WAV or AIFF file is exactly that same LPCM data. The pits and lands do not directly identify the 1's and zeros, rather a transition from pit to land indicates a 1 and no transition land to land a zero, so the conversion to on-disk WAV or AIFF format is still a format conversion, but the end result is the data is identical of course.

 

The format of an audio CD is strict, but on the disk, it is still divided into sectors - sections for a pure audio CD - and each section holding 98 frames. Each frame holding 36 byes, 24 bytes of which are the audio data. The rest is pretty much exactly as you described (well done, by the way). On a CD-ROM, the sectors are what? 2352 bytes?

 

Logically, a track on an Audio CD is equivalent to a file on disk, so it is convenient to think of them that way. Forgetting for the moment they are better described as collections of consecutive light rails. So yes, I am wrong in the exact sense, but it was mostly because I was too lazy to write out a nice essay like you did.

 

In any case, really nice post.

 

-Paul

[Superdad]

Thanks for the kindness Paul, but all except the first two paragraphs were my cut-and-paste selections from Wikipedia.

 

My intent was not to take you to task for a semantic slip, rather it was to call out what I think is the core of all this back and forth about file, disc, data, and sound equivalency--or lack thereof--between music stored on CDs and that which we store on our hard drives.

 

The technology and techniques involved in realtime CD playback by a traditional CD player or transport are VERY different than what happens with DAE to a hard drive, and therein lay THE key advantage of computer audio. It is also why I am circumspect about the relevance/benefits of higher precision glass mastering techniques such as Blu-Spec and SHM (respectively) to people who always rip their CDs to hard drive (see my posts #114 and #98 where I quote Barry Diament agreeing).

 

Not that I am opposed to record companies taking more care in mastering and pressing--it often means they are being a bit more careful in the earlier part of the audio chain, including closer to original tapes, better A/D, less compression--but not always!

 

By the way, there are a few high-end audio designers/manufacturers (my friend Jeff Kalt at Resolution Audio comes to mind) who are producing CD players utilizing DAE modes (CAV-constant angular velocity, zero interpolation, etc.) instead of standard CDP playback. IDE CD/DVD drives are thin and cheap, and processors are comparatively easy to program...

I bet that his Cantata Music Center could care less about pressing quality differences.

[sone]

Well, sortof. As you noted, the data on a CD is Linear PCM data (LPCM) and the data in a WAV or AIFF file is exactly that same LPCM data. The pits and lands do not directly identify the 1's and zeros, rather a transition from pit to land indicates a 1 and no transition land to land a zero, so the conversion to on-disk WAV or AIFF format is still a format conversion, but the end result is the data is identical of course.

 

Your comments are filled with factual errors and misconceptions. For example the format of lossless files on an HD or SSD are not as you describe. The information is spread over blocks of size:

 

stat -f "%k" track_orig.wav

4096

 

So storage of uncompressed audio files is typically spread over many blocks.

 

And all the clocking issues occur after the audio information has been decoded from disk, compressed or not, and are in active memory.

[Jud]

And all the clocking issues occur after the audio information has been decoded from disk, compressed or not, and are in active memory.

 

Depends. Clocking issues from the source (compact disc, HDD, etc.) may be "reassociated" with the clocking of the data from the DAC's buffer by a PLL, for example.

[burnspbesq]

Obviously the files don't have identical content if they sound different, no matter what the checksums may be telling you.

 

Sorry, that's not even a tiny bit "obvious," unless you've controlled every other variable in the signal chain. Have you?

[Audio_ELF]

Must...stop...reading...

[Jud]

Must...stop...reading...

 

Didn't you say the very same thing at this point in an identical thread a couple of years ago? ;-)

 

Deja vu all over again....

[Audio_ELF]

Didn't you say the very same thing at this point in an identical thread a couple of years ago? ;-)

 

Deja vu all over again....

I think it was a few pages further in last time...

[souptin]

Didn't you say the very same thing at this point in an identical thread a couple of years ago? ;-)

 

Deja vu all over again....

 

I think you'll find it was the exact same words, identical in ascii codes, same font style, identical size... but completely different meaning. Really after all this time you should understand such things.

[Paul R]

Wow- amazing. Tell me, are you talking about disks or CDs? They are not the same you know.

 

The "blocks" you are talking about are known as "sectors" on a hard disk drive, and while 4096bytes is common today for a sector size, there are still plenty of disks out there that have 512byte sectors on them. Moreover, it is a simple matter to read/write to a disk, skipping the OS and filesystem bit, including writing consecutive files, in which the data file is laid out in an order so that the next physical sector (block) read is the next block needed for a file.

 

Or to scatter the files around the disk in a random manner. Or to write the sectors in such a way as to require the disk to work very hard indeed.

 

I did that a couple years ago, and yes, it can make an audible difference in the sound. Filled up many pages of my notebook with the odd results from that. It is, however easy to do. I suggest you try it for yourself and get the facts before going on about theory.

 

I'm trying to be nice to you kid, but let me be straight with you - you pretty obviously are talking through your nose about this stuff.

 

-Paul

 

 

Your comments are filled with factual errors and misconceptions. For example the format of lossless files on an HD or SSD are not as you describe. The information is spread over blocks of size:

 

stat -f "%k" track_orig.wav

4096

 

So storage of uncompressed audio files is typically spread over many blocks.

 

And all the clocking issues occur after the audio information has been decoded from disk, compressed or not, and are in active memory.

[Paul R]

I agree with you. -Paul

 

 

Thanks for the kindness Paul, but all except the first two paragraphs were my cut-and-paste selections from Wikipedia.

 

My intent was not to take you to task for a semantic slip, rather it was to call out what I think is the core of all this back and forth about file, disc, data, and sound equivalency--or lack thereof--between music stored on CDs and that which we store on our hard drives.

 

The technology and techniques involved in realtime CD playback by a traditional CD player or transport are VERY different than what happens with DAE to a hard drive, and therein lay THE key advantage of computer audio. It is also why I am circumspect about the relevance/benefits of higher precision glass mastering techniques such as Blu-Spec and SHM (respectively) to people who always rip their CDs to hard drive (see my posts #114 and #98 where I quote Barry Diament agreeing).

 

Not that I am opposed to record companies taking more care in mastering and pressing--it often means they are being a bit more careful in the earlier part of the audio chain, including closer to original tapes, better A/D, less compression--but not always!

 

By the way, there are a few high-end audio designers/manufacturers (my friend Jeff Kalt at Resolution Audio comes to mind) who are producing CD players utilizing DAE modes (CAV-constant angular velocity, zero interpolation, etc.) instead of standard CDP playback. IDE CD/DVD drives are thin and cheap, and processors are comparatively easy to program...

I bet that his Cantata Music Center could care less about pressing quality differences.