File Transfer & Defrag Integrity?

People,

[Didn't know where else to place this post...so I put it here, since it relates to my DAW (SONAR XL 2.2)]:

I am trying to balance audio file location (on the HD) as it relates to efficiency of operation, vs. the continual relocation/rewriting of those files. I understand that audio files are comprised of only numbers, but I wonder about the integrity of those numbers as they are rewritten from location to location (&...I've witnessed this topic going around before...some audiophiles say rewritten files are compromised...others say there is absolutely no change, whatsoever.)

So here are my questions (& these are basically OS questions, as it relates to the DAW...I am running XP):

First, a simple hierarchy type question: I have SONAR configured to place audio files specific to a project's folder. Sometimes it becomes necessary to move audio files/clips between projects.

So...is it correct to assume that...if I select & copy a file from one folder (in Windows Explorer); & paste it into another folder...the data is re-written? (so that there are then two complete files in two different locations?) Is it also correct to assume that...if I select & cut a file from one folder; & paste it into another folder...the location of that cut file does not change (on the HD), but only the path to that file changes? (& I know SONAR can also do this; & provide the option to move or refferrence from present location...but, for this question, I'm talking about transferring files manually with Windows Explorer.)

Second: In defragmentation, I understand that files are relocated on a contiguous framework, but what is the nature of the continuity (again, as it relates to the DAW)? Is it correct to assume that they are relocated with efficiency of operation (seeking, caching & playback in the app) as the consideration?

And...how does that all work (considering that...when we record, digital audio is recorded onto the HD in a continuous stream. Then, we clip & comp & slide, etc., etc...& SONAR then has to pointer the rearranged audio work back to the original raw streamed file.) So now, when defrag takes place...which framework is considered in this "contiguous" order: the original audio file, or the location of the various rearranged clips in the project?

Thanks,

mark4man

What actually happens on the physical drive surface is subject to many,many variables: file system type, drive space available, current level of fragmentation, bad drive blocks, cluster size, etc.

The notion that copying or moving a file compromises the data in it can quickly be tested:

1. Record some audio data in Sonar

2. Copy the file to another location.

3. Move the new file as many times as you like

4. Enter a command window and run the utility fc.exe with the switch /? to display the help for this command. It will enable you to run a full binary comparison of the two files.

The OS file system has some built in mechanisms to control and eliminate data errors. As SteveD points out, it's all just ones and zeroes to the PC (and the OS). There is no difference between your audio and say, a MS Word document in the sense of raw storage. The fact that the PC knows what to do with a particular file is because of higher levels of the OS. Associations, as they are called are not fundamental to writing data on a disk. They simply tell the os what to do with a particular file based on file names. The file system relies on a database(or set of databases) that contain "pointers" which refer the OS to the location of data based upon file name, folder name, etc.

An application program can manage this data in a couple of ways: 1. Use the standard API to interact with the file system and allow it to handle the manipulation of the bits on the disk(ususally, the most reliable method). or 2. Use built-in code to order a direct write of data on the disk using the absolute sector value to access the hardware. The absolute sector method was frequently used back in the 16-bit days as a sort of shortcut for placing application specific binary files on disks. The application code then could order a read of sector XXX rather than asking the OS for the data. There is a speed advantage to this, but the advent of the Hardware Abstraction Layer in Windows NT(and NT descendants, 2000 and XP) makes direct interaction with hardware substantially more difficult. Also, the Windows APIs for FAT32 and NTFS are easily available to developers, so there is no need to "reinvent the wheel".

All of this is to say that you are using best practices when you :

1. Partition your drive appropriate to its use.

2. Perform regular housekeeping and defragmentation

3. Don't try to "micro-manage" the data. There's not a lot that you can do that offers specific and direct impact at the drive surface.

DawPro & Jimtoonz,

Thanks much (think I'll be digesting & researching that info for awhile.)

Thanks again,

mark4man