> From: Anthony Lalande <[EMAIL PROTECTED]>
> > Pretty much correct. Something to note: the ATRAC specification
> has never
> > changed, but the sophistication of implementations has. The
> older versions all
> > used fixed point arithmetic, because the readily available DSPs
> were all fixed
> > point. Newer machines actually use floating point DSPs, at
> least in the home
> > decks. This will have some impact (audible? dunno) on the
> accuracy of the math
> > used to encode or decode the audio signal.
> If I understand the full ramifications of what you've just said, I think
> you've just answered my question, but because I'm curious, I'll
> ask anyway:
>
> Can the different ATRAC compression algorithms result in data loss that is
> not directly related to ATRAC? For example, is it possible to get more
> definition in a recording with a company's v1.0
> compression/encoding engine
> (algorithm) than with the same company's later (and presumably
> better) v8.0
> compression engine?
Definite Yes to the first question. The very first MD units sounded
terrible,
not because ATRAC is a bad technique, but because the implementations were
too limited in precision. For the second question, I'd guess that the newer
implementations will always be superior to the older ones. Aside from cost
and
speed issues, I can't think of any case where a competent floating point
implementation would be inferior to a fixed point version. Fixed point math
will inherently be more noisy in this application because of the continuous
rounding and truncation of intermediate results. In essence, every stage of
calculation would introduce quantization noise. Using floating point math
will
minimize or eliminate the intermediate rounding and limit quantization noise
to
just the very end of the computation (converting floating point results back
to 16 bit integer samples).
> From: Stainless Steel Rat <[EMAIL PROTECTED]>
> * Dave Kimmel <[EMAIL PROTECTED]> on Thu, 11 Jan 2001
> | ATRAC is lossy because it does NOT return the same data after
> | decompression that it was given for compression. ATRAC throws out
> | information in order to make it easier to compress the data,
> therefore the
> | compression and decompression process loses data.
>
> There are two technical errors in that statement:
>
> ATRAC uses 5:1 bitwise reduction but no additional data
> compression. MD-74
> can hold 74 minutes of music, the same as CD-DA, on a disc 1/5 the size of
> a CD because it is storing exactly 1/5 the number of bits.
>
Side note - if you have a signal with only 3 bits worth of actual
information
present, you can record it without loss. Of course, the definition of a
"3 bit signal" is tricky...
> Bitwise reduction does not make the stream more compressible.
By the way, ATRAC3 uses a Huffman squeeze on its data stream for further
reduction.
I wish I had filed a patent 15 years ago on cascaded data compression
techniques.
I was the guy who originally discovered that so-called incompressible
compressed
image files (such as GIFs and other LZW-based methods) could be further
compressed
using Huffman coding. Zip and most other methods now use this technique
after
doing their initial hash-based compression.
>
> | This is, coincidentally, why audio MD equipment would be very poor for
> | data storage. I believe this has been discussed on-list a few times.
>
> People have used inherently "lossy" analog schemes for reliable data
> storage and transmission for decades. It really depends on the modulation
> scheme used. It would not be as efficient as writing to the raw
> device but
> there is no technical reason why it could not work.
Yep. I recall about 18 years ago, a company was selling an interface for
backing up computers to VHS recorders over the video input. All you have to
do
is modulate the data with enough redundancy to get onto the tape, to
guarantee
that you can extract a meaningful result at a later date. I outlined a
possible
approach for MD on this list a couple weeks ago. The fact that you can only
write at 30KB/sec makes me think it's not worth actually pursuing the
project
any further.
> From: Anthony Lalande <[EMAIL PROTECTED]>
> Subject: MD: ATRAC & loseless compression techniques...
> > Lossless compression is what people generally call programs like WinZip.
> Right. Your analogy to WinZip gets me wonderin'...
>
> Does any loseless compression algorithm require the entire set of data for
> read access before it begins compression? If you wanted to encode
> audio with
> a loseless compression, could you do it in real-time or would you need to
> wait until the entire recording is complete, and then compress afterwards?
> Would the results be as good in real-time than as a post-process?
Most techniques would theoretically work best if the entire data set was
present
all at once, but the ancillary data storage requirements would get out of
hand.
Huffman Squeeze definitely works best if it can analyze the entire data set.
Lempel-Ziv's hash table eventually fills up, at which point it is reset. If
the
hash table were always "big enough" for the entire data set, its compression
efficiency would be maximized. Actual implementations process data in blocks
to
avoid demanding too much temporary memory, and also to allow for some level
of
streaming. Remember that most implementations arose on Unix, where piping
data
from one command to another is a standard paradigm. Pipes wouldn't be very
interesting
if your compression program read the entire input file, processed it
enmasse, and
then spit out a result in a single humongous write operation at the end.
Also, most lossless techniques available execute fine in realtime on today's
hardware. They are all based on simple integer arithmetic, and have nowhere
near
the complexity of the lossy audio or video coding schemes. All of these
lossy
schemes live and die on FFTs, huge floating point resource pigs.
re: quality of MD, ATRAC, LP2, LP4, MP3: this is very easy to measure both
objectively and subjectively:
First, we have to agree on a "high quality" standard to start from. I
remember all of
the analogue vs digital flame wars of days gone by, but for now let's agree
that 16 bit PCM at 44.1khz as present on a CD is "high quality."
Use a bit-accurate CD-ROM drive and rip an audio file off a CD onto your PC.
This is
the original, "perfect" data source. Encode it as an MP3 using any bitrate
you care
to test, and then decode it back to PCM format. If you invert this file and
add it to
the original WAV file, the result will be the difference between the two
signals, the "error" between the original and the MP3 file. You can listen
to this error signal and measure its RMS value, to give both subjective and
objective quality measures.
Likewise, you can use the Sony ATRAC3 encoder software at 132kbps and 66kbps
bit rates to encode and decode the WAV file, to get the equivalent of LP2
and LP4 MD modes. I've done this with a couple tracks already, just out of
curiosity. The error signal is quite small, generally follows the contour of
the original music. For small source signal levels, the error is zero. Like
I said above, if you only have 3 bits worth of actual data in your source
signal, it will be recorded losslessly.
You can also try recording to and from MD using a digital interface, but
it's harder to use the resulting WAV file because you must synchronize
sample #1 of the original file with sample #1 of the MD file manually. Using
the computer program is a cinch because you don't have to guess where the
samples begin.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
-----------------------------------------------------------------
To stop getting this list send a message containing just the word
"unsubscribe" to [EMAIL PROTECTED]
