[Randy Yates]

(Don Pearce) writes:

On Thu, 29 Nov 2007 11:50:28 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 11:42:21 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 13:09:22 +0000, Eeyore
wrote:



Randy Yates wrote:

Eeyore writes:
[...]
ALL audio compression schemes rely on 'throwing away' information to get the
desired result.

I suppose you meant to say "ALL lossy audio compression schemes ...".

Fair enough.

How much data compression can the non-lossy ones deliver ? I've never investigated. I imagine
it can't be that much.

Graham

I don't think the non-lossy ones are strictly codecs - just data
compression and restoration systems.

Lossless data compression is formally a type of "source coding," so
codec (meaning "coder/decoder") is a perfectly accurate term for the
process.

A/D conversion is a type of quantization, which also falls under the
classification of source coding, so the application of codec is accurate
in this sense as well.

Sure, I know all that; but that is kind of against the spirit of the
word.

How so?

Because, as Graham has pointed out, under that terminology a Zip file
would be a codec, and that isn't really what codecs are all about.

A zip file is a file. It isn't a codec any more than an mp3 file is a
codec.

However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.
--
% Randy Yates % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC % and kiss her interface,
%%% 919-577-9882 % til then, I'll leave her alone."
%%%% % 'Yours Truly, 2095', *Time*, ELO
http://www.digitalsignallabs.com

[Don Pearce]

On Thu, 29 Nov 2007 12:37:31 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 11:50:28 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 11:42:21 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 13:09:22 +0000, Eeyore
wrote:



Randy Yates wrote:

Eeyore writes:
[...]
ALL audio compression schemes rely on 'throwing away' information to get the
desired result.

I suppose you meant to say "ALL lossy audio compression schemes ...".

Fair enough.

How much data compression can the non-lossy ones deliver ? I've never investigated. I imagine
it can't be that much.

Graham

I don't think the non-lossy ones are strictly codecs - just data
compression and restoration systems.

Lossless data compression is formally a type of "source coding," so
codec (meaning "coder/decoder") is a perfectly accurate term for the
process.

A/D conversion is a type of quantization, which also falls under the
classification of source coding, so the application of codec is accurate
in this sense as well.

Sure, I know all that; but that is kind of against the spirit of the
word.

How so?

Because, as Graham has pointed out, under that terminology a Zip file
would be a codec, and that isn't really what codecs are all about.

A zip file is a file. It isn't a codec any more than an mp3 file is a
codec.

Don't split hairs - you know what I mean.

However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.

And there, in a nutshell, is the problem with the definition. An audio
codec is something that does stuff with - specifically - audio. It
makes use of the qualities and features of audio to enable compression
that would not be valid for - eg - pictures or documents.

d




--
Pearce Consulting
http://www.pearce.uk.com

[Randy Yates]

(Don Pearce) writes:

On Thu, 29 Nov 2007 12:37:31 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 11:50:28 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 11:42:21 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 13:09:22 +0000, Eeyore
wrote:



Randy Yates wrote:

Eeyore writes:
[...]
ALL audio compression schemes rely on 'throwing away' information to get the
desired result.

I suppose you meant to say "ALL lossy audio compression schemes ...".

Fair enough.

How much data compression can the non-lossy ones deliver ? I've never investigated. I imagine
it can't be that much.

Graham

I don't think the non-lossy ones are strictly codecs - just data
compression and restoration systems.

Lossless data compression is formally a type of "source coding," so
codec (meaning "coder/decoder") is a perfectly accurate term for the
process.

A/D conversion is a type of quantization, which also falls under the
classification of source coding, so the application of codec is accurate
in this sense as well.

Sure, I know all that; but that is kind of against the spirit of the
word.

How so?

Because, as Graham has pointed out, under that terminology a Zip file
would be a codec, and that isn't really what codecs are all about.

A zip file is a file. It isn't a codec any more than an mp3 file is a
codec.

Don't split hairs - you know what I mean.

That wasn't my intention, and I do not know what you mean. That is why
I am engaging in this conversation. To speak of files obfuscates the
matter, in my opinion, and I was attempting to make things clearer.

However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.

And there, in a nutshell, is the problem with the definition. An audio
codec is something that does stuff with - specifically - audio. It
makes use of the qualities and features of audio to enable compression
that would not be valid for - eg - pictures or documents.

But you didn't say "the Lempel-Ziv algorithm is not a type of audio
codec." If you had, I might be more inclined to agree with you, but I
still might not completely agree. Since it operates on any type of
data, it could be used for audio as well. Its performance would be
bad, but the issue is one of qualifying rather than quantifying.

To return to the original point, I assert that ANY source
coding/decoding algorithm can be legitimately called a codec.
--
% Randy Yates % "And all that I can do
%% Fuquay-Varina, NC % is say I'm sorry,
%%% 919-577-9882 % that's the way it goes..."
%%%% % Getting To The Point', *Balance of Power*, ELO
http://www.digitalsignallabs.com

[Don Pearce]

On Thu, 29 Nov 2007 12:55:42 -0500, Randy Yates
wrote:

A zip file is a file. It isn't a codec any more than an mp3 file is a
codec.

Don't split hairs - you know what I mean.

That wasn't my intention, and I do not know what you mean. That is why
I am engaging in this conversation. To speak of files obfuscates the
matter, in my opinion, and I was attempting to make things clearer.


No, you really weren't. You were just point-scoring.

However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.

And there, in a nutshell, is the problem with the definition. An audio
codec is something that does stuff with - specifically - audio. It
makes use of the qualities and features of audio to enable compression
that would not be valid for - eg - pictures or documents.

But you didn't say "the Lempel-Ziv algorithm is not a type of audio
codec." If you had, I might be more inclined to agree with you, but I
still might not completely agree. Since it operates on any type of
data, it could be used for audio as well. Its performance would be
bad, but the issue is one of qualifying rather than quantifying.

To return to the original point, I assert that ANY source
coding/decoding algorithm can be legitimately called a codec.

This is an audio group. When we talk about codecs on a group like this
we are talking about audio codecs. If we were simply talking about
file compression we wouldn't use terms like codec.

d

--
Pearce Consulting
http://www.pearce.uk.com

[Eeyore]

Doug McDonald wrote:

Eeyore wrote:
Doug McDonald wrote:
Eeyore wrote:

ALL audio compression schemes rely on 'throwing away' information to get the
desired result. Advances in 'technology' will not ever affect that fundamental
principle.
While that is true, there is a big caveat.

That is that above a certain bitrate, the "error" that remains can sound
just like ordinary noise. If say 128 kbps actually results in an
error signal that sounds allows you to tell what the piece is, 160 kbps
might sound like 1/3 octave noise generators that are tuned with the
frequencies in the piece. 192 could very well sound like pink noise.
I'm not implying that those numbers are meaningful in an absolute sense ...
it could be 128 - 256 - 320.
Once you get to that point the effect of throwing away info is the same
as just adding ordinary noise. People, most people, didn't scream
and shout about added noise from tape or LPs. And they didn't talk about
"losing information" even though that indeed was what was happening.

Added noise can be relatively inoccuous.

The same doesn't apply to lost information. Your comparison isn't valid.

What I said IS true: if the lost information sounds like (and is)
white (or pink) noise, it is exactly the same as adding
white (or pink) noise. Really. At some bitrate the error
in MP3 approaches white (or pink) noise.

Not what I've experienced with some of the ones I've listened to.

Graham

[Randy Yates]

(Don Pearce) writes:

On Thu, 29 Nov 2007 12:55:42 -0500, Randy Yates
wrote:

A zip file is a file. It isn't a codec any more than an mp3 file is a
codec.

Don't split hairs - you know what I mean.

That wasn't my intention, and I do not know what you mean. That is why
I am engaging in this conversation. To speak of files obfuscates the
matter, in my opinion, and I was attempting to make things clearer.


No, you really weren't. You were just point-scoring.

So you're either calling me a liar or one who doesn't know his own
intentions?

I think this, ummm, "conversation" is done. The fact that you have
resorted to ad-hoc insults is evidence that you have no legitimate basis
for your argument.
--
% Randy Yates % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC % and kiss her interface,
%%% 919-577-9882 % til then, I'll leave her alone."
%%%% % 'Yours Truly, 2095', *Time*, ELO
http://www.digitalsignallabs.com

[Don Pearce]

On Thu, 29 Nov 2007 13:12:06 -0500, Randy Yates
wrote:

(Don Pearce) writes:

On Thu, 29 Nov 2007 12:55:42 -0500, Randy Yates
wrote:

A zip file is a file. It isn't a codec any more than an mp3 file is a
codec.

Don't split hairs - you know what I mean.

That wasn't my intention, and I do not know what you mean. That is why
I am engaging in this conversation. To speak of files obfuscates the
matter, in my opinion, and I was attempting to make things clearer.


No, you really weren't. You were just point-scoring.

So you're either calling me a liar or one who doesn't know his own
intentions?

I think this, ummm, "conversation" is done. The fact that you have
resorted to ad-hoc insults is evidence that you have no legitimate basis
for your argument.

Nice bit of backing-out. Respect!

d

--
Pearce Consulting
http://www.pearce.uk.com

[Richard Crowley]

"Doug McDonald" wrote...
Richard Crowley wrote:

Anyone who has cleaned a black-vinyl LP, or used
Cedar (etc.) to extract a conversation out of the noise
would agree.

Cleaning an LP is not for removal of white noise ...
it's very very far from that.

I didn't say that cleaning an LP removed white noise.
I was observing that *masking* the signal is very
different than *irrevocably discarding* it. The first is
reversable while the second is not.

[Richard Crowley]

"Don Pearce" wrote ...
Randy Yates wrote:
However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.

And there, in a nutshell, is the problem with the definition. An audio
codec is something that does stuff with - specifically - audio. It
makes use of the qualities and features of audio to enable compression
that would not be valid for - eg - pictures or documents.

I don't see the problem. We all regularly refer to an "MP3 file" or a
"ZIP file". And it is understood by everyone that decoding an MP3
file requires a MP3 codec, just as decoding a ZIP file requires a
ZIP codec.

A standalone application of an MP3 codec is called an "MP3
Player" just as a standalone application of a ZIP codec is
called "WinZip" (etc.). But note that there are also versions of
both MP3 and ZIP codecs (and most others) that are just DLL
files and usable internally by other applications.

[Don Pearce]

On Thu, 29 Nov 2007 10:51:39 -0800, "Richard Crowley"
wrote:

"Don Pearce" wrote ...
Randy Yates wrote:
However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.

And there, in a nutshell, is the problem with the definition. An audio
codec is something that does stuff with - specifically - audio. It
makes use of the qualities and features of audio to enable compression
that would not be valid for - eg - pictures or documents.

I don't see the problem. We all regularly refer to an "MP3 file" or a
"ZIP file". And it is understood by everyone that decoding an MP3
file requires a MP3 codec, just as decoding a ZIP file requires a
ZIP codec.

A standalone application of an MP3 codec is called an "MP3
Player" just as a standalone application of a ZIP codec is
called "WinZip" (etc.). But note that there are also versions of
both MP3 and ZIP codecs (and most others) that are just DLL
files and usable internally by other applications.


I consulted the experts. In other words I went to the PKZIP web site.
I did a site-wide search for the word CODEC. Guess how many hits I
got. Guess again - lower. Go on, and again - a bit lower still. There
yet?

d

--
Pearce Consulting
http://www.pearce.uk.com

[Richard Crowley]

"Don Pearce" wrote ...
This is an audio group. When we talk about codecs on a group like this
we are talking about audio codecs. If we were simply talking about
file compression we wouldn't use terms like codec.

The term "codec" is defined as....
"a device or program capable of performing transformations
on a data stream or signal"

Note that the effect is not limited to audio (or even media) data.
Note further that it equally applies to ADC and DAC hardware.

If you wish to make such a narrow (and artificial) distinction
about what constitutes a "codec", then you will have problems
trying to categorize things like FLAC, etc. Is it a media codec,
or is it a file compression algorithm?

Floor wax or dessert topping? ["Shimmer"]
http://snltranscripts.jt.org/75/75ishimmer.phtml

[Don Pearce]

On Thu, 29 Nov 2007 10:58:53 -0800, "Richard Crowley"
wrote:

"Don Pearce" wrote ...
This is an audio group. When we talk about codecs on a group like this
we are talking about audio codecs. If we were simply talking about
file compression we wouldn't use terms like codec.

The term "codec" is defined as....
"a device or program capable of performing transformations
on a data stream or signal"

Note that the effect is not limited to audio (or even media) data.
Note further that it equally applies to ADC and DAC hardware.

If you wish to make such a narrow (and artificial) distinction
about what constitutes a "codec", then you will have problems
trying to categorize things like FLAC, etc. Is it a media codec,
or is it a file compression algorithm?


Difficulty of categorizing items close to boundaries is no reason to
conclude that the categories don't exist.

A man has three hairs on his chin; is he bearded or not?

d

--
Pearce Consulting
http://www.pearce.uk.com

[Richard Crowley]

"Don Pearce" wrote ...
I consulted the experts. In other words I went to the PKZIP web site.
I did a site-wide search for the word CODEC. Guess how many hits I
got. Guess again - lower. Go on, and again - a bit lower still. There
yet?

Your choice of "experts" is debatable.
Google returned 752,000 hits for: zip codec
including...

"codec
"(3) (COmpressor-DECompressor) A general data compression
algorithm; for example, a "Zip codec." The term may also be
applied to the built-in algorithms used to create and render
images such as GIFs and JPEGs. See data compression."
http://www.answers.com/topic/codec?cat=technology

There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.

[Eeyore]

Richard Crowley wrote:

"Don Pearce" wrote ...
Randy Yates wrote:
However, the Lempel-Ziv algorithm is indeed a source coding algorithm
and in that sense can be called a codec.

And there, in a nutshell, is the problem with the definition. An audio
codec is something that does stuff with - specifically - audio. It
makes use of the qualities and features of audio to enable compression
that would not be valid for - eg - pictures or documents.

I don't see the problem. We all regularly refer to an "MP3 file" or a
"ZIP file". And it is understood by everyone that decoding an MP3
file requires a MP3 codec, just as decoding a ZIP file requires a
ZIP codec.

A standalone application of an MP3 codec is called an "MP3
Player" just as a standalone application of a ZIP codec is
called "WinZip" (etc.). But note that there are also versions of
both MP3 and ZIP codecs (and most others) that are just DLL
files and usable internally by other applications.

There is a BIG difference however. A true CODEC operates in real time. Zipping
and unzipping files is however not a real time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding and decoding on a
digital data stream or signal. "

Note 'data stream' or 'signal'. NOT file.

Graham

[Eeyore]

Don Pearce wrote:

On Thu, 29 Nov 2007 10:58:53 -0800, "Richard Crowley"
wrote:

"Don Pearce" wrote ...
This is an audio group. When we talk about codecs on a group like this
we are talking about audio codecs. If we were simply talking about
file compression we wouldn't use terms like codec.

The term "codec" is defined as....
"a device or program capable of performing transformations
on a data stream or signal"

Note that the effect is not limited to audio (or even media) data.
Note further that it equally applies to ADC and DAC hardware.

If you wish to make such a narrow (and artificial) distinction
about what constitutes a "codec", then you will have problems
trying to categorize things like FLAC, etc. Is it a media codec,
or is it a file compression algorithm?


Difficulty of categorizing items close to boundaries is no reason to
conclude that the categories don't exist.

A man has three hairs on his chin; is he bearded or not?

d

A woman has three hairs on her chin; is she bearded or not?

I think this has to be one of those 'looks like a duck, quacks like duck' etc
scenarios.

Graham

[Doug McDonald]

Richard Crowley wrote:
"Doug McDonald" wrote...
Richard Crowley wrote:

Anyone who has cleaned a black-vinyl LP, or used
Cedar (etc.) to extract a conversation out of the noise
would agree.
Cleaning an LP is not for removal of white noise ...
it's very very far from that.

I didn't say that cleaning an LP removed white noise.
I was observing that *masking* the signal is very
different than *irrevocably discarding* it. The first is
reversable while the second is not.



What I am saying is that a properly
working lossy compression system, such as MP3, given enough bits,
is equivalent to adding white (or pink) noise. If one
can be "undone" (which it can't ) so can the other. If
one can't, neither can the other.

Some people have difficulty understand this.

Cleaning an LP is not for removal of white noise, it
removes clicks and pops. These can, to some extent,
be removed ex post facto in software. Added white noise
can't be, at least not without removing actual information
buried in it.

Doug McDonald

[Richard Crowley]

"Eeyore" wrote ...
There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find them?

Furthermore, it can be BOTH. You can take WAV files and
encode them into FLAC (as a batch process, likely very-much
faster than "real-time"), and then take the FLAC file and decode
them *in real-time* when you want to listen to them.

Note 'data stream' or 'signal'. NOT file.

Nothing operates on "files" as such. Anything you do with
a file turns it into a "data stream" from the CPU's POV.
You cannot read a "file" without turning it into a datastream
nor can you write a "file" without it exsiting as a datastream
on the way from the HD controller to the drive. (And indeed,
as the HD head reads or writes the "file".)

Furthermore, we have a problem with defining "real time".
When we talk on a cellphone, we are (mostly) unconsious
of the fact that it isn't really "real-time" due to the nature of
the time-domain sharing of the cellsite with hundreds of
phones. It is very fast, but not technically "real-time" in the
strictest sense. You can demonstrate the effect by calling
someone standing next to you and noting the difference
between through-the-air real-time vs. the encoding, trans-
mission, and decoding through the cell phones.

[Eeyore]

Richard Crowley wrote:

"Eeyore" wrote ...
There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much NOT real-time.

Graham

[Jack]

Eeyore wrote in
:



Jack wrote:

Kevin McMurtrie wrote

Audio compression will stay around for some uses. CPUs and algorithms
will always be much cheaper than long distance bandwidth and wireless
bandwidth. Regardless of how fast the internet gets, 10x compression
still means 10x customer capacity. 10x compression on your mobile
player means 10x the room for music.

Also, there are now warnings of Internet bottlenecks by 2010 due to
multimedia content and increased population/usership.

The usual scaremongering. Journalists are clueless about technology.

The pipes will simply get bigger to take the load.

Like oil will keep flowing no matter what? They are warning that billion$
must be spent now to make sure it doesn't happen. The Net was not
originally conceived for this much audio and video transfer.

Jack

[Jack]

"Arny Krueger" wrote in
:

Where are the results of your DBTs?

Anybody can write poetry. Real men can hear differences in blind
tests, or admit they can't.

Real men? If you listen to the WMA file you'll hear that no blind tests are
needed in this case. I already described in detail what the artifacts are.

Jack

[Richard Crowley]

"Eeyore" wrote ...
Richard Crowley wrote:

"Eeyore" wrote ...
There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much NOT real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

[Kevin McMurtrie]

In article ,
Eeyore wrote:

Jack wrote:

Kevin McMurtrie wrote

Audio compression will stay around for some uses. CPUs and algorithms
will always be much cheaper than long distance bandwidth and wireless
bandwidth. Regardless of how fast the internet gets, 10x compression
still means 10x customer capacity. 10x compression on your mobile
player means 10x the room for music.

Also, there are now warnings of Internet bottlenecks by 2010 due to
multimedia content and increased population/usership.

The usual scaremongering. Journalists are clueless about technology.

The pipes will simply get bigger to take the load.

Graham

The problem is in the last few miles. Most US homes are still at the
same DSL, dialup, or cable service levels they had a decade ago. Only
DSL and dialup have unlimited bandwidth plans. Cable and the
ever-elusive new fiber optic services have oppressive usage limits that
can make them less appealing than DSL.

[Don Pearce]

On Thu, 29 Nov 2007 23:11:02 -0800, "Richard Crowley"
wrote:

"Eeyore" wrote ...
Richard Crowley wrote:

"Eeyore" wrote ...
There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much NOT real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

But it does, otherwise it would simply be data. The word stream
implies that the data is moving past you, and you must deal with it on
the fly.

d

--
Pearce Consulting
http://www.pearce.uk.com

[Richard Crowley]

"Don Pearce" wrote in message
...
On Thu, 29 Nov 2007 23:11:02 -0800, "Richard Crowley"
wrote:

"Eeyore" wrote ...
Richard Crowley wrote:

"Eeyore" wrote ...
There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find
them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much NOT
real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

But it does, otherwise it would simply be data. The word stream
implies that the data is moving past you, and you must deal with it on
the fly.

I take it that you aren't a programmer, either.

[Don Pearce]

On Fri, 30 Nov 2007 01:48:31 -0800, "Richard Crowley"
wrote:


"Don Pearce" wrote in message
...
On Thu, 29 Nov 2007 23:11:02 -0800, "Richard Crowley"
wrote:

"Eeyore" wrote ...
Richard Crowley wrote:

"Eeyore" wrote ...
There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find
them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much NOT
real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

But it does, otherwise it would simply be data. The word stream
implies that the data is moving past you, and you must deal with it on
the fly.

I take it that you aren't a programmer, either.

I have been. So tell me, what do you think is the difference between
data and data stream? In other words, what does the word stream mean
in this context?

d

--
Pearce Consulting
http://www.pearce.uk.com

[Eeyore]

Richard Crowley wrote:

"Eeyore" wrote ...
Richard Crowley wrote:
"Eeyore" wrote ...

There is a BIG difference however. A true CODEC operates
in real time. Zipping and unzipping files is however not a real
time process.

Wikipedia also takes the view that codecs must be real time.
http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing encoding
and decoding on a digital data stream or signal. "

Sorry, I can't see the words "real time" anywhere in your quote
(or on the whole page, for that matter). Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much NOT real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

Maybe the streams and rivers in your world run on a stop-start basis too ?

Graham

[Don Pearce]

On Thu, 29 Nov 2007 12:08:07 -0800, "Richard Crowley"
wrote:

"Don Pearce" wrote ...
I consulted the experts. In other words I went to the PKZIP web site.
I did a site-wide search for the word CODEC. Guess how many hits I
got. Guess again - lower. Go on, and again - a bit lower still. There
yet?

Your choice of "experts" is debatable.
Google returned 752,000 hits for: zip codec
including...

"codec
"(3) (COmpressor-DECompressor) A general data compression
algorithm; for example, a "Zip codec." The term may also be
applied to the built-in algorithms used to create and render
images such as GIFs and JPEGs. See data compression."
http://www.answers.com/topic/codec?cat=technology

There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.


Just the one? And from such a reputable source (tee hee!). I did the
google thing myself, and 99% of what I found was codec packs that
could be downloaded as a zip file. Funny that they should not say that
their codecs had been compressed by a further codec, isn't it? The
thing about counting the number of hits is that you have to actually
understand what it is you are hitting. Please just drop this
silliness.

d

--
Pearce Consulting
http://www.pearce.uk.com

[Arny Krueger]

"Jack" wrote in message

"Arny Krueger" wrote in
:

Where are the results of your DBTs?

Anybody can write poetry. Real men can hear differences
in blind tests, or admit they can't.

Real men? If you listen to the WMA file you'll hear that
no blind tests are needed in this case.

Jack, real men can read and obviously you can't. I posted the results of my
blind tests with Steven's files on 11/28. That was two days ago. Where are
yours?

All I did is transform Stephen's coded files back into .wav files with
standard software and compare those .wav files adn the original .wav file
with some well-known free software that is pointed to by links at
www.pcabx.com .

BTW, blind tests comparing .wav files to coded files are slam-dunk easy.
Please see www.pcabx.com and the Hydrogen Audio forums for more
information.

I already described in detail what the artifacts are.

No Jack, you just posted some poetry.

But of course Jack you're always right and people like Steven and I are
always wrong, and the fact that all of this technology was developed with
blind tests means nothing to you...

Sigh! :-(

[Arny Krueger]

"Jack" wrote in message

Eeyore wrote in
:



Jack wrote:

Kevin McMurtrie wrote

Audio compression will stay around for some uses.
CPUs and algorithms will always be much cheaper than
long distance bandwidth and wireless bandwidth.
Regardless of how fast the internet gets, 10x
compression still means 10x customer capacity. 10x
compression on your mobile player means 10x the room
for music.

Also, there are now warnings of Internet bottlenecks by
2010 due to multimedia content and increased
population/usership.

The usual scaremongering. Journalists are clueless about
technology.

The pipes will simply get bigger to take the load.

Like oil will keep flowing no matter what? They are
warning that billion$ must be spent now to make sure it
doesn't happen. The Net was not originally conceived for
this much audio and video transfer.

Things change. Arpanet was not designed to support the world wide web. It
could barely do light email.

[Arny Krueger]

"Eeyore" wrote in
message
Richard Crowley wrote:

"Eeyore" wrote ...
Richard Crowley wrote:
"Eeyore" wrote ...

There is a BIG difference however. A true CODEC
operates
in real time. Zipping and unzipping files is however
not a real time process.

Wikipedia also takes the view that codecs must be
real time. http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing
encoding and decoding on a digital data stream or
signal. "

Sorry, I can't see the words "real time" anywhere in
your quote (or on the whole page, for that matter).
Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much
NOT real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

Maybe the streams and rivers in your world run on a
stop-start basis too ?

Actually, that's the formal definition between a river and a creek. ;-)

Creeks run start-stop, and rivers flow continuously.

[Steven Sullivan]

In rec.audio.tech Jack wrote:
Steven Sullivan wrote in
:

I was too lazy to upload anything but you got me started now.

wma Blaze 128 CBR
http://www.badongo.com/file/5333875

Oddly, that WMA file is actually 192 kbps per Winamp and Windows file
properties.

mp3 LAME 192 VBR
http://www.badongo.com/file/5333913

That MP3 shows as 131 kbps (VBR) per EncSpot Pro (analyzes MP3 headers).
EncSpot also shows the encoder as FhG, not LAME. Were those typos?

Definitely not in the case of the MP3. That was made by me using LAME, via
foobar2000. I don't even have FhG on any of my computers.

I don't recall the Blaze file being 192, either--bitrate is selectable from
a menu and I thought I selected 128 CBR. But I'd have to double check.
I don't have the mp3s handy on this computer, and the badongo downloads have
expired.

Also, is that a remastered version of the song? Those "slushy" highs sound
a lot crisper than on my original CD. I have Reprise Records Catalog #
2257-2.

There is no remastered version of Decade.


Your recording sounds noticeably cleaner, but of course that's moot to the
WMA/MP3 comparison. The part WMA really mangles (on my CD version) is
between 3:30 and 4:00, plus similar sections. The very dullness of the
recording confuses it, IMO.

Since you gave such an easy site to work with, here are my samples. Notice
the muffled "breathing" effect in the WMA file. Very unusual in my
experience with WMA. I used GoldWave 5.22 to encode these.

http://www.badongo.com/file/5340634 (WAV 3:30 to 3:40)
http://www.badongo.com/file/5340662 (WMA 9.2 128 kbps 3:30 to 3:40)
http://www.badongo.com/file/5340669 (MP3 FhG 128 kbps 3:30 to 3:40)

Don't get the impression that I'm picking on WMA. The artifacts are truly
puzzling. On many other tracks WMA sounds crisper to me than the MP3
counterpart. For example, LAME 3.97 128 kbps adds notable distortion to the
background strings on The Eagles "Take It To The Limit" (encoded using
EAC). WMA 128 kbps seems to shine on that track.

My working theory is that each encoder uses different tricks that get
tripped up by unique harmonics.


Jack

--

___
-S
"As human beings, we understand the world through simile, analogy,
metaphor, narrative and, sometimes, claymation." - B. Mason

[Randy Yates]

"Arny Krueger" writes:

"Eeyore" wrote in
message
Richard Crowley wrote:

"Eeyore" wrote ...
Richard Crowley wrote:
"Eeyore" wrote ...

There is a BIG difference however. A true CODEC
operates
in real time. Zipping and unzipping files is however
not a real time process.

Wikipedia also takes the view that codecs must be
real time. http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing
encoding and decoding on a digital data stream or
signal. "

Sorry, I can't see the words "real time" anywhere in
your quote (or on the whole page, for that matter).
Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much
NOT real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

Maybe the streams and rivers in your world run on a
stop-start basis too ?

Actually, that's the formal definition between a river and a creek. ;-)

Creeks run start-stop, and rivers flow continuously.

So some signals are data creeks?
--
% Randy Yates % "She has an IQ of 1001, she has a jumpsuit
%% Fuquay-Varina, NC % on, and she's also a telephone."
%%% 919-577-9882 %
%%%% % 'Yours Truly, 2095', *Time*, ELO
http://www.digitalsignallabs.com

[Richard Crowley]

"Don Pearce" wrote ...
"Richard Crowley" wrote:
I take it that you aren't a programmer, either.

I have been. So tell me, what do you think is the difference
between data and data stream? In other words, what does
the word stream mean in this context?

A data stream is information that is linked together and
must be taken in sequence to be understood. (vs. random-
access data).

Take a book for example. The *story* is a data-stream
because it must be taken in sequence. But the words
and paragraphs and chapters can be taken as random-
access blocks of data, but if you take it that way you
lose the sense of the story / data-stream. Novels are
generally treated as a data-stream. OTOH dictionaries
are generally treated as random-access data.

In the context of the function of a codec, the sense is
the same. No codec (MP3 or ZIP, etc.) can properly
decode the data unles it is taken in sequence (i.e. a
"data stream"). But there is no implication of WHEN
this must happen. It doesn't matter whether you
decode MP3 in real-time (as you listen) or whether
you batch decode it to a PCM sequence and them
just feed those bytes into an ADC after the fact.

[Richard Crowley]

"Eeyore" wrote ...
Richard Crowley wrote:
Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

Maybe the streams and rivers in your world run on a stop-start basis
too ?

As a matter of fact, I live very close to the largest river draining
into the Pacific Ocean. It has 14 dams and is also the largest
hydroelectric power producing river in North America. Are you
going to say that it isn't a river anymore because the flow can
be controlled (or even stopped)?

On a smaller scale, most smaller streams around here are in
constant threat of beavers building dams and blocking the
flow. This presents a problem in urban and suburban areas
because it causes local flooding. AFAIK, none of the streams
have been renamed just because beavers blocked the flow.

[Richard Crowley]

"Don Pearce" wrote...
"Richard Crowley" wrote:
I take it that you aren't a programmer, either.

I have been. So tell me, what do you think is the difference
between data and data stream? In other words, what does
the word stream mean in this context?

A data stream is information that is linked together and
must be taken in sequence to be understood. (vs. random-
access data).

Take a book for example. The *story* is a data-stream
because it must be taken in sequence. But the words
and paragraphs and chapters can be taken as random-
access blocks of data, but if you take it that way you
lose the sense of the story / data-stream. Novels are
generally treated as a data-stream. OTOH dictionaries
are generally treated as random-access data.

In the context of the function of a codec, the sense is
the same. No codec (MP3 or ZIP, etc.) can properly
decode the data unles it is taken in sequence (i.e. a
"data stream"). But there is no implication of WHEN
this must happen. It doesn't matter whether you
decode MP3 in real-time (as you listen) or whether
you batch decode it to a PCM sequence and them
just feed those bytes into an ADC after the fact.

[Steven Sullivan]

In rec.audio.tech Jack wrote:
Jack wrote in
:

http://www.badongo.com/file/5340634 (WAV 3:30 to 3:40)
http://www.badongo.com/file/5340662 (WMA 9.2 128 kbps 3:30 to 3:40)
http://www.badongo.com/file/5340669 (MP3 FhG 128 kbps 3:30 to 3:40)

CORRECTION: those are actually segments from 3:30 to 4:00 (30 secs. each).
Purists should rename the downloaded files.

Funny thing about badongo; there are no controls on who can download what.
You can grab random stuff by changing the link suffix. Nobody ought to put
personal stuff there.

Jack


here's the same segment, done by me. I verified the codecs and bitrates this time


FLAC via foobar2k
http://www.badongo.com/file/5364152

128WMA CBR via FairStars Audio Converter (shows as 129 kbps)
http://www.badongo.com/file/5364159

190MP3 VBR via LAME 3.97 (shows as 183-219 kbps)
http://www.badongo.com/file/5364184


___
-S
"As human beings, we understand the world through simile, analogy,
metaphor, narrative and, sometimes, claymation." - B. Mason

[Eeyore]

Richard Crowley wrote:

"Eeyore" wrote ...
Richard Crowley wrote:
Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

Maybe the streams and rivers in your world run on a stop-start basis
too ?

As a matter of fact, I live very close to the largest river draining
into the Pacific Ocean. It has 14 dams and is also the largest
hydroelectric power producing river in North America. Are you
going to say that it isn't a river anymore because the flow can
be controlled (or even stopped)?

On a smaller scale, most smaller streams around here are in
constant threat of beavers building dams and blocking the
flow. This presents a problem in urban and suburban areas
because it causes local flooding. AFAIK, none of the streams
have been renamed just because beavers blocked the flow.

We don't have this problem in the UK.

No beavers you see.

Graham

[Don Pearce]

On Fri, 30 Nov 2007 08:37:56 -0800, "Richard Crowley"
wrote:

"Don Pearce" wrote...
"Richard Crowley" wrote:
I take it that you aren't a programmer, either.

I have been. So tell me, what do you think is the difference
between data and data stream? In other words, what does
the word stream mean in this context?

A data stream is information that is linked together and
must be taken in sequence to be understood. (vs. random-
access data).

Take a book for example. The *story* is a data-stream
because it must be taken in sequence. But the words
and paragraphs and chapters can be taken as random-
access blocks of data, but if you take it that way you
lose the sense of the story / data-stream. Novels are
generally treated as a data-stream. OTOH dictionaries
are generally treated as random-access data.

In the context of the function of a codec, the sense is
the same. No codec (MP3 or ZIP, etc.) can properly
decode the data unles it is taken in sequence (i.e. a
"data stream"). But there is no implication of WHEN
this must happen. It doesn't matter whether you
decode MP3 in real-time (as you listen) or whether
you batch decode it to a PCM sequence and them
just feed those bytes into an ADC after the fact.

No it isn't. A file on a disc could be described as imfor,ation that
must be taken in sequence, but it is still a file. A data stream is an
inexorable flow of data which must be dealt with as it comes.

d

--
Pearce Consulting
http://www.pearce.uk.com

[Don Pearce]

On Fri, 30 Nov 2007 08:09:48 -0500, "Arny Krueger"
wrote:

"Eeyore" wrote in
message
Richard Crowley wrote:

"Eeyore" wrote ...
Richard Crowley wrote:
"Eeyore" wrote ...

There is a BIG difference however. A true CODEC
operates
in real time. Zipping and unzipping files is however
not a real time process.

Wikipedia also takes the view that codecs must be
real time. http://en.wikipedia.org/wiki/Codec
"A codec is a device or program capable of performing
encoding and decoding on a digital data stream or
signal. "

Sorry, I can't see the words "real time" anywhere in
your quote (or on the whole page, for that matter).
Can you help us find them?

A *signal* or *data stream* are real-time concepts.

In comparison zipping and unzipping files is very much
NOT real-time.

Then we must agree to disagree. I take it you are not
a comptuer programmer? I've never before heard the
notion that a "data stream" had any temporal implication.

Maybe the streams and rivers in your world run on a
stop-start basis too ?

Actually, that's the formal definition between a river and a creek. ;-)

Creeks run start-stop, and rivers flow continuously.


In England we have many places called Winterbourne. These are places
with seasonal water flows.

d

--
Pearce Consulting
http://www.pearce.uk.com

[Jack]

"Arny Krueger" wrote in
:

"Jack" wrote in message

Eeyore wrote in
:



Jack wrote:

Kevin McMurtrie wrote

Audio compression will stay around for some uses.
CPUs and algorithms will always be much cheaper than
long distance bandwidth and wireless bandwidth.
Regardless of how fast the internet gets, 10x
compression still means 10x customer capacity. 10x
compression on your mobile player means 10x the room
for music.

Also, there are now warnings of Internet bottlenecks by
2010 due to multimedia content and increased
population/usership.

The usual scaremongering. Journalists are clueless about
technology.

The pipes will simply get bigger to take the load.

Like oil will keep flowing no matter what? They are
warning that billion$ must be spent now to make sure it
doesn't happen. The Net was not originally conceived for
this much audio and video transfer.

Things change. Arpanet was not designed to support the world wide
web. It could barely do light email.

My comment was also about people's perception that growth (of any kind) can
go on without limits in a finite world. It's a mass-delusion of modern life
in the oil age. At some point Internet capacity will peak, just like the
ability to supply electricity to power it all. Computers/servers have
become a major energy hog.

Jack