naturerecordists
[Top] [All Lists]

Re: back up on audio CDR (warning: long) (was: beginners question)

Subject: Re: back up on audio CDR (warning: long) (was: beginners question)
From: Walter Knapp <>
Date: Fri, 30 Aug 2002 20:46:59 -0400
evertveldhuis wrote:
>
> > Since CD audio is the same uncompressed audio, why do you not
> consider
> > it backup? It can be pulled back into the computer with no loss.
> >
>
> Walt,
>
> On some other forum or website (don't remember which one) I found out
> that although the actual sounds are not altered (compressed) there is
> one serious 'problem': the computer stores the wav file, and any
> other file for that matter, in a certain amounts of blocks.
> Typically these blocks are 4 kB (I am telling this out of my poor
> memory so the figure 4 might be wrong.)

Allocation blocksize varies considerably from hard disk to hard disk.
It's chosen when the disk is formatted to make sure the disk directory
won't run out of space. And is dependent on the capacity of the disk.

What matters is that the basic size is bytes. Two bytes to each 16bit
sample. The bytes generally don't get broken up. But your entire file
can be scattered in different random blocks all over the disk. The
beauty of computers is that they have no trouble organizing all of this.
And it's still two bytes of 16bits in audio CD.

> When the wav file is burned to an audio CD format the blocks files
> get another standard size, and that is why it is to my strict
> standard no longer a back-up since the original form of the data (in
> this case the blockfile size) has been changed.
> There could be mistakes which are unaudible, but after resizing
> againg from CD audio to WAV there is HUGE potential for loss of
> information.

The problem is that .wav is a windows format and uses little endian
coding. Everything else, mac aiff, audio CD and so on uses big endian.
That means the .wav format stores the bits in reverse order from
everybody else. So, the bit order must be reversed. With properly
written software this is no problem. And note in going to .wav from
minidisc you have already changed this once.

On top of that a audio CD is not written the same way at all, does not
use allocation blocks. It much more closely resembles a LP disk written
by a laser. In other words that file that was all fragmented on your HD
is one continuous audio data recording. With a TOC like the Minidisc
uses to tell where each track begins and ends.

> If you ever tried to rip audio CD's with progrock - where there are
> no pauses between tracks, but the music just keeps on going, just
> like a live recording - you will often get problems at the beginning
> of each track.

Note I use mac and it's virtually copying, track by track as aiff is the
same big endian format as the audio CD. It does not copy the intertrack
gap that was mastered into the CD, this contains no audio. It also does
not do it one long track. I'm not sure I could even force it to do so as
it presents the material to be copied as a list of tracks. I have a
bunch of programs capable of copying audio CD to aiff and they all work
like this.

Note also, the audio CD encoding standard was used as the template when
the MiniDisc standard was developed. While the MiniDisc standard has
some tricks not thought of for audio CD, it's fundamentally the same basis.

Since audio CD as played includes a step to deal with any missing bits,
playing is not a perfect reproduction. But when copied back by a
computer it is, assuming you have cared for the disks, if you have not
the computer will tell you about the errors. The error rate there will
be the same in either audio CD or burning ISO 9660 disks containing .wav
or .aif files.

> I fully realise that this is a problem that only occurs under certain
> circumstances that do not occur often. But still, there is an audible
> difference, so for me it is not a back up, it has become a dead-end
> user product.

The circumstances are pretty much unique to windows and don't have
anything to do with the quality of the audio stored on a audio CD. They
have a lot more to do with the old fashioned way a X86 processor works.
And careful choice of software will take care of it in Windows too. You
can put a 44k 16bit soundfile into audio CD and get it back unchanged.

> A bit off topic now:
> It is the same reason why bands do not - just copy that consumser CD
> 1000 times - but use the master tape (or master optical disc).

A lot of habits die hard. But there are many reasons for going back to
the original unprocessed sound. Music consumer CD's are heavily
processed sound, not original sound.

In the case of going back to the master, they are usually going back to
the analog, or to a higher digital sampling rate. Some loss occurred
when it was sampled 44.1k 16bit. And that sample depended on the
particular A/D used at the time, there have been improvements in those
too. In addition over time the desired sound changes, in particular
modern recording is compressing the dynamic range closer and closer to
the loud end. So old mixes won't sound "right" and must be remixed just
to fix this. You have to go back to the masters to change this sort of
stuff. All that has little to do with nature recording, I don't think
I've run across any commercially produced nature recordings that
compressed the dynamic range or any of the other music changes. The
audio CD's I store for backup are of the raw, unprocessed audio as it
came into the computer, a separate channel deals with any CD's I might
produce through processing. I do not consider those as archives. Any
more than I would copying back to minidisc.

Note in modern practice, a master CD is often used to produce all other cop=
ies.

Walt



________________________________________________________________________
________________________________________________________________________

<Prev in Thread] Current Thread [Next in Thread>
Admin

The University of NSW School of Computer and Engineering takes no responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the naturerecordists mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU