12 replies to this topic

[AlChe]

Can any one please explain why this happens:

After I burn an Audio CD in Toast Pro 11.0.6 and then compare aiff file sizes on my burnt disc to the sizes of the aiff source files located in the iTunes directory, I find that the original files are always slightly larger than the burnt output files.

Here are some specific numbers from the last disc I burnt:

Track 1
original size: 13,960,324 bytes
burnt file size: 13,952,064
which is 8260 bytes smaller

Here's another thing that I noticed about this last CD that I burnt:
It was a sequential compilation of tracks from a 3-disc album, and the file size difference between all burnt and original tracks from disc 1 was a consistent number of 8260 bytes, while the tracks from the disc two yielded a constant size difference of 8268 bytes; the burnt files originating from the third disc were all 8266 bytes smaller than their source files.

There are no file size discrepancies when Toast burns data discs. Burnt and original files are byte-by-byte copies of each other.

It seems to me that Toast either strips away a small portion of data originally contained in the source files or compresses the files a little while burning audio cds.

Can anyone provide an exhaustive explanation of what happens to aiff file data during burning in Toast?

Thank you.

[theoldarchiver]

The sound is not stored as files on an Audio CD (but as streams). Therefore it lacks the file “header” that an AIFF file would have. The header would likely be mostly meta-data (information about the file itself). It is not important that this information is lost, as the audio format on Audio CDs is standardized, and thus known without in-file reference. The audio-data part of the AIFF file should be 100% on the CD, although things like byte-order might make it hard to compare 1-on-1 on a low level.
Small differences in file-length (as seen in your various tracks) might be attributed to sector sizes, where each track on an audio CD must fill a certain number of full sectors, where each sector can hold 2352 bytes.

[AlChe]

Thank you very much for your explanation, Digital Master. Although I do not quite understand what meant by "the sound is not stored as files on an Audio CD (but as streams)... it lacks the file 'header' that an AIFF file would have," since the files on a burnt cd have an aiff extension. Is there some sort of "white paper" that you know of that is available on this process anywhere on the net that? Wouldn't the CD sector size nuance similarly affect any other type of file when burnt to a disc? Thank you again for your help.

[tsantee]

AlChe, on 28 July 2012 - 12:15 PM, said:

Thank you very much for your explanation, Digital Master. Although I do not quite understand what meant by "the sound is not stored as files on an Audio CD (but as streams)... it lacks the file 'header' that an AIFF file would have," since the files on a burnt cd have an aiff extension. Is there some sort of "white paper" that you know of that is available on this process anywhere on the net that? Wouldn't the CD sector size nuance similarly affect any other type of file when burnt to a disc? Thank you again for your help.

While I hope theoldarchiver also responds to your questions, it is important to know that an audio CD is not written in a computer storage format (such as HFS or ISO 9660). The audio CD spec was created long before there were audio CD players (much less CD recorders) on computers. The OS requires special programming to be able to read an audio CD since it is not a standard computer format. That programming creates what you see in the Finder so that it looks very similar to other mounted discs and even gives the .aiff name to the tracks. But that's not how those tracks are written. It is just how they are being described. I wouldn't go so far as to say you are comparing apples and oranges because in the Finder they look much the same. But you are comparing different kinds of apples or different kinds of oranges. What matters is the tracks are 16-bit, 2-channel, 44.1 kHz digital audio. That makes them identical to the .aiff files on your computer's hard drive.

Edited by tsantee, 28 July 2012 - 02:48 PM.

[AlChe]

Thanks again, Digital Master. It's beginning to become clearer to me.
Any chance you can save me one last bit of trouble and tell me something else? I've temporarily run out of blank cds and cannot right now test and see if an Audio CD Copying process (vs. ripping and then burning) produces an actual byte-by-byte clone of an original cd, which, if the terminology is not loose, it should do. Shall the Original and Copy checksums match in that case? Or should I rather expect the checksum of the Copy version of the disc to be identical to that of it's Rip-n-Burn version? Or is it going to be another different number this time as well?
Thank you again for your time.

[AlChe]

Forgot to mention: when I burnt that 3-disc compilation I mentioned in my first post, I also saved it as a Toast image file (.Sd2f). Finder shows it's size as 798,543,151 bytes. I then created a Sd2f image of the burnt cd and it's size measured as 798,538,973. Which is 4178 bytes smaller than the Toast original.   Given this tendency, each consecutive duplication of an aiff file has to decrease the file's size.     I'm scratching my head here.

[theoldarchiver]

AlChe, on 28 July 2012 - 12:15 PM, said:

Although I do not quite understand what meant by "the sound is not stored as files on an Audio CD (but as streams)... it lacks the file 'header' that an AIFF file would have," since the files on a burnt cd have an aiff extension.

As tsantee kindly explained, that is just a trick/presentation form of the Finder. There aren't really AIFF files on an audio CD. But what is on there is VERY similar. Similar enough to pull off this trick.

AlChe said:

Is there some sort of "white paper" that you know of that is available on this process anywhere on the net that?

An official license of the specification for Audio CDs (document IEC 60908) has come down in price from $5000 to $260. But you wouldn't need that, unless you plan on manufacturing a CD player.
There are some good webpages on the Red Book standard (e.g. Wikipedia), that link to more information if needed.

AlChe said:

Wouldn't the CD sector size nuance similarly affect any other type of file when burnt to a disc?

Yes it would, but only as far as total capacity is concerned. The file system on the disc keeps track of the true file size, so the end user wouldn't even notice. (By the way, a similar thing happens on hard disks, where files are written in ‘blocks’ of several kilobytes, so that there is a small discrepancy between file size and space used on the disk.)

AlChe, on 28 July 2012 - 03:27 PM, said:

I've temporarily run out of blank cds and cannot right now test and see if an Audio CD Copying process (vs. ripping and then burning) produces an actual byte-by-byte clone of an original cd, which, if the terminology is not loose, it should do. Shall the Original and Copy checksums match in that case? Or should I rather expect the checksum of the Copy version of the disc to be identical to that of it's Rip-n-Burn version? Or is it going to be another different number this time as well?

I've never tested that, but the audio data should be a byte for byte duplicate, with a good burner/reader and quality discs. It depends a bit on how accurate Toast is in copying, which I can't determine. (There is a reason why a Windows program called Exact Audio Copy became popular in some circles: it did/does digital extraction better, more securely, than some similar apps, by expecting errors that it needs to handle the most accurate way it can.)

AlChe, on 28 July 2012 - 11:11 PM, said:

When I burnt that 3-disc compilation I mentioned in my first post, I also saved it as a Toast image file (.Sd2f). Finder shows it's size as 798,543,151 bytes. I then created a Sd2f image of the burnt cd and it's size measured as 798,538,973. Which is 4178 bytes smaller than the Toast original.   Given this tendency, each consecutive duplication of an aiff file has to decrease the file's size.

I don't know about this one, but one thing that comes to mind is that perhaps you burned a disc with CD-Text activated, but the reading back from the disc didn't include this. This a limitation of the combination of software and hardware. Some software can write it, but not read it back. Many optical drives do not pass this information to host computers when reading, even if the software is capable.

[hermie54]

Some circles on Mac use XLD for ripping Audio CDs, to be found through MacUpdate or directly here: http://tmkk.pv.land....ld/index_e.html

A guide on how to set it up and use it can be found here: http://www.digitalve...ic=26740&oo=312

[AlChe]

Thank you, guys.

Unfortunately, i'm not sure if the cd text option was on when i burnt the disc in question. I'm certain that i messed with that option after i made the disc 'cause it is "on" now and i haven't burnt any more cds since. i'd like to eliminate the cd-text variable from my experiment (i intend to do a couple more generational burns of the same cd) but i'm not sure how to look for the cd text correctly using any of the mac-supported apps listed in the wikipedia article on cd text or if my optical drives can read it. I have a Matshita dvd r uj 85j in my iMac and an external Nec dvd rw nd-3550a. Any pointers there, anyone? (Push comes to shove, I'll just do another test with CD text switched off.

Thank you, Apprentice, for your input. XLD is, actually, my program of choice for ripping cds. I just did a quick toast rip for this test. Although I did use the program to do all my ripping in past.

My original question arose when i decided to give re-writable cds a try the other day (never had used them before) and checked the original and output data info when I noticed the numerical mismatch. i then did a similar burn on a regular cd and ended up with the same numbers as with the re-writeable disc. And that was what really got me worried 'cause, as I've already mentioned, i'd been using Toast forever and exclusively both for ripping and burning my music but I never checked my numbers/checksums before.

[tsantee]

AlChe, on 29 July 2012 - 12:49 PM, said:

Thank you, guys.

Unfortunately, i'm not sure if the cd text option was on when i burnt the disc in question. I'm certain that i messed with that option after i made the disc 'cause it is "on" now and i haven't burnt any more cds since. i'd like to eliminate the cd-text variable from my experiment (i intend to do a couple more generational burns of the same cd) but i'm not sure how to look for the cd text correctly using any of the mac-supported apps listed in the wikipedia article on cd text or if my optical drives can read it. I have a Matshita dvd r uj 85j in my iMac and an external Nec dvd rw nd-3550a. Any pointers there, anyone? (Push comes to shove, I'll just do another test with CD text switched off.

Insert the burned audio CD and choose Disc Info from Toast's Recorder menu. The window that appears will display any CD text info burned to the disc.

[AlChe]

Thanks!
Here's what I got:


Medium Type: CD
Space Available: You cannot write to this disc.
Space Used: 663.1 MB
Content
Title: Audio CD
Content Type: Audio
Tracks: 57
Sessions: 1
Details                   Start         Size
Session 1 TAO      0               761.5 MB
Track 1                  0               13.3 MB
etc.

And that's it. If I understand correctly, none of this qualifies as cd text. Am I right? Could it be that neither of my drives reads back cd-text data?

Looks like the surest way for me to shed more light on this dilemma is going to be doing several generational Copy burns and Rip-n-burn dupes in Toast and analyzing the results... Unless somebody else comes with a definitive explanation of their own or does a similar test before me. But I'm most positive it must have already been done by many true audiophiles out there. I wish I could find their reports online. Anyways, I'm going to keep looking.

Digital Guru, thank you once again for trying to help crack this one for me.

[tsantee]

AlChe, on 29 July 2012 - 04:00 PM, said:

Thanks!
Here's what I got:


Medium Type: CD
Space Available: You cannot write to this disc.
Space Used: 663.1 MB
Content
Title: Audio CD
Content Type: Audio
Tracks: 57
Sessions: 1
Details    Start Size
Session 1 TAO   0    761.5 MB
Track 1   0    13.3 MB
etc.

And that's it. If I understand correctly, none of this qualifies as cd text. Am I right? Could it be that neither of my drives reads back cd-text data?

Looks like the surest way for me to shed more light on this dilemma is going to be doing several generational Copy burns and Rip-n-burn dupes in Toast and analyzing the results... Unless somebody else comes with a definitive explanation of their own or does a similar test before me. But I'm most positive it must have already been done by many true audiophiles out there. I wish I could find their reports online. Anyways, I'm going to keep looking.

Digital Guru, thank you once again for trying to help crack this one for me.

The CD Text would have appeared if it was present on the disc. I notice you burned the disc Track-at-Once (TAO) rather than Disc-at-Once (DAO). I think it has to be burned DAO for the CD Text to be written. CD Text is pretty useless as there are few CD players that display the info. There are some other limitations to TAO such as there can't be zero-second pauses or crossfades without an audible silence between the tracks. It's been a long time since I thought about TAO so my recollection is rather fuzzy.

Edited by tsantee, 29 July 2012 - 09:50 PM.

[AlChe]

Got it. Then, I guess, we can safely discount the CD text variable in our trying to figure out if each consecutive duplication of an aiff file has to decrease the file's size, as my experiment made me suspect.