iTunes AIFF Encoder

[Freann]

Error correction is part of the encoding of the bit stream into pits and lands. You have to un-encode it (Cross-Interleaved Reed-Solomon Code) )

[kirkmc]

Here's someone who tested dragging files to the Finder and ripping them, and found that they are exactly the same as files ripped with iTunes, or with several other apps:

 

CAS 5: CD Ripping | Design w Sound

[goldsdad]

I meant why would it be used for a Finder copy? It's used when ripping if you're converting to other formats than AIFF/WAV, because iTunes is sort of playing the music (or at least analyzing it to be able to compress it); do we even know if it's used when you rip AIFF/WAV files?

 

Either you are completely confused or you are playing a game with these posts. I do not have the patience to continue with this, either way, and now wish I'd stayed out of the thread.

[Freann]

Ok, back to the original question :-)

I don’t doubt his findings.

 

But the issue is/was: for redbook CDs you cannot do a checksummed copy OS level operation. Ripping is not file copying.

[kirkmc]

Either you are completely confused or you are playing a game with these posts. I do not have the patience to continue with this, either way, and now wish I'd stayed out of the thread.

 

I'm not confused; see the link I posted just above, where someone compared files.

 

I don't know why audiophiles think there's something magical about CDs; they're just data storage devices. They store data in different ways from computers, but it's digital all the way down, and that data can me processed the same way any other digital data can.

[kirkmc]

Ok, back to the original question :-)

I don’t doubt his findings.

 

But the issue is/was: for redbook CDs you cannot do a checksummed copy OS level operation. Ripping is not file copying.

 

As I said just above, CDs are just data storage devices. Why can't you do a checksum by reading and copying at the same time, comparing what's read with what's written. It seems quite trivial to do that.

[Freann]

The magic is that we are dealing with non-packet, un-checksummable, continous bit stream data. It is totally different to how computers work. No really, completely different. A CD is more like a vinyl record than a harddrive.

 

Again. This is pre-personal computer 70s tech.

[kirkmc]

The magic is that we are dealing with non-packet, un-checksummable, continous bit stream data. It is totally different to how computers work. No really, completely different. A CD is more like a vinyl record than a harddrive.

 

Again. This is pre-personal computer 70s tech.

 

But the AIFF file contains the exact same data as is on the CD. It's not converted in any way, other than to have headers added to it so a computer can see it as a file. It doesn't matter if it's a continuous stream, because the ToC defines where each track begins and ends

 

That person who did the test (my link a few posts up) compared the "ripped" and "dragged" files and found they were exactly the same.

 

The original question was about ripping AIFF files; I think it's clear that dragged AIFF files are the same. That's all I wanted to say a couple of pages back; I see nothing that suggests that they're not the same.

[Daudio]

Why not? If the OS is creating a filesystem, it has to know where the "files" begin and end.

 

The OS does not 'create' a filesystem ! Disk Utility can create a 'Volume' and format it for a number of different filesystem types (HFS+, NTFS, etc.). The Finder can show, create, move, and delete files within a volume.

 

Getting the vocabulary right might help get other concepts right too.

 

 

But the AIFF file contains the exact same data as is on the CD. It's not converted in any way, other than to have headers added to it so a computer can see it as a file.

 

Nope, the data on the CD is in a very different encoding scheme (and error detect/correct mechanisms) then within an AIFF, FLAC, or whatever file format. Go look it up in Google, before digging yourself into an even deeper hole

[kirkmc]

The OS does not 'create' a filesystem ! Disk Utility can create a 'Volume' and format it for a number of different filesystem types (HFS+, NTFS, etc.). The Finder can show, create, move, and delete files within a volume.

 

Getting the vocabulary right might help get other concepts right too.

 

The OS is using a file system that is an abstraction of a files system layered on top of the CD. On OS X, that filesystem is called CDDAFS. As such, OS X shows a CD to contain files, even though the CD doesn't actually contain files. When you copy them, however, they become files.

 

(A file system in little more than a catalog used as an abstraction to read and write data, ensuring that the locations of files can be recorded. Disk Utility, for example, "formats" a disk by essentially writing blank catalog information (and some other stuff that the filesystem uses to be able to perform its tasks).)

[Freann]

Nope. You are still not getting it.

What you say is true for packet data with check sum error correction. Its how a OS works.

 

None of the above applies for CDs. So you need other tricks/methods. As described in the linkes above.

[Freann]

On the subway to work. I think I have figured this out…

 

A copy operation uses checksums. A checksum compares the source and target file i two ways:

- Length (total number of bits)

- content (bit by bit)

 

From this you get one of two results: identical files or a copy failure.

 

An extraction process (ripping) checks for one thing:

- Length (total number of bits)

 

This opens up for more than two results. In the unlikely event of 100% reading errors you could get a successful copy (length), but end up with a file with zero identical bits compared to the source file.

 

 

Since the OS does not know the correct value for the source bit, it cannot detect or correct for reading errors. For this you need a specialized ripping app.