"RIP" not as in 'rest in peace'!!

G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

While I wasn't looking, someone slipped a new term into the hifi lingo
- "rip" as in copying something from some source media.

Exactly what does it mean, what media is referenced and what is its
history?

Thanx,

ESTG/
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Rip: Copy from a CD, typically in digital form, and typically at
faster-than-realtime speeds.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

<erigby@batelnet.bs> wrote in message
news:1123508364.005684.201950@g43g2000cwa.googlegroups.com
> While I wasn't looking, someone slipped a new term into
> the hifi lingo - "rip" as in copying something from some
> source media.
>
> Exactly what does it mean, what media is referenced and
> what is its history?

ripping is the process extracting bit-perfect digital audio
data directly from audio CDs.

The term was *old* when I first learned of it, which was in
the mid-late '90s.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

It is my understanding that Redbook Audio is a digital audio data storage
system that does not have the likes of a file system, like you would find on
a data CD. It is more like the grooves on an old LP. The original idea of a
CD audio player was a digital extension of the idea of the LP. It spins.
It's round. It has a hole in the middle. The tracks on a disk need to be
accessible while the disk is spinning and in any rotation so you can cue a
track from somewhere near the beginning, not necessarily the exact same
sample every time; much like dropping the needle in the darker grooves on an
LP. Because there is no file system, it takes some special care to extract
the audio as a pure digital stream.

~James. :eek:)


<erigby@batelnet.bs> wrote in message
news:1123508364.005684.201950@g43g2000cwa.googlegroups.com...
> While I wasn't looking, someone slipped a new term into the hifi lingo
> - "rip" as in copying something from some source media.
>
> Exactly what does it mean, what media is referenced and what is its
> history?
>
> Thanx,
>
> ESTG/
>
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

On Mon, 8 Aug 2005 10:35:01 -0400, "Arny Krueger" <arnyk@hotpop.com>
wrote:

><erigby@batelnet.bs> wrote in message
>news:1123508364.005684.201950@g43g2000cwa.googlegroups.com
>> While I wasn't looking, someone slipped a new term into
>> the hifi lingo - "rip" as in copying something from some
>> source media.
>>
>> Exactly what does it mean, what media is referenced and
>> what is its history?
>
>ripping is the process extracting bit-perfect digital audio
>data directly from audio CDs.

I've also heard it used for digitizing/digitally recording LP's
into a computer, though that may be a more recent and less "correct"
usage. OTOH, usage is what defines a word as much as anything.

>The term was *old* when I first learned of it, which was in
>the mid-late '90s.

So what's the origin? I can easily think up a folk-etymology origin
(thus it's very likely to be wrong) that "ripping" a CD means doing
copyright infringement, from "ripping off" the rights owners of their
earnings. But I have no evidence from that.

-----
http://www.mindspring.com/~benbradley
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

"Ben Bradley" wrote ...
> I've also heard it used for digitizing/digitally recording LP's
> into a computer, though that may be a more recent and less
> "correct" usage. OTOH, usage is what defines a word as
> much as anything.

To me, at least, "ripping" refers specifically to recovering the
stream of digital data from a RedBook audio CD and storing
it into a proper computer file (wav, etc.)

Capturing/recording/transcribing from other sources (such as
LPs or tape, etc.) is NOT "ripping" as the original was not a
digital source.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

On Mon, 8 Aug 2005 14:51:21 -0400, "James Lehman"
<james[remove]@akrobiz.com> wrote:

>It is my understanding that Redbook Audio is a digital audio data storage
>system that does not have the likes of a file system, like you would find on
>a data CD. It is more like the grooves on an old LP. The original idea of a
>CD audio player was a digital extension of the idea of the LP. It spins.
>It's round. It has a hole in the middle. The tracks on a disk need to be
>accessible while the disk is spinning and in any rotation so you can cue a
>track from somewhere near the beginning, not necessarily the exact same
>sample every time; much like dropping the needle in the darker grooves on an
>LP. Because there is no file system, it takes some special care to extract
>the audio as a pure digital stream.

So you maintain ripping a CD is just a synonym for playing it?

I don't see any particular problem in reading data from any chosen
point in any file on any non-linear medium - CD, floppy or hard drive.
There can be a rather looser attitude to error-tolerance. on an audio
CD, I suppose. Does this have relevance to it's unique data
structure?

I first heard the term "Rip" meaning extracting the music from
computer games, when it was integral to a data file, not stored
separately and accessibly. Now I see it used in reference to getting
audio and/or video data off media in a way other than that intended by
the maker.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Laurence Payne wrote:
> So you maintain ripping a CD is just a synonym for playing it?

"Any sufficiently precise playback is indistinguishable from copying."
Which is precisely why better media are viewed as a mixed blessing by
the publishing industry.

> There can be a rather looser attitude to error-tolerance. on an audio
> CD, I suppose.

Audio CD playback corrects errors by interpolation, which is fast,
usually good enough for human consumption, and in fact is *more* robust
on seriously damaged disks. Data CDs use error correcting codes, because
they need to return exactly the right bits... but that means that when
the damage is worse than the ECC can deal with, they basically give up.

(Note that if you're archiving audio, there's a good argument for
pulling two copies, one in each representation, since age and abuse
affect them differently.)
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

"Laurence Payne" wrote ...
> So you maintain ripping a CD is just a synonym for playing it?

No, "ripping" implies an element of COPYING, not just playback.

> I don't see any particular problem in reading data from any chosen
> point in any file on any non-linear medium - CD, floppy or hard drive.
> There can be a rather looser attitude to error-tolerance. on an audio
> CD, I suppose. Does this have relevance to it's unique data
> structure?

It is that conversion from a RedBook digital "stream" (or the
extraction of audio from a game, etc.) into a "proper computer
file" that is the essence of "ripping" to me.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Bingo!

"Richard Crowley" <richard.7.crowley@intel.com> wrote in message
news:dd8qcn$t94$1@news01.intel.com...
> "Laurence Payne" wrote ...
> > So you maintain ripping a CD is just a synonym for playing it?
>
> No, "ripping" implies an element of COPYING, not just playback.
>
> > I don't see any particular problem in reading data from any chosen
> > point in any file on any non-linear medium - CD, floppy or hard drive.
> > There can be a rather looser attitude to error-tolerance. on an audio
> > CD, I suppose. Does this have relevance to it's unique data
> > structure?
>
> It is that conversion from a RedBook digital "stream" (or the
> extraction of audio from a game, etc.) into a "proper computer
> file" that is the essence of "ripping" to me.
>
>
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Laurence Payne wrote:
> On Mon, 8 Aug 2005 16:33:49 -0700, "Richard Crowley"
> <richard.7.crowley@intel.com> wrote:
> >Capturing/recording/transcribing from other sources (such as
> >LPs or tape, etc.) is NOT "ripping" as the original was not a
> >digital source.
>
> But there are digital sources other than RedBook CD?

DAT, MO, ...
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

dpierce wrote ...
> Laurence Payne wrote:
>> On Mon, 8 Aug 2005 16:33:49 -0700, "Richard Crowley"
>> <richard.7.crowley@intel.com> wrote:
>> >Capturing/recording/transcribing from other sources (such as
>> >LPs or tape, etc.) is NOT "ripping" as the original was not a
>> >digital source.
>>
>> But there are digital sources other than RedBook CD?
>
> DAT, MO, ...

To my way of thinking DAT and MO were formats/media
were *designed* to be recovered digitally whereas audio
CD (as contrasted with CD-ROM) was never designed to
be used to reproduce the exact digital sample stream. The
minimalist error detection/recovery methodology used in
the RedBook format would appear to support this theory.

But, really, this discussion of the etymology of "rip" has
exceeded its useful span.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Joe Kesselman wrote:
> Laurence Payne wrote:
> > So you maintain ripping a CD is just a synonym for playing it?
>
> "Any sufficiently precise playback is indistinguishable from copying."
> Which is precisely why better media are viewed as a mixed blessing by
> the publishing industry.
>
> > There can be a rather looser attitude to error-tolerance. on an audio
> > CD, I suppose.
>
> Audio CD playback corrects errors by interpolation, which is fast,
> usually good enough for human consumption, and in fact is *more* robust
> on seriously damaged disks. Data CDs use error correcting codes, because
> they need to return exactly the right bits... but that means that when
> the damage is worse than the ECC can deal with, they basically give up.

Sorry, this is simply not correct. CD's use interpolation only if
the already built-in error correcting codes fail. Red book CD's
already use a couple of layers of error correction, including
CIRC. The actual unrecovered data error rate on even moderately
maintained disks is still on the order of 1 bit in 10^12 or better.

Now CD-ROM adds another layer or two of error correction on top of
that. But to state that CD's ONLY use interpolation for error
recovery is simply false.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Richard Crowley wrote:
> dpierce wrote ...
> > Laurence Payne wrote:
> >> On Mon, 8 Aug 2005 16:33:49 -0700, "Richard Crowley"
> >> <richard.7.crowley@intel.com> wrote:
> >> >Capturing/recording/transcribing from other sources (such as
> >> >LPs or tape, etc.) is NOT "ripping" as the original was not a
> >> >digital source.
> >>
> >> But there are digital sources other than RedBook CD?
> >
> > DAT, MO, ...
>
> To my way of thinking DAT and MO were formats/media
> were *designed* to be recovered digitally whereas audio
> CD (as contrasted with CD-ROM) was never designed to
> be used to reproduce the exact digital sample stream. The
> minimalist error detection/recovery methodology used in
> the RedBook format would appear to support this theory.

Which "minimalist error detection/recovery methodology" would
that be. Red bnook audio CD's use several rather sophisticated
error encoding/detection and recovery algorithms, including EFM
encoding, CIRC (Cross-Interleaved Reed-SOlomon Coding), etc..

Typically, the raw bit error rate on a CD is on the order of 1
bit in 10^5 or 10^6, but after CIRC error correction, this is
reduced to 1 bit in 10^11 or less. I have routinely seen discs
play the entire way through without a single uncorrected error.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

dpierce wrote ...
> Richard Crowley wrote:
>> To my way of thinking DAT and MO were formats/media
>> were *designed* to be recovered digitally whereas audio
>> CD (as contrasted with CD-ROM) was never designed to
>> be used to reproduce the exact digital sample stream. The
>> minimalist error detection/recovery methodology used in
>> the RedBook format would appear to support this theory.
>
> Which "minimalist error detection/recovery methodology" would
> that be. Red bnook audio CD's use several rather sophisticated
> error encoding/detection and recovery algorithms, including EFM
> encoding, CIRC (Cross-Interleaved Reed-SOlomon Coding), etc..
>
> Typically, the raw bit error rate on a CD is on the order of 1
> bit in 10^5 or 10^6, but after CIRC error correction, this is
> reduced to 1 bit in 10^11 or less. I have routinely seen discs
> play the entire way through without a single uncorrected error.

I meant relative to data-grade error detection/recovery schemes.

If it is that common to be able to read RedBook data stream
without errors, why do people have so much trouble ripping
them? Even pristine discs right out of the shrink-wrap.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

James Lehman wrote:
> It is my understanding that Redbook Audio is a digital audio data storage
> system that does not have the likes of a file system, like you would find on
> a data CD. It is more like the grooves on an old LP. The original idea of a
> CD audio player was a digital extension of the idea of the LP. It spins.
> It's round. It has a hole in the middle. The tracks on a disk need to be
> accessible while the disk is spinning and in any rotation so you can cue a
> track from somewhere near the beginning, not necessarily the exact same
> sample every time; much like dropping the needle in the darker grooves on an
> LP. Because there is no file system, it takes some special care to extract
> the audio as a pure digital stream.

That's not correct.

CD audio data is collected into well-defined units that comprise
a hiearchy which certainly qualifies as a random-access, indexable,
seekable (with 100% repeatability) hierarchy.

The smallest addressable unit in a CD is a subcode block, which has
its own sync work, instructions, data, commands and error correction
information. Such a block can define the beginning of a track or index,
which is uniquely and repeatably accessible, just as would the sector
on a harddrive.

The lead-in tracks contain track and index tables that can be read in,
as the vast majority of CD players do. That's why when you put in a CD,
the player will often display immediately how many tracks it finds. It
does not have to read the entire disk to gather this information: it's
all in the index track. Another word for "index track" would
appropriately be "directory." This area includes not only track
subcode block index information, but includes track and index timing
as well.

Once any one entry is known, the drive can be commanded to seek to
the exact location on the disk and start playing (reading) immediately.
It will do so from the same sample every time you command it to do
so. There is no inaccuracy in that respect. You're limited to starting
reading from the beginning of a sub code block, and not anywhere in
the middle, simply because the error correction requires an entire
block to perform its operations.

In all respects, a CD is far more different from an LP than it is
similar, and for more like a hard drive than it is different.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Richard Crowley wrote:
> dpierce wrote ...
> > Richard Crowley wrote:
> >> To my way of thinking DAT and MO were formats/media
> >> were *designed* to be recovered digitally whereas audio
> >> CD (as contrasted with CD-ROM) was never designed to
> >> be used to reproduce the exact digital sample stream. The
> >> minimalist error detection/recovery methodology used in
> >> the RedBook format would appear to support this theory.
> >
> > Which "minimalist error detection/recovery methodology" would
> > that be. Red bnook audio CD's use several rather sophisticated
> > error encoding/detection and recovery algorithms, including EFM
> > encoding, CIRC (Cross-Interleaved Reed-SOlomon Coding), etc..
> >
> > Typically, the raw bit error rate on a CD is on the order of 1
> > bit in 10^5 or 10^6, but after CIRC error correction, this is
> > reduced to 1 bit in 10^11 or less. I have routinely seen discs
> > play the entire way through without a single uncorrected error.
>
> If it is that common to be able to read RedBook data stream
> without errors, why do people have so much trouble ripping
> them?

I have never had trouble ripping disks on my system. Ever.

Maybe its because my system is reasonably well maintained, using
something other than the cheapest P.O.S. drives that have been
beaten to smithereens on OS's that are maintained and free of
extraneous tasks and all that. Maybe it's because most people's
systems are a total mess.

Yes, some peeople have a lot of trouble ripping CD's without
errors. They bring the disk to me, and I can read it with no
problems. TO me it's a miracle that there system can do anything
at all.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

James Lehman wrote:
> Oh really?

Really. Do you have a copy of IEC 60908 on hand?

> Are you a software engineer too!

Yes, I am.

> The data on a hard drive is truly random access and because of that it can
> be in any order.

"Random access" does not mean the same thing as "random order."

> That's why we have things like disk defragmenters. There is
> a file system in place that requires that the entire partition on the hard
> drive has a format regardless of the amount of data that is stored there.

Irrelevant to the fact that an audio CD is an addressable, random
access device.

> CD audio is nothing like the data structures that are stored on
> a hard drive.

Might I respectfully recommend you obtain a copy of the Redbook
CD audio specification and cite the particular section that supports
your assertion?

> The tracks are most definitely in order on the disk and they can be accessed
> simply by moving the laser read head a certain amount to catch the stream
> somewhere near the beginning of the track.

It CANNOT read arbitrarily within a CD frame, since the entire
frame is needed for CIRC decoding.

Might I respectfully recommend you obtain a copy of the Redbook
CD audio specification and cite the particular section that supports
your assertion?

> CD audio was developed WAY before
> anyone had the idea of putting a file format and computer data on a CD. Sure
> lots of enhancements to the format have come along over the years. I'm
> talking about first generation CD.

Might I respectfully recommend you obtain a copy of the Redbook
CD audio specification and cite the particular section that supports
your assertion?

And we ARE talking about "first generation," i.e., redbook
standard CD's,. i.e., IEC 60908 format audio CD's.

A reasonable summary of the principles involved can be found
in texts such as Pohlman's "Principles of Digital Audio," Ch. 9,
"The Compact Disk," and the details therein.
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

On Mon, 8 Aug 2005 16:33:49 -0700, "Richard Crowley"
<richard.7.crowley@intel.com> wrote:

>To me, at least, "ripping" refers specifically to recovering the
>stream of digital data from a RedBook audio CD and storing
>it into a proper computer file (wav, etc.)
>
>Capturing/recording/transcribing from other sources (such as
>LPs or tape, etc.) is NOT "ripping" as the original was not a
>digital source.

But there are digital sources other than RedBook CD?
 
G

Guest

Guest
Archived from groups: rec.audio.tech (More info?)

Oh really?

Are you a software engineer too!

The data on a hard drive is truly random access and because of that it can
be in any order. That's why we have things like disk defragmenters. There is
a file system in place that requires that the entire partition on the hard
drive has a format regardless of the amount of data that is stored there. CD
audio is nothing like the data structures that are stored on a hard drive.
The tracks are most definitely in order on the disk and they can be accessed
simply by moving the laser read head a certain amount to catch the stream
somewhere near the beginning of the track. CD audio was developed WAY before
anyone had the idea of putting a file format and computer data on a CD. Sure
lots of enhancements to the format have come along over the years. I'm
talking about first generation CD.

~James. :eek:)


<dpierce@cartchunk.org> wrote in message
news:1123601875.443766.88710@f14g2000cwb.googlegroups.com...
>
> James Lehman wrote:
> > It is my understanding that Redbook Audio is a digital audio data
storage
> > system that does not have the likes of a file system, like you would
find on
> > a data CD. It is more like the grooves on an old LP. The original idea
of a
> > CD audio player was a digital extension of the idea of the LP. It spins.
> > It's round. It has a hole in the middle. The tracks on a disk need to be
> > accessible while the disk is spinning and in any rotation so you can cue
a
> > track from somewhere near the beginning, not necessarily the exact same
> > sample every time; much like dropping the needle in the darker grooves
on an
> > LP. Because there is no file system, it takes some special care to
extract
> > the audio as a pure digital stream.
>
> That's not correct.
>
> CD audio data is collected into well-defined units that comprise
> a hiearchy which certainly qualifies as a random-access, indexable,
> seekable (with 100% repeatability) hierarchy.
>
> The smallest addressable unit in a CD is a subcode block, which has
> its own sync work, instructions, data, commands and error correction
> information. Such a block can define the beginning of a track or index,
> which is uniquely and repeatably accessible, just as would the sector
> on a harddrive.
>
> The lead-in tracks contain track and index tables that can be read in,
> as the vast majority of CD players do. That's why when you put in a CD,
> the player will often display immediately how many tracks it finds. It
> does not have to read the entire disk to gather this information: it's
> all in the index track. Another word for "index track" would
> appropriately be "directory." This area includes not only track
> subcode block index information, but includes track and index timing
> as well.
>
> Once any one entry is known, the drive can be commanded to seek to
> the exact location on the disk and start playing (reading) immediately.
> It will do so from the same sample every time you command it to do
> so. There is no inaccuracy in that respect. You're limited to starting
> reading from the beginning of a sub code block, and not anywhere in
> the middle, simply because the error correction requires an entire
> block to perform its operations.
>
> In all respects, a CD is far more different from an LP than it is
> similar, and for more like a hard drive than it is different.
>