[bct] Re: Fw: Recording in digital.

  • From: "Graham Lewis" <Graham.Lewis@xxxxxxxxxxxxx>
  • To: <blindcooltech@xxxxxxxxxxxxx>
  • Date: Tue, 01 Nov 2005 09:29:36 +0000

Combined with the podcast that Rob and Larry did and the other feedback on this 
list, Jeff Armstrong gave an excellent explanation and I think I finally grasp 
this!  Many thanks everybody!


Graham Lewis
Centre for Academic Practice
University of Warwick
University House
Kirby Corner Road
Coventry CV4 8UW
Tel.: (+44) (0) 24 765 72737
Mobile: 07733450022
Fax.: (+44) (0) 24 765 727326


>>> j1armstrong@xxxxxxxxxxxxxx 10/31/05 08:37pm >>>

----- Original Message ----- 
From: "jeff" <j1armstrong@xxxxxxxxxxxxxx>
To: "Larry Skutchan" <blindcooltech@xxxxxxxxx>
Sent: Sunday, October 30, 2005 5:10 PM
Subject: Recording in digital.

> Larry,
>    I'll take a crack at putting the terms for digital recording into their 
> proper place.
> Sample rate:
> How many times (per second) an audio stream is sampled.
> Bit Rate:
> The size of each sample expressed as bits per sample.
> When we combine the two above terms we end up creating a stream of samples 
> of a certain size and the number of samples times the size of the samples 
> is the size of the streaming audio data which is expressed in kilobits , 
> (1000 bits)per second and
> The easiest way I can link these all together is like this:
> Sample Rate multiplied by Sample size = kilobits per second of streaming 
> audio data, and therefore storage space required to store one second of 
> that data.
> Let me give an example using CD audio.
> Our sample rate is 44100 samples per second, our bit rate is 16 bits per 
> sample and when you multiply these two numbers you get  705,600 bits per 
> second of storage space needed to store one stream of audio information, 
> double this because it takes two channels or streams of data to produce 
> stereo playback and you get 1,411,200 bits per second needed to store the 
> stereo image you are recording.  We refer to this number as about 1411 
> KBPS. The sample rate and bit rate used in this example are the industry 
> standard for normal CD audio.
>    Now, if we apply some compression, which we do with a "CODEC", 
> (coder/decoder), which is an algorithm or program, if you will, which has 
> been designed to throw out some bits which are not necessary to the 
> audible image, we end up with a compressed audio file.  In one case we 
> have what is called lossless compression.  The image or audio file still 
> sounds like the original and no data that is required to recreate the 
> original stream is missing.  If we want a smaller file, we can either 
> reduce the number of samples we take every second, reduce the size of our 
> samples, or both. Whenever we do one of these things, we are losing some 
> of the original data from the stream.  This is referred to as "lossy" 
> compression.
> when information that was present in the original cannot actually be heard 
> by the listener, or at least might be overshadowed by another sound that 
> is occurring at the same time.  The compression algorithm can remove those 
> bits and still maintain high quality sound, but after a while, the more 
> bits one removes from the original, the more one intrudes into the audible 
> image produced by the compressed stream or file.
>    Obviously, the more compression which is applied the smaller the output 
> file will be.  When you multiply the bits per sample by the number of 
> samples per second, you will always get the KBPS, again, the stream size 
> and storage requirement, for one second of the  compressed audio.
>    I like to copy my CDs onto my hard drive, I use very little compression 
> on the stream coming off the CD.  My files are therefore bigger and use 
> more storage, but there is less chance of damaging the quality of the 
> audio in the file.  Since I use very little compression, the computer does 
> not have to work very hard to compress my output file and the process goes 
> very fast.
>    If I wanted to really compress my files so that I could fit more of 
> them onto a  portable device, I would choose a compression algorithm or 
> set my copying program's compression settings to make a smaller file but 
> the likely result would be a lower quality sounding output file.  In other 
> words, a low bit rate and a low sample rate multiply to cause a smaller 
> file with a smaller KBPS like 32KBPS or 64KBPS.  The computer has to work 
> harder to do all the arithmetic it takes to produce the compressed file 
> and therefore takes a long time to create a more compressed file.
>    Other examples I can think of.  I bought a bunch of old time radio 
> shows which had been copied onto CD-ROM disk.  The old shows were of low 
> quality because somebody recorded them from a radio using a cassette 
> recorder with it's microphone held near the radio's speaker.  So the files 
> which contain the shows are compressed down to 32KBPS size because that is 
> all that is required to  produce voice recordings of this quality and the 
> program, while in poor quality, was never about the audio quality anyway, 
> it was about the words on the recording.  Now, on the other hand, XM 
> satellite, uses a 128KBPS stereo recording compression to balance nice 
> quality sound with efficient use of the amount of bandwidth they have to 
> broadcast on.  If they tried to get closer to the original in sound 
> quality, they would have to reduce the number of channels they offer to 
> their customers.
>    The Iriver IFP 899 uses a compression program to compress the recorded 
> audio before it is stored on the flash memory of the recorder.  This is 
> why it tops out at 96KBPS even though the sampling rate is 44100 and the 
> bitrate is 16 bits per sample.  I'm sure the extra work it takes the 
> device to compress the audio "on the fly", eats up battery life, though I 
> can't prove that.  With this device, you have no choice to have your data 
> stored uncompressed as a ".wav" file..
>    For a reference visual, think of samples as dipping a Dixie cup into a 
> stream that is flowing by you.  The more often you dip the cup into the 
> water the higher your sample rate.  The bit rate is how much water you get 
> each time you dip, half a cup versus a full cup.  The total of the number 
> of dips with the cup or samples multiplied by the size of samples or 
> amount in each dip of the cup equals the total volume of water you will 
> have need to store.  That total volume of water storage needed would be 
> your KBPS and the longer you kept sampling the water, the larger the 
> storage needed, this is the length of recording multiplied by the KBPS to 
> get total bits needed for storage.
> You can always divide your total kbps by 8 because 8 bits fit into one 
> byte of storage and then you will know how many bytes of disk space you 
> will need for any of your planned recordings.  Our 1411KBPS above for CD 
> audio would require about  176,000 bytes per second to record or 176 
> kilobytes per second.  You can use the windows calculator to test out 
> these ideas, just enter your sampling rate and multiply it by your bits 
> per second to get KBPS, divide that answer by 8 to get kilobytes per 
> second of disk needed for a recording at that setting.
>    If anyone has any questions, let me know, if I can't answer them, I can 
> look them up.
> Only read this section if you totally understood what I was saying in the 
> first part of this letter.
> The bitrate used for CD audio is 16 bits per sample.  and the compression 
> I spoke of earlier was the same for each sample of data.  What if someone 
> varied the amount of bits depending on factors in the audio stream.  Like 
> a D.J. introducing a song wouldn't require as much bitrate as the actual 
> song, and we could get the file just a bit smaller if we let our bitrate 
> dip down during the intro.  If there was a point, somewhere during the 
> song, where there was a silence or only one instrument playing, we could 
> probably dip down our sampling size there too.  The overall filesize would 
> be reduced and that is called variable bitrate or "VBR".  The method used 
> in our first few examples was constant and we just call that constant 
> bitrate or "cbr".  You will see settings for these factors in many cd 
> ripping programs and not all playback devices can handle variable rate 
> data streams and so it is not always a good idea to use this option.  I 
> use it on my hard drive's library of copied CDs because I know Winamp can 
> playback these recordings.
> Well, thanks Larry for letting me throw my 2 cents in there and try to 
> make it understandable.  .
> Jeff Armstrong 

Other related posts: